Из того, что бывают монстры на php не следует, что это проблема монолитов.
Это проблема тех, кто их так написал. Сделать можно плохо на любом способе разбиения кода. И в случае микросервисов таких способов едва ли не больше.

И в чем эта "важная разница"? Пусть программисты накосячили в сервисе склада:
1) оркестратор перезапускает монолит по аварии.
2) перезапускается только сервис склада, а вся остальная система выглядит как поддельная елочная игрушка - с елки не падает, но радости не доставляет.

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

А откуда вообще следует, что микросервисная система (как система в целом) требует меньше памяти?
Там же в каждом сервисе коммуникационный код (хорошо если gRPC, а не комплект JSON-чиков), очереди какие-то, буфера и т.п.
Объем шаблонного кода огромен, под это в go даже генераторы пишут - одна кнопка и у программиста NN00 строк "болванки" микросервиса.

Требует даже больше. Но, тут в другом ещё есть нюанс же. С железом, чем больше памяти/ядер в одной железке - тем больше стоимость гига/ядра. Горизонтальное масштабирование по железу дешевле вертикального.

Но это не отменяет факта, что часто тупо дешевле железом закидать монолит, чем разводить микросервисы, и раздувать ФОТ и усложнять процессы.

Монолит, это всё в одном - допустим и управление счетами пользователя и новостями для сайта. Но зачем? микросервисы - это как раз про такое разделение ответственности - сервис управления счетами пользователя и сервис управления новостями для сайта.
Если дробить дальше, то это уже наносервисы получаются.
То есть, если вы начинаете дробить сервис управления новостями на сервис выгрузки новостей на сайт и сервис добавления/редактирования новостей, то вы перешли на наноуровень. Но он тоже вполне себе неплох - например, нагрузка для редактирования меньше чем для выдачи новостей на сайт - масштабировать можно меньше. Да и логику административного доступа можно вырезать из кода, а значит меньше делается проверок в коде

Часть сервисов не так критична для бизнеса - показ рекламных баннеров, построение отчётов для внутренней аналитики итп, если при их падении будет падать и основное приложение (пусть и на 10 секунд), для многих это неприемлемо. Скорость обнаружения аварии и реакции на неё зависит от системы мониторинга, а не монолит это или микросервисы

+

Viktor Alenkov (0) увеличил репутацию Ivan (1)

Я даже загрузку данных делаю в пайплайне из Кафки и 3-4 микросервисов. Кода так мало что разобраться в нем это 10 минут, соотвественно его легко протестировать/поддерживать и т.д. А ещё их можно запускать в какой нибудь aws lambda и жить без части серверов. Минусами едет достаточно сложная развертка, надо учиться писать логи _нормально_ чтоб их можно читать и трассировать. Пока так и не нашёл ту середину где сервисы достаточно микро но без эксплуатационных проблем.

Микросервисы очевидно требуют больше ресурсов.

Ну так делайте тесты, чтобы библиотеки не валились.

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


А потом у людей глючит половина сайта.

Быстро поднятое упавшим не считается, об удалении забытого позаботится GC :)

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

Тут же речь о том, что если процесс идёт через несколько сервисов - появляются саги/трейсинг/распределённые транзакции/eventual consistency/поддержка кластера Кафки и прочее, когда в монолите - это все решается куда проще. И в таком контексте - уже не все так сладко :)

ничто не мешает вам использовать сервис очередей синхронно - получите “монолит”
Так же, как в монолите можно использовать Event driven и получить асинхронность и разные контексты

монолит vs микросервис это не про это. Точнее, это не только про это

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

Ммм, распределённый монолит? Вот тут и проблема, что вбираются минусы обоих подходов :D

В рамках монолита, гораздо больше гарантий/атомарности из коробки. Отчеты так же делать проще. Куча всего делать проще.

По хорошему, микросервисы нужны только для:
1) Горизонтального масштабирования отдельных компонентов системы
2) Использование разных технологических стеков в разных компонентах системы
3) Как более простой вариант строго разграничивать «компоненты» системы, но это на самом деле можно и с монолитом сделать :)

Все остальное достижимо и в монолите, местами проще в реализации.

Просто нынче как-то любят монолиты недооценивать, и считают вообще чуть ли не матерным словом, а микросервисы переоценивать и возносить в абсолют. И основной посыл ровно в этом. Ведь всего-то инструмент нужно под задачу выбирать :)

> Ведь всего-то инструмент нужно под задачу выбирать
+

> Скорость обнаружения аварии

В теории, опять же - в теории. А на практике к сервисам, которые не критичны для бизнесов, это просто не прикрутили/забыли/не успели. Хорошо если health check есть.

Ну если в монолиту можно дать проваляться пол дня, PR-ы редкие, а суточные РПСы можно рассматривать по отдельности на дневном графике, то да. Монолит лучше подходит)