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

«но где это основная платформа для таких систем, как 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.

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

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

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

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

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

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

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

Правда?. Вы должны поставить перед собой задачу сообщить NASA, Google, CERN, Reuters и т. д., что все они используют базу данных любителей, которая не готова к использованию в прайм-тайм.

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

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

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

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

За все это вы платите временем разработки. После того, как вы использовали все эти советы, чтобы убедить своего босса, что вы ничего не потеряете, используя LAMP, месяцев, чтобы создать сайт на Java, и всего 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 стека:

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 в качестве БД

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

My 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. Они, вероятно, подходят для веб-приложений, где основная часть работы в любом случае выполняется веб-сервером и СУБД. Однако я предпочитаю статическую систему типов и предпочитаю Java/C# для бизнес-приложений и C++ для системного программирования.

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

Каковы основные черты корпоративной системы?

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

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

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

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

Масштабируемые веб-архитектуры Пожалуйста, посмотрите на долю рынка всех серверов с августа 1995 г. по январь 2009 г.

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

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

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

Я считаю, что дело не в том, что эта технология преждевременна или что-то, что заставляет таких крупных компаний, как AT&T, продвигаться вперед с полным внедрением на уровне предприятия. У этих компаний такой большой бюджет на ИТ-расходы, что последнее, о чем они будут думать, — это потратить больше на настройку и улучшение технологий с открытым исходным кодом, необходимых для удовлетворения потребностей их бизнеса.

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

Есть две основные проблемы для крупных предприятий, использующих стеки LAMP:

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

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

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

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

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

Вопрос о том, что означает буква «P» в LAMP, остается спорным. Я чувствую, что PHP не готов к корпоративному использованию, потому что у него так много отдельных недостатков (например, плохая обработка юникода, отсутствие пространств имен, несовместимые API, несогласованный синтаксис, плохая обратная совместимость версий, дублированные/устаревшие функциональные возможности), которые в совокупности усложняют его. реализовать ремонтопригодную систему.

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

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