Комментарии 65
Ожидаемо. Проект фактически заглох еще в доковидные времена.
В чем проявляется "заглох"?
Сравните ченжлог за последние лет 5 с более ранним. Там по большей части багфиксы.
Парни (плотно) пилят http/3, между этим выпускают релизы. Поверьте мне, проект живее всех живых. Программисты NGINX славятся своей надежностью, тут ответственность, миллионы серверов где используется nginx.
Понимать надо (с)
тут не "хуяк-хуяк и в продакшен", ответственность, миллионы серверов где используется nginx.
и очень обидные баги и WONT FIX... Нынче envoy нормальная тема, а не nginx...
Простите. Не со зла. https://www.youtube.com/watch?v=v3Xqvy1jqio
и очень обидные баги и WONT FIX...
Список обидных багов, которые wontfix?
ну, я когда-то давно начал с reuseport. Когда он только появился. Потом вроде зафиксили, но время прошло. В этом они молодцы. Но, например, нормальный тест конфига в nginx не завезли как будто до сих пор. В моем кейсе nginx -t хватал трафик с рабочего инстанса. А как проверять конфиг без наличия ip на интерфейсе - очень интересный вопрос. Или без сертификатов.
Отдельная целая история - это модули, которые собраны по принципу - покупайте платный nginx, там все из коробки.
Грустно это все ))) опен сурс такой опен сурс
Но, например, нормальный тест конфига в nginx не завезли как будто до сих пор. В моем кейсе nginx -t хватал трафик с рабочего инстанса.
Как только о баге сообщили, так его и исправили: https://trac.nginx.org/nginx/ticket/1300
Между сообщением о баге и исправлением прошло несколько недель. Было это 5 лет назад. Как там, "ложечки нашлись, но осадочек остался"?
А как проверять конфиг без наличия ip на интерфейсе - очень интересный вопрос.
А в запуске nginx -t и нет необходимости. Если конфиг содержит ошибку, которую бы мог выявить nginx -t, то такой конфиг просто не будет применен и nginx продолжит работу со старым конфигом, сообщив об этом в лог.
Опция reuseport работает ровно так, как она работает в ядре.
Отдельная целая история - это модули, которые собраны по принципу - покупайте платный nginx, там все из коробки.
Все модули, которые были открытыми, так ими и остаются. Более того, постоянно прибавляют в функциональности и добавляются новые.
Модули N+ были написаны по многочисленным запросам от энтерпрайзных клиентов, которые готовы за них платить. Представьте себе, что если бы не эти модули, то не только их бы не было, но и не было множества другой, бесплатной функциональности, которую бы просто некому было писать. Разработчикам, которые работают полный рабочий день (а зачастую на самом деле даже больше) над одним проектом - тоже нужно кушать и кормить семью. Пожертвований, которые собирались до появления N+ - хватало только на оплату хостинга для сайта.
Грустно это все ))) опен сурс такой опен сурс
У вас есть и остается на выбор огромное количество бесплатных сторонних модулей, написанных и поддерживаемых энтузиастами - ни кто не запрещает продолжать ими пользоваться.
P.S. Любой написанный код - это чье-то время. Время человека имеет свою цену. Если человек пишет какой-то код в удовольствие, как хобби, то он просто сам неявно оплачивает это хобби из своего кармана. Чтобы иметь такую роскошь, оплачивать свое хобби, нужно уже иметь какой-то источник дохода. Странно, когда это нужно объяснять.
Странно, когда это нужно объяснять.
это все сложнее. Потому что эти компании, которые разрабатывают платный софт, точно так же на опенсурсе по сути делают бетатестинг своих продуктов. И никто комьюнити за это не платит. За баги тоже не платят. За код тоже не платят и я точно так же чисто по приколу репорчу баги и иногда фиксы какие-то предлагаю. Насколько могу. Самая беда здесь, что коммерческий софт точно так же предоставляется по модели AS IS. Никто ни за что не отвечает. Коллеги пользуются, например, энтерпрайз штуками а-ля RHEL и OpenShift - и там точно так же в баг трекере висят штуки годами, всем пофиг. А самое интересное, что действительно с этого корабля деваться некуда, потому что все продукты примерно одинаковы.
Вы абсолютно правы - в рамках опенсурса никто никому ничему не обязан. :-)
Самая беда здесь, что коммерческий софт точно так же предоставляется по модели AS IS. Никто ни за что не отвечает.
Любая ответственность и гарантии в договоре будут умножать прайс на N.
Коллеги пользуются, например, энтерпрайз штуками а-ля RHEL и OpenShift - и там точно так же в баг трекере висят штуки годами, всем пофиг. А самое интересное, что действительно с этого корабля деваться некуда, потому что все продукты примерно одинаковы.
Если вы готовы платить ту самую сумму, умноженную на N, то на такой случай есть предложение: "Designated Engineer" - среди прочего, там "Roadmap visibility, prioritization of bug fixes, and prioritization of feature requests".
Если вы готовы платить ту самую сумму, умноженную на N, то на такой случай есть предложение: "Designated Engineer" - среди прочего, там "Roadmap visibility, prioritization of bug fixes, and prioritization of feature requests".
интересный вопрос, на самом деле. С одной стороны, действительно звучит прикольно и как решение. А с другой стороны - там есть приоритизация фич, т.е. все равно никто не обязуется ее реализовать по вашему первому запросу. Может быть, если повезет. Ну, и очень интересно - вообще кто-нибудь этим сервисов пользуется? Я представляю себе только очень богатые компании из финтеха, но как показывает опыт - эти очень "богатые" компании вместо того, чтобы платить вендору почему-то пытаются выращивать свою внутреннюю компетенцию. Вот удивительно, да? Как думаете, почему?
Среди клиентов полно компаний из списка Fortune 500, в том числе из верхушки.
но как показывает опыт - эти очень "богатые" компании вместо того, чтобы платить вендору почему-то пытаются выращивать свою внутреннюю компетенцию. Вот удивительно, да? Как думаете, почему?
Это видимо СНГ опыт? Мой опыт говорит о том, что большинство американских компаний стремяться аутсорсить по максимуму любой непрофильный бизнес. Набирать людей и выращивать свою экспертизу - это капиталовложения, это время, которое упущено, это риски.
Вот взять, например, нашу историю успеха с компанией Audi. Им нужно решить конкретную задачу, а вы бы на их месте наняли команду, чтобы потратить годы на разработку своего WAF решения с нуля?
А с другой стороны - там есть приоритизация фич, т.е. все равно никто не обязуется ее реализовать по вашему первому запросу. Может быть, если повезет.
А вы попробуйте просчитать экономику такого предложения. Допустим, что у вас есть десятки тысяч платящих клиентов. Сколько должен заплатить один клиент, чтобы вместо реализации каких-то фич, необходимых для сохранения существующей базы клиентов и её умножения, бросить ресурсы на хотелки этого одного клиента? При какой сумме это будет экономически выгодно разработчику?
Среди клиентов полно компаний из списка Fortune 500, в том числе из верхушки.
ну, это же ничего не означает? Купи подписку редхат и попади в fortune 500 по скидке? Ну, не работает это так.
ну, все понятно. Инженеры F5 в треде. На месте Audi я бы провел стандартную процедуру для крупной компании - рассылку заявок по потенциальным вендорам и сбор их результата. Дальше открытый конкурс на основе критериев от заказчика для выбора победителя. И с тем же успехом мог бы победить, ну, не знаю... https://www.checkpoint.com/cyber-hub/cloud-security/what-is-web-application-firewall/ или https://www.imperva.com/products/web-application-firewall-waf/ Не одним единым F5. В конце-концов, есть в самих балансировщиках F5 WAF-функциональность, а я говорил чисто про nginx. /p.s. добавлю, что сами балансировщики классные - вот те, которые аппаратные или апплайенсы /
Сколько должен заплатить один клиент, чтобы вместо реализации каких-то фич, необходимых для сохранения существующей базы клиентов и её умножения, бросить ресурсы на хотелки этого одного клиента?
ну, я про это и говорю, но с другой стороны. Для заказчика, который не готов заливать деньгами какого-нибудь конкретного подрядоса, пропихнуть какую-то свою фичу или баг в верх списка практически нереально. И в этом аспекте возможно, что поиск какого-нибудь дешевого и вменяемого контрактора (а-ля EPAM) или организация in-house экспертизы будет иметь смысл.
Ну, и завсегда проблема - повторюсь, у крупных компаний типа редхат и vmware всегда есть куча багов в KB, которые не правятся годами. И хорошо, если ты на это не напорешься. На горячей линии поддержки могут работать индусы (ничего личного, это бизнес), которые будут футболить тикеты, пока ты не прорвешься до нормального инженера (здесь, кстати, личные связи с инженерным персоналом, или связи с менеджером по продажам могут помочь) и которому будет интересна проблема конкретного заказчика... Коллега буквально на днях рассказывал историю про включение ipvs в kube-proxy в опеншифт... воз и ныне там.
И еще накину. Вот возьмем Lyft. Именно они разработали envoy. Ну, вот не взяли они nginx. Какой у них профильный бизнес? С одной стороны, это не шаурмячная, а компания, которая занимается перевозками. С другой, это именно IT компания. Вот должны ли были они брать готовое решение или пилить свой велосипед? Надо сказать, что получилось достойно. Или SoundCloud, которые подарили миру prometheus? Я уверен, что коллеги из Ауди тоже могли бы разработать какую-нибудь полезную штуку и опенсурснуть ее в мир. Это могла бы быть какая-нибудь библиотека, дизайн-система или может быть целый комплекс, скажем, для CI/CD (пример уже есть - Spinnaker от Nerflix).
ну, это же ничего не означает? Купи подписку редхат и попади в fortune 500 по скидке? Ну, не работает это так.
Проблема в том, что большинство тех самых крупных компаний, о которых вы писали, очень чувствительно и строго относятся к раскрытию поставщиков своих решений, а потому со стороны не видно кто и у кого что покупает.
На месте Audi я бы провел стандартную процедуру для крупной компании - рассылку заявок по потенциальным вендорам и сбор их результата. Дальше открытый конкурс на основе критериев от заказчика для выбора победителя.
Почему вы думаете, что они так не сделали, если по ссылке прямым текстом написано "After an initial vendor investigation process, there was only one security solution that ticked all the boxes".
ну, я про это и говорю, но с другой стороны. Для заказчика, который не готов заливать деньгами какого-нибудь конкретного подрядоса, пропихнуть какую-то свою фичу или баг в верх списка практически нереально.
Обычно речь идет о суммах, когда просто берут и покупают компанию целиком. И такое, кстати, тоже регулярно происходит. Вот как недавно с Activision Blizzard. Думаете у Microsoft нет компетенций для разработки таких же продуктов? Но зачем, если проще и быстрее купить готовую компанию.
Ну, и завсегда проблема - повторюсь, у крупных компаний типа редхат и vmware всегда есть куча багов в KB, которые не правятся годами
Равно как и у мелких. Какая-то банальщина. Багов нет только у тех продуктов, которыми никто не пользуется. Срок прошедший с момента обнаружения бага - это не критерий для приоритезации его исправления. Кто-то предпочитает заниматься исправлением багов в хронологическом порядке?
А ещё баги, как минимум, делятся на известные и неизвестные, и последние, как правило, хуже и неприятнее. Баг в KB - это уже более хороший баг.
Вот возьмем Lyft. Именно они разработали envoy.
...
Ауди тоже могли бы разработать какую-нибудь полезную штуку и опенсурснуть ее в мир.
Если бы могли бы - разработали бы. Многое упирается в кадры, кадры помноженные на время. Если в Lyft нашлась команда людей, которые смогли придумать и реализовать на должном уровне, да ещё у них было на это время и бизнес-воля у менеджмента - они это сделали.
Я понимаю, что в комментариях каждый второй бы свой nginx без проблем написал и повторил бы историю успеха на раз-два, но только, как правило, времени нет, и поэтому больше трети интернета предпочитает запускать на фронтенде вполне конкретный nginx.
Вы сейчас что хотите доказать? Что nginx нужен? Что надо им пользоваться ? Или что?
Несомненно, для Вас, для Игоря тот факт, что nginx используется третью сайтов (я, кстати, критиковал эту метрику, потому что интереснее, наверное, посчитать трафик, причём не только внешний, но ещё и внутренний, и коллега ниже был согласен со мной) - это действительно крутое достижение и Вы молодцы. То, что nginx сформировал целую экосистему - это тоже круто. И даже при помощи него и немножко lua неоднократно делали троллейбус из буханки. Как и с любым другим инструментом. Но факт в том, что время меняется. Задачи тоже. Апач и IIS тоже когда-то давно конкурировало друг с другом. И лидерами становятся другие...
Я очень рад за ваши успехи, но как бы успехи в бизнесе и качество (в каких-то абсолютных единицах) - вещи абсолютно ортогональные. И поэтому, ну, получается спор ни о чем. Вы там аппелируете к форчун500, но это очень похоже на простой факт, что лучше быть богатым, здоровым и молодым, чем старым, бедным и больным.
Если что - никакого негатива не держу, всех благ и хорошего Вам настроения )))
P.s. Если думаете, что я негативистки мыслю - нет. Просто точки зрения могут быть разные, а мир больших денег вообще особый. Сколько было скандалов вокруг Гугл-ФБ с обработкой ПД и прочего. Или взять Дизельгейт... поэтому я бы не стал просто меряться успехом в форчун500 или любой другой сходной метрикой.
Вы сейчас что хотите доказать? Что nginx нужен? Что надо им пользоваться ? Или что?
Вы озвучили в комментах некие претензии и я на них ответил. Я не вижу никакого смысла спорить. Это как спорить с человеком, который сидя в лесу и наблюдая несколько деревьев вокруг себя - считает, что весь остальной лес абсолютно такой же.
Если думаете, что я негативистки мыслю - нет. Просто точки зрения могут быть разные, а мир больших денег вообще особый.
Проблема в том, что наличие точки зрения не означает, что её нужно высказывать в любой удобный момент и по любому поводу.
Тут негативные комментарии про nginx есть не только от вас. Видимо все эти комментаторы считают, что данная новость о его авторе - это отличный повод, чтобы как-нибудь пнуть его детище, а не просто поблагодарить за работу и вклад, который он сделал. Или промолчать и пройти мимо, оставив свою точку зрения при себе.
Проблема в том, что наличие точки зрения не означает, что её нужно высказывать в любой удобный момент и по любому поводу.
Точку зрения можно высказывать где угодно, как угодно и какую угодно. Реагировать на нее вам или кому-то другому это ваше или их дело. Вот и все, нет никакой проблемы.
Данная новость отличный повод еще раз обсудить роль nginx в современном мире. Вот люди и высказываются, что детище важное, но начинает уступать другим по вполне объективным причинам. С чего вдруг об этом нужно молчать и проходить мимо. Важный вклад автора проекта от этого никуда не денется.
Согласен, что может быть не совсем удачный пример. Я не разбираюсь в игровой индустрии, просто новость на слуху.
Но вот F5, например, тоже чуть ли не каждый год покупает по 1-2 компании и тут речь об авторских правах точно не идет. Так из приобретений только за последние пару лет: Shape Security, Silverline, Volterra,Threat Stack.
https://trac.nginx.org/nginx/ticket/1311
https://trac.nginx.org/nginx/ticket/1151
актуально для https://github.com/kubernetes/ingress-nginx/issues/2948
Я чего не вспомнил сразу - думал, что это уже решено сто лет в обед, но похоже, что нет.
Там же написано, почему предложенный патч работать правильно не будет. И если в ядре нет хорошего решения, то его нет.
Отдельно интересно услышать, а каким образом это "очень обидный баг", ибо по сути это настолько мирооптимизация, что даже на бенчмарках измерить разницу от точно выверенного выставления affinity и числа рабочих процессов не так уж просто.
и очень обидные баги и WONT FIX…
можно примеры?
а сами поищите по trac.nginx.org Помогу немного, пришлось поколдовать над трекером.
https://trac.nginx.org/nginx/ticket/237 -> например, на мой взгляд, актуальная штука. Ей сделали reopen, но воз и ныне там.
Кстати, с гитлабом или докером та же фигня - куча ишью висит в открытых и по нескольку лет никакой активности. Зато вот в кубере все просто - нет активности месяц, тикет досвидос ) В целом, разработчиков могу понять, потому что открытые тикеты, по которым нет активности, непонятно вообще, надо делать или нет. Если тикет не нужен автору (reporter'у), то и разрабам он нафиг не уперся... Главное, чтобы процессы были прозрачные и понятные, а не так, что открыли новое репо и "обнулились" как Император
А какой новый функционал вы бы хотели видеть в подобном веб сервере, кроме поддержки новых протоколов и багфиксов?
Как минимум стоило бы продолжить процесс передачи наработок из "commercial subscription" в комьюнити. Я не говорю, что все нужно сделать бесплатно. Ничего не имею против nginx+. Я лишь говорю, что процесс должен быть непрерывным, иначе иначе все уйдут к конкурентам, у которых эти фичи уже в базе.
В противном случае nginx останется лишь на фронтенде для терминации ssl и раздачи статики.
Вы же понимаете, что тем более зрелый продукт, тем меньше у него ченжлог? Это, как бы, нормально.
Я бы не хотел в своем продакшене использовать систему, у которой релиз каждые две недели с ченжлогом из нескольких десятков ченжей и фиксов.
С точки зрения админа, да, продукт с минимальным ченжлогом удобен в проде. Но! Я уже знаю целый пласт админов, которые предпочли envoy nginx-у. Подозреваю, что другие конкуренты тоже не дремлют.
С точки зрения разработчика api nginx достаточно сложен. Фактически все сторонние модули (за редким исключением) позиционируются как поделки и не заслуживают доверия. А жаль.
Ну и в конце концов, если твой проект не генерит фичи, то он явно не очень интересен его разработчику. По крайней мере я не сталкивался с обратным. Сысоев вроде как давно отошел от непосредственной разработки в менеджмент, но, видимо, не зашло.
Предпочли проксю веб-серверу? O_o
Я же правильно помню, что Envoy - это edge/middle/etc proxy? Service mesh, Istio т.д. Или текст выше был конкретно про nginx-service-mesh?
Кстати, если говорить о развесистых API, то там, где nginx начинает доставлять неудобства, уже давно люди используют тот же Kong, к примеру.
А много кто использует nginx именно как веб-сервер? Для чего? Сейчас повсеместно все написано на джавах, го, джаваскриптах, питонах и прочих, где внутри свои серверы. Нджинкс он и есть прокси, это основное его применение сколько я его помню. И сейчас его ткают в тот же кубер именно с той же целью. В этом плане он очевидно начинает уступать более современным решениям. Есть envoy, мы вот traefik гоняем. Сложность и неудобство конфигурации я читал уже неоднократно. Dropbox хороший бложик писал по миграции с nginx на envoy https://dropbox.tech/infrastructure/how-we-migrated-dropbox-from-nginx-to-envoy
Джавы джавами, а статику-то как сервить?
Не знаю как это в мире джавы делают (там скорее какой-нить tomcat будет). В мире Go, например, очень часто статику им же и сервят. Нода думаю не исключение. Зачем для этого nginx. Лишняя прослойка и гемор. Если у приложения ничего кроме статики нет или это SPA какой-нить - ну да, там nginx хватит простого.
Но «на круг», отдавать статику конечно же удобнее nginx и его собратьями. Тем более очень часто это физически/географически другой сервер.
а еще есть штуки типа varnish - которые говорят, что очень неплохо ускоряют отдачу данных... и никакого nginx :-) Естественно, это чисто кэш
выкидывают на какое-нибудь minio или s3
В больших проектах внешний трафик составляет не более 5-10% от всего http трафика проекта.
Если nginx и дальше будет развиваться такими темпами, то в ближайшее время nginx останется только снаружи. Конкуренты же вытеснят его из внутренних коммуникаций.
Выставлять Go наружу с его вебсервером такое себе дело. Nginx сверху ставят для терминирования TLS, limit rate, балансировки трафика etc. Те ровно то, что в нем хорошо работает. Traefik, написаный на Go, как бы ни смешно звучало, не сможет заменить Nginx на проектах с реальным трафиком. Если сравнивать именно перфоманс, то HAProxy опережает Nginx, но, в силу привычки и менее удобной конфигурации, часто на это закрывают глаза.
Что касаемо Envoy, то он сложен в конфигурировании (опять же сравнивая с Nginx), и в нем куча отдельных компонентов, см тот же https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_features/global_rate_limiting.html. Те мало его засетапить, нужно и сбоку еще какие-то сервисы городить да еще и с REDIS. Те стоимость владения, усложнение эксплуатации и неочевидные точки отказа. Хотя кого это пугает, все с тормозов давно слетели и без k8s даже локально ничего поднять не могут:)
Как раз это куда лучше, т.к. написан он безопасном языке и его реализация стека уже проверена временем. В том числе реализация TLS, где у nginx используется корявый openssl. А бенчмарки говорят, что traefik запросто тягается с nginx, haproxy и envoy.
Envoy хотя бы понимает grpc, что для многих компаний сегодня очень важно. От прокси нужно наличие API, чем как раз отличаются envoy и traefik и чего нет у nginx.
По ссылке у вас все логично - адекватный рейт лимит не реализовать без внешнего общего хранилища. Самый стандартный паттерн это вот как раз поставить сбоку клатер redis, который сможет принять дофига нагрузки, и кучу инстансов проксей, которые смогут адекватно держать лимиты вместе. Судя по всему, nginx ничего подобного не умеет, что для меня лично бы сделало его непригодным для этих целей. Envoy при этом умеет local rate limit, когда редис не нужен и все работает как у нджинкс - лимиты исполняет каждый инстанс сам в изоляции от остальных. Если нужно бложик закрыть проксей, то нджинкс сгодится наверное. Если нужно принять дохера трафика, балансировать и рейтами покрыть его, то очевидно нужно что-то более адекватное типа envoy как раз.
Те мало его засетапить, нужно и сбоку еще какие-то сервисы городить да еще и с REDIS.
на nginx тоже придется что-то типа redis или lua притаскивать,@crekerниже все правильно говорит.
А еще отдельная боль - собирать метрики с nginx. Что там сейчас нынче модно? vts module?
Хотя кого это пугает, все с тормозов давно слетели и без k8s даже локально ничего поднять не могут:)
ой, это тоже смешно. Буквально на днях статью видел с критикой Linux и куда делись такие классные штуки как FreeBSD. https://habr.com/ru/post/646073/ Вот она современная индустрия. Linux стал по сути стандартом. Как бы хорошо или плохо это не было. Кубер тоже становится стандартом.
https://news.netcraft.com/archives/2022/01/17/january-2022-web-server-survey.html
Заглох? Так-то даже за последние 30 дней у Nginx +0,22% к market share по активным сайтам.
ага-ага, а там же в статье:
nginx lost 7.33 million sites this month (-1.91%) but continues to be the most commonly used web server with 32.3% of all sites using it. Although nginx’s share has fallen, Apache is still more than eight percentage points behind after losing 3.70 million sites (-1.31%), which has taken its own market share down to 23.9%.
т.е. убыль -1.91%...
Проект вышел на новые рынки. Например вот
и никто ими не пользуется, лол, а есть и используются nginx как ingress, то комьюнити версию - https://kubernetes.github.io/ingress-nginx/
In a CNCF survey, nearly two‑thirds of respondents reported using the NGINX Ingress Controller, more than all other controllers combined – and NGINX Ingress Controller has been downloaded more than 10 million times on DockerHub. Combining the speed and performance of NGINX with the trust and security behind the power of F5, NGINX Ingress Controller is synonymous with high‑performing, scalable, and secure modern apps in production.
а это простите вообще какая-то дичь на оффсайте nginx.. Опять попутали как будто nginx ingress controller и f5 nginx ingress controller.
Ну кто им пользуется я знать не могу. Очевидно они здесь давят на тот факт, что если вы типа сидите на nginx платном, то смотрите, все юзают ингресс nginx. Переходите и на платный ингресс. Он там как минимум WAF в себе содержит, за что они деньги и просят, что в общем-то, штука важная для энтерпрайза.
Начинания то правильные. Включились в самые хайповые направления. Правда сейчас набирает популярность eBPF в этом месте и тут вроде nginx предложить нечего. Не вижу упоминаний по крайней мере.
проблема в том, что это пыль в глаза и выдавание желаемого за действительное. Я спецом проверил - та же статистика с докерхаба вообще нерелевантна, т.к. тот же комьюнити ингресс (который РЕАЛЬНО популярен) скачан неизвестное количество раз, потому что образ там на k8s.gcr.io/ingress-nginx/controller
Правда сейчас набирает популярность eBPF в этом месте и тут вроде nginx предложить нечего
цилиум сейчас интегрирует envoy внутрь себя с ebpf и это будет концом для service mesh типа Istio в текущем виде с сайдкарами и для nginx.
Он там как минимум WAF в себе содержит, за что они деньги и просят
да херовый там WAF, если честно. Вообще не слышал про нормальные WAF от F5 или, в частности, внутри nginx. Если надо - есть отдельные wallarm вроде https://www.wallarm.com/solutions/waf-for-kubernetes НО ОНИ ТОЖЕ НА КОМУНИТИ ВЕРСИИ построены, а не продукте Ф5. Удивительное дело, да?
Опять же, это все с позиции нас, кто видит не дальше своего носа. Нужно смотреть, что творится в энтерпрайзах. Для этого можно, например, залезть в отчетности и доклады инвесторам. Отчетности к сожалению не выделяют nginx продукты, все в сумме, что ожидаемо. Презентация - общия слова. Зато транскрипт https://www.fool.com/earnings/call-transcripts/2021/07/26/f5-networks-inc-ffiv-q3-2021-earnings-call-transcr/ содержит много полезно и из него вполне видно, что nginx продукты пользуются спросом у больших клиентов и за счет этого у F5 продолжается рост.
в энтерпрайзах вообще отдельный мир - там много где кубера, например, нет. Или есть решения F5, но без nginx. Сложно короче. А еще как считать - по объему контрактов? Или по количеству инсталляций? Если первую метрику еще хоть как-то из открытой финансовой отчетности можно получить, то вторую вряд ли. Или может все-таки по объему трафика посмотрим? Но тогда вообще окажется, что половина трафика интернета вообще у какого-нибудь нетфликс или cloudflare с их freebsd и чем-то самописным (немножко спекулирую)
половина трафика интернета вообще у какого-нибудь нетфликс
У Netflix действительно большая доля трафика благодаря CDN, которую им NGINX, Inc. помог построить с нуля. Заодно и FreeBSD подтянули.
Ждём nginx-ng
Это Unit.
Там пишут вебсайты на assembler!
https://www.nginx.com/blog/nginx-unit-adds-assembly-language-support/
@johnfound, это Вы?
Печально, что при уходе Игоря вспоминают сейчас МВД и Lynwood, а не реально много того, что он сделал. Internet Powered by Nginx
несомненно - он сделал очень важные две вещи.
он изменил подход к написанию софта. Когда nginx начинался - вся эта история с event loop была в новинку и прям очень хорошо зашла. Сейчас этим никого не удивишь
при помощи его продукта nginx мы решили кучу своих задач, за это большое спасибо.
Но тем не менее - у любого продукта есть рождение, зрелость и закат. И опять же повторюсь, что значение nginx сейчас падает. Если б все было хорошо - не пришлось бы компании Lyft разрабатывать свой envoy :-)
Игорь Сысоев покинул компанию F5 Networks и проект Nginx