Pull to refresh

Comments 28

сосредоточить свои усилия на Zend Server


А кто-нибудь пользуется этой… кхм… поделкой? Пару раз смотрел всякие ролики про него и не понял зачем он нужен, когда это и так есть по-дефолту.

Учитывая это, вообще считаю откровенным бредом такое решение компании. Продвигать никчёмный продукт и гробить то, чем действительно пользовались.
Видимо этот продукт приносит основную прибыль.
Что по дефолту есть?
Они продают поддержку всего стека технологий для работы php приложений.
Если вам это не требовалось, то вам пока везло.
Если вам это не требовалось, то вам пока везло.


Мне всегда хватало apt install php-fpm. Ну или докер + кубернетис. Не суть. Смысл в том, что уже есть, бесплатно и на установку и конфиг оркестровки тратится… ну час, максимум.
UFO just landed and posted this here
Почему не подходит для продакшена?
UFO just landed and posted this here
На западе в больших конторах думают по другому. Они покупают поддержку, гарантию роботоспособности у разработчика.
У нас на фирме прикупили как-то лицензии на зенд сервер (ZS) пару лет назад. Цена вопроса по слухам была 6ти значной в евро за 3 года лицензии.

Из киллер фич было:
  • Возможность настраивать оповещения на различные события, например, превышение времени выполнения скрипта/URL, потребление памяти, exceptions
  • Профайлер мог включаться прямо в продакшене по событиям, по желанию если открыть страницу с секретным токеном, либо с какой-то вероятностью по определённому URL
  • Возможность записи краха приложения (по exceptions, например). При этом записовалось состояние приложения и в Zend Studio можно было прокрутить событие назад (тут могу немного ошибаться). Только работало это всё исключительно в ZendStudio, который мы уже почти не использовали.
  • Графики, счётчики
  • Возможность установки Zend Framework прямо на сервере без всяких composer. Идея была в том, что ZF выступал бы в роле сервера приложений и можно обновлять ZF на уровне сервера


С чем столкнулись в реальности:
  • Вроде всё работало стабильно, все заявленные фичи тоже работали.
  • Потратили уйму времени (где-то год почти) на интеграцию в инфраструктуру, обучение сисадминов, изменение деплоймента. Сам деплоймент усложнился, появилось промежуточное звено в виде zstool
  • Многие фичи оказались не нужны вообще. Всем было лень заглядывать в логи в поисках гипотетических проблем, графики тоже особо были не нужны.
  • Интеграция с Zend Studio оказалась ненужна
  • Фича по установке ZF прямо в сервер тоже оказалась не нужна и даже мешала. Были установлены какие-то внутренние модули, которые прописывались в spi_autoloader и это мешало нашему composer autoloader. Т.е. при загрузке страницы подгружались какие-то неведомые php файлы откуда-то из /var/lib/zend
  • Сисадмины имели большие проблемы с обновлениями безопасности и openssl, ведь ZS это не пакет в системе, это и есть система! Приходилось тревожить техподдержку зенда и пинать чтобы быстрее выпустили апдейты безопасности
  • Были глюки с конфигурацией apache vhost, обращались в поддержку, бездушный индийский саппорт на ломанном английском сказал, что не смог воспроизвести проблемы и значит её нету. Хотя мы описали подробнейшую инструкцию.
  • Для подготовки zip пакета для деплоймента надо было использовать zstool, оно умело делать зип архив только в один поток. Стоит ли говорить, что наше приложение было под 500МБ?
  • При деплое зип архива размером более в 500МБ деплоймент просто крэшился.
  • Все пакеты аккуратно складывались в sqlite базу данных на сервере!!! Вы когда-нибудь видели sqlite базу на сотни гигабайт? Я — да. Как их оттуда можно было удалять — я не знаю, этот вопрос как-то решали сисадмины.
  • На сервере у апача были memory leaks. Ничего лучше кроме как рестарта сервера раз в месяц мы не смогли придумать. Процессы превращались в зомби. Причину не нашли.
  • Лицензионная политика. Вроде как лицензия давалась на количество хостов, поэтому чтобы сэкономить нам пришлось на некоторых хостах запускать несвязанные между собой приложения.
  • С логами апача тоже была отдельная проблема в связи с комбо безопасность + закон о защите персональных данных. В итоге доступа к логам из интерфейса ZS не было.


Искренне надеюсь, что они доведут свой продукт до ума. Мы же всё переделали на php/apache, ansible и jenkins и рады.
То есть Rogue уже не заинтересована не только в программных продуктах, но и в развитии самого PHP? Очень грустная новость. Впрочем, есть надежда, что желающих взять под своё крыло эту команду найдется предостаточно.
Насколько реальная мысль, что Facebook может пригласить их для развития Hack?
fb и wikipedia первые в списке
а можно сделать некоммерческую foundation и привлечь спонсоров
Зачем им Hack, если у них есть свой компилятор? Или Hack как-то использует «основной» PHP 7?
Делаю ставку на Badoo или Etsy
Не совсем понял. Права на PHP остаются у Rogue Wave Software, или ребята всем отделом забирают всё, кроме Zend Server и уходят искать спонсора на дальнейшую поддержку языка и не заинтересовавших Rogue Wave Software частей инфраструктуры?
Без одобрения они не смогут выполненную работу назвать PHP 8
Скажите в двух словах — PHP всё или еще не всё?
В очередной раз php уже всё, но пока еще не всё.
Я начинаю подозревать, что php уже больше не всё.
«поиск нового дома для этих проектов, чтобы обеспечить запланированный вклад в PHP 8 и дальнейшие версии» — среди российских компаний в предоставлении подобного дома жизненно должен быть заинтересован Битрикс)
Зачем Битриксу интересоваться развитием PHP, если ему хватает 5.3? :)
Ну со следующего года вроде минимальная версия 7.1, но зачем — не ясно.
Ответ банален — деньги. Чтобы занимать около 30% рынка CMS в России, их нужно было вложить немало. А чтобы дальше оставаться на плаву им также нужно интересоваться и развитием PHP. Кстати, с 7 версией цмска работает заметно шустрее
Звучит страшновато, мне нравиться писать на php, если на 5.6 я думал что время прекращать делать новые проекты на нем, а после 7.0 я отбросил все сомнения и продолжил с радостью работать на нем, перенеся все свои проекты на 7+. То, что происходит сейчас никогда хорошо не закнчивлось. Даже если ребят позовут всей командой перейти в другую компанию и ДАЖЕ если позволят продолжить работать в данном направление, то мы все равно увидим паузы в прогрессивных решениях, что удручает.
Перечисленные в статье люди работали над производительностью языка, а новые плюшки в основном добавлял nikic и сообщество в целом.

Так что не совсем так, кажется. Проблемы могут быть лишь с JIT и FFI (причём второе вполне себе стабильное уже решение, дело лишь за интеграцией в ядро).
Sign up to leave a comment.

Articles