От монолита к микросервисам. Как упростить и ускорить работу онлайн-магазина продуктов

Опыт «Утконоса».

От монолита к микросервисам. Как упростить и ускорить работу онлайн-магазина продуктов
2020

Хоть бы кто уже признал, что микросервисы - это не для скорости и надёжности, а просто потому, что не получается найти достаточное количество грамотных разработчиков на одной платформе и приходится скрещивать ужа с ежом: тут пять человек пишут на Go, там десяток на PHP, здесь ещё несколько на Котлине и так далее.
Что, скорость? Вы всерьёз считаете, что взаимодействие по сети, через шину, со всеми задержками tcp-стека будет быстрее обмена данными внутри одного процесса?
Надёжность? Падение любого из сервисов точно так же ломает работу системы, только теперь надо ещё отслеживать работоспособность шины, доступность сети и всех обвязок типа кубернетеса.

Простота? Да куда там, если теперь сервис теперь должен ещё реализовывать логику «а что делать, если обмен не прошел», саги и прочее.

400 человек на один проект? Кровь из глаз. Времена, когда мы всемером написали полноценный интернет-банк (включая обвязки со стороны банковской системы и других внешних компонент) предстают уже просто сказочной эпохой какой-то.
Управление интернет-магазином сложнее банка? Не уверен, но предположим. Но уж точно не в 50 раз.

2

Всё циклично, сначала пилим, потом клеим, потом снова пилим.
В процессе узнаём много нового и изобретаем интересное, а там раз и пенсия не за горизонтом))

Помню те прекрасные времена, когда наоборот всё загоняли в монолит с той же аргументацией, сейчас децентрализация и микросервисы, что будет дальше, догадаетесь ;)

1