Подтвердить что ты не робот

Является ли стек LAMP подходящим для использования Enterprise?

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

Чтобы быть понятным, под "Enterprise" я имею в виду большую или очень большую компанию, в которой важны безопасность, надежность, доступность наборов навыков, общая стоимость владения (TCO), масштабируемость и доступность инструментов. С другой стороны, компания, которая ищет внешнее принятие фреймворков/архитектуры - что-то вездесущее будет рассматриваться как более "действительное", чем нечто экзотическое/эзотерическое в такой среде.

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

Я действительно пытаюсь найти примеры, когда это стандарт Enterprise в очень крупном банке (I.e., Citigroup), телекоммуникационной компании (I.e., AT & T) или изготовителе (I.e., 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 или С# (которые являются общими стандартами Enterprise). Кроме того, многие приложения и системы (например, производственные системы) имеют множество функций, отличных от CRUD, которые сложнее построить с помощью PHP или Ruby или даже Python.

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

Спасибо!

К.А.

UPDATE: Несколько раз LAMP Stack подходит для использования в компании: внешние блогов

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

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

К сожалению, примеров 1-го пункта не так много. Поэтому ваше дело доказано. Он не может использоваться для корпоративных приложений, потому что в настоящее время нет приложений, которые вы называете "корпоративными".

Тем не менее, ваши другие моменты очень интересны.

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

  • Apache сложнее настраивать и поддерживать, чем веб-серверы, такие как BEA WebLogic или IIS. Кем? Администраторы веб-сайта Apache? Или менеджеров веб-сайтов IIS? Это полностью субъективно.

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

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

Ответ 2

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

Хотя я лично не рекомендовал бы 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 или С# (которые являются общими стандартами Enterprise).

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

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

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

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

Ответ 3

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

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

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

Ответ 4

Просто подумал, что добавлю еще один сайт в список тех, которые работают на LAMP - Wikipedia. Седьмой крупнейший веб-сайт в мире, написанный полностью на PHP и запущенный MySQL, и у них есть только два или три платных разработчика. Конечно, у них есть помощь со стороны добровольцев, но это не так много, и это очень хорошо. Не знаю, действительно ли вы назовете их "предприятием", но для такого огромного и популярного веб-сайта они, похоже, сделали все для себя.

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

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

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

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

Ответ 5

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

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

  • Java Stack, где у вас есть Solaris или Enterprise Linux (RedHat) с Weblogic/Websphere/Tomcat и т.д. и Java Enterprise вместе с технологиями Hibernate, Spring и т.д. Большинство выбрало бы Oracle как DB.

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

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

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

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

Ответ 9

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

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

Ответ 10

У вас есть некоторые реальные плохие мифы в вашем сообщении:

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

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

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

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

Ответ 11

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

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

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

Ответ 12

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

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

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

Ответ 13

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

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

Ответ 14

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/С# для бизнес-приложения и С++ для системного программирования.

Ответ 15

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

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

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

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

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

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

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

Ответ 16

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

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

Ответ 17

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

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

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

Ответ 18

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

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

Ответ 19

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

Ответ 20

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

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

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

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

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

Ответ 21

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