Подходит ли стек LAMP для использования на предприятии?
Подходит ли стек LAMP (Linux, Apache, MySQL, PHP / Ruby / Python) для использования на предприятии?
Чтобы быть понятным, под "Предприятием" я подразумеваю крупную или очень большую компанию, в которой ключевыми факторами являются безопасность, надежность, доступность наборов навыков, общая стоимость владения (TCO), масштабируемость и доступность инструментов. Иными словами, компания, которая ищет внешнее внедрение фреймворков / архитектуры - что-то вездесущее будет восприниматься как более "обоснованное", чем что-то экзотическое / эзотерическое в такой среде.
Я видел случаи использования, когда Oracle, IBM и Sun внедрили системы в стеке LAMP для различных предприятий. Я также видел примеры, на которых основаны такие сайты, как yellowpages.com (Ruby on rails) и Facebook (php). Однако ни один из этих примеров не является именно тем, что я ищу.
Я действительно пытаюсь найти примеры, когда это стандарт Enterprise в очень крупном банке (т.е. Citigroup), телекоммуникационной компании (т.е. AT&T) или производителе (т.е. Proctor и 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 подходит для предприятия?
Спасибо!
KA
ОБНОВЛЕНИЕ: Иногда стек LAMP подходит для корпоративного использования: внешние блоги
21 ответ
"но где это основная платформа для таких систем, как CRM и HR, а также для внутренних и внешних веб-сайтов"
Сначала найдите приложение LAMP CRM или HR.
Затем найдите клиента для применения LAMP CRM или HR.
К сожалению, примеров по пункту 1 не так много. Таким образом, ваш случай доказан. Его нельзя использовать для корпоративных приложений, потому что в настоящее время нет приложений, которые вы называете "корпоративными".
Другие ваши пункты, однако, очень интересны.
Linux не так хорошо поддерживается, как Unix, Solaris или Windows Servers. Я думаю, что Red Hat будет категорически против этого. Позвони им. Я думаю, что они сделают очень убедительный шаг продаж. Прочитайте их истории успеха.
Apache сложнее в настройке и обслуживании, чем веб-серверы, такие как BEA WebLogic или IIS. Кем? Менеджеры веб-сайтов Apache? Или менеджеры веб-сайтов IIS? Это полностью субъективно.
MySQL - это база данных "не готова к прайм-тайм". Возьмите это с Sun Microsystems. Я думаю, что они будут категорически против этого. Позвони им. Я думаю, что они сделают очень убедительный шаг продаж. Прочитайте их истории успеха.
PHP / Ruby on rails оптимизированы для CRUD, и оба медленно работают. Может быть правдой. Java и Python могут быть быстрее. PHP и Ruby - не последнее слово в LAMP.
Что-то вездесущее будет рассматриваться как более "действительное", чем что-то экзотическое / эзотерическое в такой среде.
Хотя я лично не рекомендовал бы 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, если вы сократите числа и покажете им, что на создание сайта на Java потребуется 6 человеко-месяцев и только 3, чтобы собрать его в ruby / python, тогда это действительно то, к чему это сводится.
Если вы нанимаете идиотов для его реализации, C++ и Oracle не смогут масштабироваться. Если вы нанимаете умных людей и добиваетесь успеха, PHP и MySQL будут отлично масштабироваться.
Тот же аргумент относится к безопасности и надежности.
Facebook, Digg, часть Yahoo работает на PHP. Конечно, они нанимают много докторов наук.
Просто подумал, что добавлю еще один сайт в список тех, что работают на LAMP - Википедия. Седьмой по величине веб-сайт в мире, полностью написанный на PHP и работающий на MySQL, и у них всего два или три платных разработчика. Конечно, им помогают некоторые волонтеры, но это не так много, и масштабируется просто отлично. Не знаю, на самом ли деле вы бы назвали их "корпоративными", но для такого огромного и популярного веб-сайта они, похоже, сделали все для себя.
Linux не так хорошо поддерживается, как Unix, Solaris или Windows Servers.
Как уже говорили выше, позвоните в Red Hat, и я уверен, что они будут умолять. И объем поддержки для Linux абсолютно бесплатно удивителен.
Apache сложнее в настройке и обслуживании, чем веб-серверы, такие как BEA WebLogic или IIS.
Это зависит от того, кого вы спрашиваете. Люди, которые обычно администрируют IIS-серверы, вероятно, увидят это так. Люди, которые обычно управляют Apache, не будут. Это зависит от того, кого вы нанимаете, и если ваш стек LAMP, вы не захотите нанимать людей, не имеющих опыта работы с Apache.
Я просто хочу добавить, что я неоднократно был свидетелем того, как клиенты чувствуют себя комфортно только после того, как они предлагают серьезное $$$ для какого-либо решения, даже если это делает интеграцию предприятия еще сложнее, несмотря на то, какие аргументы вы приводите.
Я думаю, что первым критерием должен быть уровень квалификации вашей команды, уровень комфорта, чтобы убедиться, что любые решения, принимаемые на платформе, хорошо с ними работают. Что бы вы ни решили, подумайте о масштабируемости и удобстве сопровождения вашего кода. Инструменты потрясающие, независимо от того, какой стек вы выберете.
Лично я бы разбил его на 3 стека
Стек Java, где у вас есть Solaris или Enterprise Linux, такие как ( RedHat) с Weblogic/Websphere/Tomcat и т. Д., А также Java Enterprise, а также технологии Hibernate, Spring и т. Д. Большинство выберет Oracle в качестве БД.
Microsoft Stack с некоторым открытым исходным кодом при необходимости Win Server - IIS - .net/C# (ASP.net и т. Д.) - NHibernate, NUnit (модульное тестирование) и т. Д. Скорее всего, вы захотите использовать SQL Server в качестве БД
Ни один из вышеперечисленных стеков с Enterprise Linux, на котором запущен целый буфет с открытым исходным кодом, такой как MySQL (теперь под доменом Sun, поэтому на него можно серьезно смотреть), Apache (есть гуру apache), Ruby (не мой личный выбор)/ PHP (удачи) / Python (мне нравится, потому что это зрелый язык). Я бы защищал python или ruby с точки зрения управляющего кода. Может быть, для некоторых это может быть PHP.. я не в это.
Linux/Apache надежны, надежны, и каждый из них поставляется с множеством людей (по разумной цене, конечно), которые обеспечат поддержку, множество полезных инструментов, многие с исключительно высоким уровнем полезности, которые работают с ними и которые были построены на них.,
Не уверен насчет двух других, однако. В частности, MySQL, похоже, принял странный оборот в худшую сторону с момента их приобретения Sun, вопреки сообщениям в этой теме, предполагающим, что Sun может оказать хорошее влияние:
Сугубо субъективное мнение, но я лично считаю, что MySQL и, в меньшей степени, PHP - слабость, но, безусловно, есть много людей, которые не согласны, и крупные компании, которые пошли на LAMP.
Я бы предпочел, чтобы postgres или даже SQLite выводили куски из рынка MySQL, и я хотел бы больше видеть приложения на основе mono, jsp или cocoon. Я думаю, что LAMP слишком специфичен для общего термина.:)
У вас есть несколько действительно плохих мифов в вашей публикации:
Мифы о JavaEE: -App-серверы легче настраивать, чем apache, нет apache-проще. - Вы подразумеваете, что только полное решение JavaEE является корпоративным, нет.
Мифы о CRUD: -CRUD медленнее, чем JavaEE? WTF? POJO и EJB используют CRUD. Ограничивающий фактор не грубый, его пропускная способность сервера
Существует 3 ограничивающих узких места, независимо от того, какая технология, даже реализация MS, серверный уровень и уровень приложений. Выбранная технология не является фактором скорости, так как вы можете обменять преимущества на одном уровне на недостатки на другом уровне. Например, мы могли бы ускорить Java, используя хранилище документов вместо обычной БД.
Большинство новых реализаций Rails используют не Apache-серверы, которые в 3–5 раз быстрее, чем Apache. Даже хорошо настроенный Apache-сервер может превзойти некоторые стеки javaEE. Просто спросите yahoo, поскольку они используют Symfony в некоторых своих свойствах.
Причина, по которой я не нашел корпоративных приложений, построенных на LAMP, не в том, что они не являются корпоративными, а в чем-то совершенно другом, на мой взгляд. Многие крупные игроки используют LAMP или аналогичные - сразу приходят на ум Facebook и MySpace. Так что это явно не проблема масштаба и совершенства.
Тем не менее, причина, по которой я нахожу, что нет никаких корпоративных приложений, построенных на LAMP, из-за их внутренней открытости. Я не хочу строить актуарный модуль как файл PHP, потому что любой может украсть логику. С другой стороны, если у меня есть DLL, я могу сохранить контроль. По этой же причине вы не найдете много 30-пробных приложений, построенных на PHP, но гораздо проще добиться такой защиты, скажем, ASP.NET.
Я думаю, вы обнаружите, что многие предприятия используют серверы Linux, часто поддерживаемые Redhat, Novell или IBM, и что Apache также широко используется.
Но многие предприятия, как правило, используют базы данных, такие как Oracle или IBM DB2, вместо предложений с открытым исходным кодом, хотя есть много предприятий, которым действительно не нужен тип мощности, предоставляемый этими системами, и они могут сойти с MySQL или PostgreSQL.
Что касается языка веб-сервера, я думаю, что вы можете использовать что угодно. Тем не менее, если вы используете Apache, возможно, будет проще использовать PHP, Ruby или Python, тогда как если вы используете IIS или Weblogic или Domino, это будет проще сделать в Java / C#.
Я хотел бы предложить, чтобы мы определили требования к масштабируемости корпоративных систем и их различия по сравнению с веб-приложениями. Посмотрите на некоторые из наиболее масштабируемых систем, таких как Википедия, Flickr, Wordpress, Facebook, MySpace и множество других. Там вы увидите ЛАМПУ. Я больше фанат Python (так как я чувствую, что язык более чистый), но я слушаю таких экспертов, как Кэл Хендерсон (Flickr), которые написали книгу о масштабируемости, рассказывая о том, как он масштабировал банк серверов MySQL.
Каковы основные характеристики системы предприятия?
Поддержка, наличие опыта, стабильность платформы / языка, вероятно, рассчитывают.
Но у LAMP есть и другие функции, такие как более быстрая разработка, более простая расширяемость, множество доступных библиотек для повторного использования, несколько документированных историй масштабируемости, зрелые веб-фреймворки.
Вот несколько советов по созданию масштабируемых систем (я говорю о веб-масштабе). В свете всех этих доказательств я всегда удивлялся, почему продолжает появляться представление о том, что LAMP не готов для корпоративных приложений.
Что касается Apache, каждое исследование Netcraft показывает совершенно другую историю принятия. Из-за огромного количества серверов может быть больше людей, обладающих знаниями для настройки, настройки и расширения веб-сервера.
Масштабируемые веб-архитектуры. Посмотрите на долю рынка всех серверов с августа 1995 г. по январь 2009 г.
Мой 2с:
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. Они, вероятно, в порядке для веб-приложений, где большая часть работы выполняется веб-сервером и СУБД в любом случае. Однако я предпочитаю статическую систему типов и предпочел бы выбрать Java/C# для бизнес-приложения и C++ для системного программирования.
ИМО нет хороших общих аргументов против Linux и Apache; Вы, безусловно, можете получить поддержку Linux на уровне предприятия, если будете готовы заплатить за нее (и можете получить бесплатное приближение к ней, если вы готовы играть по правилам сообщества). А Apache не так сложно настроить, если вам не нужны его более сложные функции, что маловероятно для сервера приложений.
Вы, конечно, можете возразить против MySQL, поскольку некоторые из наиболее важных функций в отношении безопасности данных были добавлены только недавно. Если вы обеспокоены этим, используйте вместо этого PostgreSQL.
Что касается языка, на котором вы пишете свое приложение: PHP определенно доказал способность запускать чрезвычайно большие и сложные системы; Я был бы больше обеспокоен ремонтопригодностью, чем производительностью. А Ruby on Rails "оптимизирован для CRUD" только потому, что простое веб-приложение CRUD может быть написано почти мгновенно (буквально за минуты), но это не значит, что оно как-то менее подходит для более сложных приложений, просто то, что оно займет гораздо больше времени (все еще меньше, чем со многими другими языками)
Я полагаю, что крупные коммерческие приложения CRM и HR могут быть смещены в сторону предоставления крупных коммерческих продуктов СУБД в качестве основы для их продуктов. Если они ничего не сделают, я уверен, что они предпочтут объединиться против общей угрозы.
И им будет труднее оправдывать оплату лицензий и поддержки, если они интегрируют продукты, в которых их нет.
Для крупных предприятий, использующих стеки LAMP, есть две основные проблемы:
- TCO: принимая во внимание, что LAMP в основном бесплатен, предприятия по-прежнему достигают более низкой общей стоимости эксплуатации с другими коммерческими решениями
- Поддерживаемость: предприятия без проблем платят дополнительный доллар, чтобы получить круглосуточную профессиональную поддержку от своих коммерческих поставщиков.
Я полагаю, что дело не в том, что технология преждевременна или что-то такое, что удерживает такие крупные компании, как AT&T, для полной реализации на уровне предприятия. У этих компаний такой большой бюджет на ИТ-расходы, что последнее, о чем они должны помнить, - это тратить больше средств на настройку и усовершенствование, необходимые для технологий с открытым исходным кодом в соответствии с потребностями их бизнеса.
Так что они ищут (что вытекает из моего опыта консалтинга), покупая и управляя пакетом продуктов, и не нужно тратить больше на исследования и хакерскую часть. Компании, которые используют сборку с открытым исходным кодом, создали свои собственные группы поддержки во всем мире, чтобы удовлетворить любые потребности в поддержке, которые крупные предприятия не очень хотят делать. Им нужно все сделать быстро и точно, и они могут заплатить.
Линукс используется много. Apache и Tomcat используются очень часто. MySQL может быть надежным сейчас. Я бы использовал PostgreSQL вместо этого. Банки будут использовать Oracle, но там есть хорошая поддержка Java и Tomcat. PHP часто используется, но многие крупные компании предпочли бы Java.
На мой взгляд, лучше всего спорить о Linux (возможно, коммерчески поддерживаемой версии) решения Tomcat, Java, Tomcat|Oracle|MSSQL.
Вам понадобится системный администратор Linux, особенно с учетом увеличения количества серверов, хотя я уверен, что вы можете получить неполный рабочий день до того, как наступит это время. Если у компании уже есть системные администраторы Windows, то спорить о Linux будет сложно.
Redhat и IBM предоставляют полную поддержку Linux, Sun купила MySQL, Yahoo использует Php, многие компании используют стек LAMP, но многие используют детали.
Лично я не считаю, что Linux поддерживается хуже, чем другие упомянутые ОС; на самом деле производители оборудования обычно поддерживают Linux поверх любой другой ОС (кроме Windows, которую они обычно поддерживают довольно хорошо, если вы используете дистрибутивы maintream).
При условии, что вы не используете причудливый аромат (Совет: просто используйте RHEL или Centos, который является его бесплатным эквивалентом), Linux очень хорошо поддерживается.
MySQL может иметь некоторые недостатки, но, на мой взгляд, у него много сильных сторон; мы используем его в больших масштабах способами, которые не предназначены, но в целом он все еще работает довольно хорошо (большинство проблем связано с тем, что наши версии устарели или плохо настроены).
То, что "P" обозначает в ЛАМПЕ, является спорным. Я чувствую, что PHP не готов для предприятия, потому что у него так много индивидуальных недостатков (например, плохая обработка юникода, отсутствие пространств имен, несовместимые API, несовместимый синтаксис, плохая обратная совместимость версий, дублируемая / устаревшая функциональность), что они в совокупности усложняют его. внедрить ремонтопригодную систему.
Но с учетом соответствующей опытной команды, даже если вы выберете PHP, его можно использовать для создания чрезвычайно качественного приложения.
Если это достаточно хорошо для Google, поверьте мне, это достаточно хорошо для вас.