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

Question

Подходит ли стек LAMP (Linux, Apache, MySQL, PHP / Ruby / Python) для использования на предприятии?

Для ясности, под «Предприятием» я подразумеваю крупную или очень большую компанию, в которой ключевыми факторами являются безопасность, надежность, доступность наборов навыков, общая стоимость владения (TCO), масштабируемость и доступность инструментов. Иными словами, компания, которая ищет внешнее внедрение фреймворков / архитектуры - что-то вездесущее будет восприниматься как более «правильное», чем что-то экзотическое / эзотерическое в такой среде.

Я видел случаи использования, когда Oracle, IBM и Sun внедрили системы в стеке LAMP для различных предприятий. Я также видел примеры, на которых основаны такие сайты, как yellowpages.com (Ruby on rails) и Facebook (php). Однако ни один из этих примеров не является именно тем, что я ищу.

Я действительно пытаюсь найти примеры, когда это стандарт Enterprise в очень крупном банке (т. Е. Citigroup), телекоммуникационной компании (т. Е. AT & T) или производителе (т. Е. Proctor and Gamble). Просто чтобы быть ясным, я не ищу пример, где он используется в ограниченном смысле (как в JPMorgan Chase), но где это базовая платформа для таких систем, как CRM, производственных систем или управления персоналом, а также для внутренних и внешние сайты.

До сих пор я видел, что приложения, построенные на стеке LAMP, работают медленнее и менее гибки. Вот некоторые аргументы, которые я слышал:

• Linux не так хорошо поддерживается, как Unix, Solaris или Windows Servers.

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

• MySQL - это база данных "не готовая к прайм-тайм" для любителей, и она не является конкурентом для SQL Server или Oracle (хотя PostgreSQL, похоже, имеет репутацию более надежной).

• PHP / Ruby on rails оптимизированы для CRUD (операции создания, чтения, обновления и удаления). Хотя это является преимуществом при создании веб-приложений, интенсивно использующих CRUD, они оба работают медленнее, чем Java / Java EE или C # (которые являются общими стандартами Enterprise). Кроме того, многие приложения и системы (например, производственные системы) имеют множество функций, не относящихся к CRUD, которые может быть сложнее создать с помощью PHP, Ruby или даже Python.

Может ли кто-нибудь предоставить аргументы в поддержку или опровергнуть идею о том, что стек LAMP подходит для Enterprise?

Спасибо!

KA

ОБНОВЛЕНИЕ: Иногда стек ЛАМПЫ подходит для корпоративного использования: внешние блоги

Answer 1

«но там, где это базовая платформа для таких систем, как CRM и HR, а также для внутренних и внешних веб-сайтов»

Сначала найдите приложение LAMP CRM или HR.

Затем найдите клиента для приложения LAMP CRM или HR.

К сожалению, примеров из пункта 1 не так много. Таким образом, ваш случай доказан. Его нельзя использовать для корпоративных приложений, потому что в настоящее время нет приложений, которые вы называете «корпоративными».

Другие ваши пункты, однако, очень интересны.

1. Linux не так хорошо поддерживается, как Unix, Solaris или Windows Servers . Я думаю, что Red Hat будет категорически против этого. Позвони им. Я думаю, что они сделают очень убедительный шаг продаж. Прочитайте их историй успеха .

2. Apache сложнее в настройке и обслуживании, чем веб-серверы, такие как BEA WebLogic или IIS . Кем? Менеджеры веб-сайтов Apache? Или менеджеры веб-сайтов IIS? Это совершенно субъективно.

3. MySQL - это база данных "не готовая к прайм-тайм" . Возьмите это с Sun Microsystems. Я думаю, что они будут категорически против этого. Позвони им. Я думаю, что они сделают очень убедительный шаг продаж. Прочитайте их историй успеха .

4. PHP / Ruby on rails оптимизированы для CRUD, и оба медленно работают . Может быть правдой. Java и Python могут быть быстрее. PHP и Ruby - не последнее слово в LAMP.

Answer 2

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

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

Linux не так хорошо поддерживается, как Unix, Solaris или Windows Servers.

Если это вас беспокоит, приобретите поддержку у RedHat или установите Solaris и приобретите поддержку у Sun. Оба из них окажут вам такую ​​же хорошую поддержку, как Microsoft, вероятно,

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

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

MySQL - это не готовая к работе прайм-тайм БД для любителей, а не конкурент для SQL Server или Oracle.

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

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

Здесь есть 2 вещи:

Оптимизировано для CRUD - это совершенно не имеет значения.
Rails и некоторые платформы python / php оптимизированы для приложений CRUD. Многие из платформ C # / Java также оптимизированы для приложений CRUD. Однако, если приложение, которое вы создаете, является приложением CRUD (и 99% веб-приложений), разве это не хорошо?
Если вы не создаете приложение CRUD, в ruby ​​/ python / php / java / C # есть множество не-оптимизированных фреймворков. Чистый выигрыш: никто (следовательно, это не имеет значения)

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

То, что вы компенсируете за все это, это время разработки. Как только вы воспользуетесь всем этим советом, чтобы убедить своего босса, что вы не потеряете на чем-либо, используя LAMP, если вы сократите числа и покажете им, что это займет 6 человеко-месяцев чтобы построить сайт на Java, и только 3, чтобы построить его на ruby ​​/ python, тогда это действительно то, к чему это сводится.

Answer 3

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

Тот же аргумент касается безопасности и надежности.

Facebook, Digg, часть Yahoo работает на PHP. Конечно, они нанимают много программистов PhD.

Answer 4

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

Linux не так хорошо поддерживается как Unix, Solaris или Windows Servers.

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

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

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

Answer 5

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

Answer 6

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

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

1. Java-стек, в котором у вас есть Solaris или Enterprise Linux, такие как (RedHat) с Weblogic / Websphere / Tomcat и т. Д., А также Java Enterprise, а также технологии Hibernate, Spring и т. Д. Большинство выберет Oracle в качестве БД.

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

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

Answer 7

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

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

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

Answer 8

строго субъективное мнение , но я лично считаю, что MySQL и, в меньшей степени, PHP - это слабость, но, конечно, есть много людей, которые не согласны, и крупные компании, которые пошли на LAMP.

Я бы предпочел, чтобы postgres или даже SQLite выводили куски с рынка MySQL, и я хотел бы больше видеть приложения на основе mono, jsp или cocoon. Я думаю, что LAMP слишком специфичен для общего термина. :)

Answer 9

У вас есть несколько очень плохих мифов в вашей публикации:

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

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

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

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

Answer 10

Причина, по которой я не могу найти корпоративные приложения, построенные на LAMP, не в том, что они не на уровне предприятия, а в чем-то совершенно другом, на мой взгляд. Многие крупные игроки используют LAMP или аналогичные - сразу же приходят на ум Facebook и MySpace . Так что это явно не проблема масштаба и производительности .

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