Хватит делать МИКРОСЕРВИСЫ / Почему микросервисы — ЗЛО?

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

00:00 Вам не нужны микросервисы
00:30 Микросервисы -- это плохо
03:34 Микросервисы -- это хорошо
05:51 Перед тем, как решать -- лучше подумать

Автор: Александр Шишенко
Редактор: Анастасия Некрасова

[RussianITGuy]

Расскажите, что вы применяете на практике и какие ещё недостатки и достоинства обоих подходов вы видите!

[vladimirblagin]

У монолитной архитектуры много больше проблем, чем вы озвучили. Часть озвученных "проблем" микросервисной архитектуры аля "а у них протоколы разные" проблемы проектирования, разработки и тестирования, а не микросервисов. Сложности развертывания - это прямая задача автоматизации для DevOps. Микросервис должен развертываться командой в каком-нить Jenkins, а вся инфраструктура развертывания расписана заботливым DevOps (который любит все сделать настолько железобетонно, чтобы больше отдыхать, чем работать).
Чаще всего монолит упирается в лавинообразную сложность разработки при сколь-нибудь серьезном функционале, особенно, когда над монолитом работают все новые и новые разработчики. Понять там где ядро уже становится невозможно и монолит начинает обрастать костылями, новоделами и багами, багами, багами, как затонувший на мелководье Титаник ракушками. И спасти эту ситуацию, как правило можно только попилив монолит на части, и научив эти части коммуницировать. Ну а остальное к этому распиленному Титанику дописывать в микросервисном стиле.
Так что, если у вас серьезный масштабируемый проект на web, а не десктопный редактор иконок, то никаких монолитов там быть не может. Делайте сразу функциональную декомпозицию на сервисы, выбирайте правильную шину данных и брокер сообщений и пилите на этих рельсах маленькие понятные приложения. Микросервисы.
PS.
Чтобы ответить на вопрос, что лучше микросервисы или монолит ответьте себе на простой вопрос: Что лучше, знать все устройство огромного приложения, все его классы общего назначения, неявные протоколы кем-то когда-то спроектированные и не описанные в доках или наоборот описанные в километрах манов, разбираться в сложном взаимодействии работы большой команды над большим монолитом или ... знать единый протокол взаимодействия всех приложений в системе и не зависимо ни от кого работать над маленьким понятным приложением, интерфейсы взаимодействия которого с общей шиной данный понятны и прозрачны? Еще проще вопрос: какой приложение проще осмыслить и разрабатывать большое или маленькое? Все остальное - это инфраструктурные вещи, которые касаются не разработчика, а DevOps.
PS.
А вообще сравнивать монолит и микросервисы настолько же некорректно как сравнивать разработку web-систем и десктопных приложений. У каждого приложения свой набор технологий. И там, где живут микросервисы - в сложных, часто распределенных, системах на web (internet/intranet не важно), там говорить о монолитах просто неуместно.

[dennykolesnikov]

Если бы я посмотрел это видео вчера, сегодня у меня была бы новая работа (спасибо, видео и объяснение просто отличные)

[comrad]

у нас в проде сейчас гибрид - бизнес логика в джанго-монолите, а МЛ вынесен в сервисы. Запихивать огромные модели в джангу было бы слишком больно для всех

[viktor__]

смотрю на 1.5 скорости иначе уснуть можно. Єто единственний минус. А так все супер !

[dennykolesnikov]

Если Джанго, рельсы и т.д. - монолитные Фреймворки, какие можно отметить как самые популярные для построения микросервисов?

[FigisBadralov]

Протоколы - это что? gRPC?
Предлагаю еще быстрее - Oracle/Delphi/Windows/RDP
На PL/SQL делаете REST c json и клевый сайт.
Делается за неделю. База делается за полдня. Админка еще полдня. И вперед раскручивать!

[petr_e]

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

Точку зрения, что технические решения должны принимать технические спецы, поддерживаю.

[panamadreams]

1:27 Да да. Я тоже пишу приложение на делфи, и сервер для обновления и обмена информацией на Python. Ох блин, какой же геммор подружить их по HTTP. Написать там, потом написать там. На разных языках, с разными подходами, потом все это протестировать... Это реально сложно и объемно.