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


Answers

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

Хотя я лично не буду рекомендовать 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.

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

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

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

Оптимизирован для 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, тогда это действительно то, к чему это сводится.

Question

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

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

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

Я действительно пытаюсь найти примеры, когда это стандарт Enterprise в очень большом банке (Ie, Citigroup), телекоммуникационной компании (Ie, AT & T) или изготовителе (Ie, 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

ОБНОВЛЕНИЕ: несколько раз LAMP Stack подходит для использования в компании: внешние бэкграфы




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

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

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

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

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




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

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

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




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

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



Мой 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 ++ для системного программирования.




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

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

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

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

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




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

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

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




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

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

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




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

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

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

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

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




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

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