Действительно ли стек LAMP подходит для использования Предприятия?

Я лично не вижу Linux, как менее хорошо поддерживаемый, чем другая упомянутая ОС; на самом деле поставщики оборудования обычно поддерживают Linux по любой другой ОС (за исключением Windows, который они действительно обычно поддерживают вполне хорошо, если Вы используете основные дистрибутивы).

, Если Вы не используете причудливый аромат (Подсказка: Просто используйте RHEL или Centos, который является его свободным эквивалентом), Linux очень хорошо поддерживается.

MySQL может иметь некоторые недостатки, но по-моему он имеет много преимуществ; мы используем его в крупном масштабе способами, не предназначенными, но это все еще работает вполне хорошо обычно (большинство проблем происходит из-за наших версий, являющихся устаревшим или плохо настроенным).

то, Что обозначает "P" в ЛАМПЕ, спорно. Я чувствую, что PHP не готов к предприятию, потому что он имеет столько отдельных недостатков (например, плохая обработка unicode, никакие пространства имен, непоследовательные API, непоследовательный синтаксис, плохая версия назад совместимость, дублированная/устаревшая функциональность), что они составляют в целом создание помех реализовать удобную в сопровождении систему.

, Но, учитывая соответственно опытную команду, даже если Вы выбираете PHP, он может использоваться для подавания чрезвычайно высококачественной заявки.

Если это достаточно хорошо для Google, доверяйте мне, это достаточно хорошо для Вас.

Redhat и IBM оказывают полную поддержку для Linux, Sun купил MySQL, Yahoo использует Php, многочисленные компании используют стек LAMP, но много частей использования.

Существует два основных вопроса для крупных предприятий с помощью стопок ЛАМПЫ:

• TCO: учитывая, что ЛАМПА в основном прибывает свободная, предприятия все еще достигают более низкой общей стоимости операции с другими коммерческими решениями
• Обеспеченность : предприятия не имеют никакой проблемы при оплате дополнительного маркера для получения круглосуточной профессиональной поддержки от их коммерческих поставщиков

Linux используется много. Apache и Tomcat используются много. MySQL может быть устойчивым теперь. Я использовал бы PostgreSQL вместо этого. Banks будет использовать Oracle, но существует хорошая поддержка Java и Tomcat там. PHP используется много, но многие крупные компании предпочли бы Java.

Вы являетесь лучшими от приведения доводов в пользу в пользу Linux, (возможно коммерчески поддерживаемая версия) Tomcat, Java, решение Tomcat|Oracle|MSSQL, по-моему.

Вам будет нужен системный администратор Linux, тем более, что количество подъемов серверов, хотя я уверен, что можно получить неполный рабочий день один в том, прежде чем то время возникнет. Если компания уже имеет системных администраторов Windows, тогда приводящих доводы в пользу Linux, будет жестким.

Я хотел бы предложить, чтобы мы определили требования масштабируемости Корпоративных систем и как они отличаются по сравнению с веб-приложениями. Посмотрите на некоторые из большинства масштабируемых систем как Википедия, Flickr, Wordpress, Facebook, MySpace и хост других. Вы будете видеть стек LAMP там. Я - больше поклонника Python (так как я чувствую, что язык имеет более чистое чувство), но я слушаю экспертов как Cal Henderson (Flickr), кто записал книгу по масштабируемости, говорящей о том, как он масштабировал банк серверов MySQL.

, Каковы существенные особенности корпоративной системы?

Поддержка, доступность экспертных знаний, устойчивость платформы/языка, вероятно, рассчитывает.

, Но ЛАМПА имеет другие функции как более быстрая разработка, более легкая расширяемость, много доступных библиотек для повторного использования, нескольких зарегистрированных историй масштабируемости, назревающих веб-платформ.

Вот несколько указателей на создание Масштабируемых систем (я говорю о веб-Масштабе). Я всегда задавался вопросом в свете всего этого доказательства, почему восприятие ЛАМПЫ, как не являющейся готовым к Корпоративным приложениям, продолжает открываться.

Что касается Apache, каждое исследование Netcraft показывает совсем другую историю принятия. Чистым количеством серверов может быть больше людей со знанием, чтобы настроить, настроить и расширить веб-сервер.

Масштабируемая веб-Архитектура Посмотрите на Долю рынка всего августа 1995 Серверов Jan 2009

Мой 2c:

Linux: Так как ядро 2.6 вышло, я скажу, что это - определенно высококачественная ОС. Версия 2.4 не была вполне там, и 2.2 была шутка, но 2.6 действительно хорошо. Будьте осторожны с выбором распределения, все же. По моему опыту, RedHat/CentOS очень хорош, и по-видимому Debian (исходный, не Ubuntu!) может быть настроен приятно, если у Вас есть хороший администратор. Мой опыт с OpenSUSE был не очень хорош.

Apache: не использовали его, но я не вижу, почему это была бы проблема.

MySQL: Это - самое слабое место стека. Я не собираюсь сообщать подробности здесь - изучают комментарии в reddit.programming, если Вам интересно. Лучший взгляд на PostgreSQL.

PHP/Perl/Ruby/Python: Я работал с Perl и до меньшей степени с Python. Они, вероятно, хорошо для веб-приложений, где объем работы сделан веб-сервером и DBMS так или иначе. Однако я действительно предпочитаю статическую систему типов и выбрал бы Java/C# для бизнес-приложения и C++ для системного программирования.

IMO там не являются никакими хорошими общими аргументами против Linux и Apache; можно, конечно, получить поддержку уровня предприятия Linux, если Вы готовы заплатить за него (и хорошее приближение его бесплатно, если Вы готовы играть по правилам сообщества). И Apache не то, что трудно для конфигурирования, если Вам не нужны его более сложные функции, который маловероятен в сервере приложений.

можно, конечно, изложить доводы против MySQL, так как некоторые самые важные опции в отношении безопасности данных были добавлены только недавно. Если Вы обеспокоены этим, используйте PostgreSQL вместо этого.

Что касается языка Вы пишете свое приложение в: PHP, определенно оказалось, был в состоянии выполнить чрезвычайно большие и сложные системы; я был бы более обеспокоен пригодностью для обслуживания, чем производительность. И Ruby on Rails "оптимизирован для CRUD" только в asmuch, поскольку простое веб-приложение CRUD не может быть записано в почти никакое время (буквально минуты), но это не означает, что так или иначе меньше подходит для более сложных приложений, просто что потребуется намного больше времени (еще меньше, чем со многими другими языками)

Я предполагаю, что большой коммерческий CRM и приложения HR могли бы быть смещены к поставке больших коммерческих продуктов RDBMS как основа для их продуктов. Если ничто иное, они будут, я уверен, предпочитают объединяться против общей угрозы.

И они приходятся тяжелее, выравнивая по ширине лицензию и поддерживают сборы, если они интегрируют продукты, которые не имеют их.

Причина того, что не были найдены Корпоративные приложения основывалась на ЛАМПЕ, то, не потому что они не уровень предприятия, но что-то совершенно различное, по-моему. Много крупных игроков использует ЛАМПУ или подобный - Facebook и <забастовка>, MySpace сразу приходит на ум. Так ясно не проблема масштаб и перфект .

Тем не менее причина я нахожу, что нет никаких корпоративных приложений, основывался на ЛАМПЕ, из-за их внутреннего открытого характера. Я не хочу создавать страховой модуль как файл PHP, потому что любой может украсть логику. С другой стороны, если у меня есть DLL, я могу сохранить контроль. Вы не находите, что много приложений с 30 пробными версиями основывалось на PHP по этой самой причине, но намного легче достигнуть такой защиты с, говорится в ASP.NET.

Linux/Apache укреплен, наклон, и каждый идет с большим количеством людей (для хорошей цены, конечно), кто окажет поддержку, много полезных инструментов, многих на исключительно высоких уровнях утилиты, которые работают с ними и которые были созданы на них.

Не уверенный в других двух, как бы то ни было. В особенности MySQL, кажется, взял странную перемену к худшему начиная с того, что они были полученными Sun вопреки сообщениям в этом потоке, предполагающем, что Sun может быть хорошим влиянием:

http://www.reddit.com/r/programming/comments/7gb8j/oops_we_did_it_again_mysql_51_released_as_ga_with/

строго субъективное мнение , но я лично нахожу, что MySQL и до меньшей степени PHP определенная слабость, но конечно существует много людей, которые не соглашаются и крупные компании, которые пошли ЛАМПА.

я предпочел бы видеть пост-ГРЭС, или даже SQLite вынимают блоки из рынка MySQL, и я хотел бы видеть моно или jsp или основанные на коконе приложения больше. Я предполагаю, что ЛАМПА немного слишком специфична для обобщающего понятия.:)

Я думаю, что первые критерии должны быть уровнем квалификации Вашей команды, выступ уровня комфорта для проверки, что когда-либо решения платформы приняты работы хорошо с ними. Независимо от того, что Вы решаете, думают о масштабируемости и пригодности для обслуживания Вашего кода. Инструменты являются потрясающими, неважно, что складывает Вас, выбирают.

я лично разломал бы его на 3 стека -

1. Стопка Java, где у Вас есть Солярис, или Предприятие Linux как (Redhat) с Weblogic/Websphere/Tomcat и т.д. и Java Enterprise наряду с В спящем режиме, Spring и т.д. технологии. Большинство выбрало бы Oracle как DB.

2. Microsoft Stack с некоторым Открытым исходным кодом в случае необходимости Сервер Победы - IIS - .net/C# (ASP.net и т.д.) - NHibernate, NUnit (поблочное тестирование) и т.д., Скорее всего, Вы хотели бы использовать SQL Server в качестве DB

3. Ни один из вышеупомянутого стека с Предприятием Linux, выполняющим целый шведский стол материала с открытым исходным кодом как MySQL (теперь под доменом Sun, на так можно посмотреть серьезно), Apache (существуют апачские гуру там), Ruby (не мой личный выбор) / PHP (удача) / Python (мне нравится он, потому что это - зрелый язык). Я защитил бы Python или рубин от руководящей кодовой точки представления. Возможно, для некоторых это мог быть PHP.. я не в него.

Я просто хочу добавить, что я много раз свидетельствовал, что клиенты только чувствуют себя комфортно, как только они подают серьезный $$$ для некоторого решения, даже если это делает интеграцию предприятия еще тяжелее, несмотря на то, какие аргументы Вы приносите к таблице.

Если Вы нанимаете идиотов для реализации его, C++ & Oracle не масштабируется. Если Вы нанимаете людей, которые умны и добиваются цели, PHP & MySQL масштабируется очень хорошо.

Тот же аргумент идет для безопасности & устойчивость.

Facebook, Digg, части Yahoo, на котором работают PHP. Конечно, они нанимают много программистов доктора философии.

Просто мысль, я добавил бы другой веб-сайт к списку тех, которые работают на ЛАМПЕ - Википедия. Седьмой по величине веб-сайт в мире, записанном полностью в PHP и, убегает MySQL, и у них только есть два или три заплаченных разработчика. Конечно, у них есть некоторая помощь от волонтеров, но это не много, и это масштабируется очень хорошо. Не знайте, назвали ли Вы действительно их 'предприятием', но для такого огромного и популярного веб-сайта они, кажется, сделали хорошо для себя.

Linux рассматривается как не также поддерживаемый как Unix, Солярис или Windows Server.

, Поскольку другие сказали выше, позвоните Red Hat, и я уверен, что они будут просить отличаться. И сумма поддержки там Linux , абсолютно свободного , удивительна.

Apache более трудно настроить и поддержать, чем веб-серверы как BEA WebLogic или IIS.

, Который зависит, кого Вы спрашиваете. Люди, которые обычно администрируют серверы IIS, вероятно, просмотрят его этот путь. Люди, которые обычно администрируют Apache, не будут. Это зависит от того, кого Вы нанимаете, и если Вашим стеком будет ЛАМПА, то Вы не захотите нанимать людей без опыта Apache так или иначе.

Я думаю, что Вы найдете, что многие предприятия используют серверы Linux, часто поддерживаемые Redhat, Novell или IBM, и что Apache является также наиболее часто используемым.

, Но многие предприятия имеют тенденцию использовать базы данных как Oracle или IBM DB2 вместо предложений с открытым исходным кодом - хотя существуют многие предприятия, которым действительно не нужен вид питания, которое те системы обеспечивают и могли сойти с рук MySQL или PostgreSQL.

И для языка веб-сервера, я думаю, что можно использовать примерно что-либо. Однако при использовании Apache, вероятно, легче использовать PHP, Ruby или Python, тогда как при использовании IIS или Weblogic или Domino будет легче сделать это в Java / C#.

Что-то повсеместное будет рассматриваться как более "допустимое", чем что-то экзотическое / тайный в этом виде среды.

, Хотя я лично не рекомендовал бы PHP из-за многих дефектов на языке, это несомненно повсеместно. С появлением phusion пассажира поддержка направляющих среди общих хостинговых компаний растет довольно быстро также. Я даю ему другой год или 2 самое большее прежде 90 +, % общих хостинг-аккаунтов поддерживают направляющие из поля. Если это не повсеместно, что?

Linux рассматривается как не также поддерживаемый как Unix, Солярис или Windows Server.

, Если это беспокоит Вас, поддержку покупки со стороны Redhat или установку, Солярис и покупка поддерживают от Sun. Оба из тех окажут Вам так же, как хорошая поддержка, поскольку Microsoft вероятна [1 113]

, Apache более трудно настроить и поддержать, чем веб-серверы как BEA WebLogic или IIS.

я не могу говорить за BEA WebLogic, но настраивавший и Apache, IIS и Tomcat, Apache является самым легким и понять и найти примеры и документацию для длинным путем.

MySQL "не готов к прайм-тайму" DB для людей, увлеченных своим хобби, и не конкурента для SQL Server или Oracle.

, О, действительно? . Необходимо сделать миссией сказать НАСА, Google, CERN, Агентство Рейтер и т.д., что они все используют базу данных человека, увлеченного своим хобби, которая не готова к прайм-тайму.

PHP / Ruby на направляющих оптимизирован для CRUD, и оба работают медленнее, чем EE Java/Java или C# (которые являются оба общими стандартами Предприятия).

здесь существует 2 вещи:

Оптимизированный для CRUD - Это полностью не важно.
направляющие и некоторые python/php платформы оптимизированы для Приложений типа CRUD. Многие платформы C#/Java также оптимизированы для Приложений типа CRUD. Однако, если приложением, которое Вы создаете, является Приложение типа CRUD (и 99% веб-приложений), разве это не Хорошая Вещь?
, Если Вы не создаете Приложение типа CRUD, существует много non-crud-optimized платформ в ruby/python/php/java/C#. Сетевая победа: Никто (следовательно это не важно)

, Работают медленнее, чем Java/C# - Это, несомненно, верно, но это также не имеет значения. Поскольку сайт низкого трафика, различие в производительности не собирается составлять что-либо, и для сайта интенсивного трафика Ваше узкое место, будет базой данных, ли это быть MySQL, оракулом, или что бы то ни было.

, Что Вы компромисс для всего этого являетесь временем разработки. Как только Вы использовали весь этот совет убедить Вашего босса, что Вы не будете терпеть неудачу ни на чем при помощи ЛАМПЫ, Если Вы произведете подсчеты и покажете Ваш их, что это собирается занять 6 месяцев человека для создания сайта в Java, и только 3 для создания его в рубине/Python тогда это действительно, к чему это сводится.

У вас есть несколько действительно плохих мифов в посте:

JavaEE Myths: -App Servers проще настраивать, чем apache, nope apache проще. -Вы подразумеваете, что только JavaEE полное решение является корпоративным, нет.

CRUD Мифы: -CRUD медленнее JavaEE? WTF? POJO и EJB используют CRUD. Ограничительный фактор не crud, его пропускная способность сервера

Есть 3 ограничивающих узких места независимо от технологии, даже MS...серверной реализации, persistence layer, и app layer...выбранная технология не является фактором скорости, так как вы можете обменяться преимуществами в одном слое на недостатки в другом слое. В качестве примера можно привести использование хранилища документов вместо обычных БД...

В большинстве новых реализаций Rails используются не apache-серверы, которые в 3-5 раз быстрее Apache...даже хорошо настроенный сервер Apache может превзойти некоторые javaEE стеки...просто спросите yahoo, так как они используют Symfony в некоторых своих свойствах...