Микросервисная архитектура и SOA: подборка статей

Первый вопрос - не «как нарезать», а «нужно ли резать».

Модульная архитектура даёт значительную часть выигрыша от разделения без платы за сеть и распределённую эксплуатацию, и для многих команд она остаётся правильным конечным состоянием, а не переходным.

Решение принимается по двум свойствам системы: насколько её части зависят друг от друга (связанность) и насколько каждая часть цельна по смыслу (связность).

Если резать систему, у которой высокая связанность, получится распределённый монолит: те же зависимости, но теперь через сеть.

Когда решение резать принято, всё сводится к тому, по какой линии.

Технически граница проводится где угодно.

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

Поэтому разговор о микросервисах быстро превращается в разговор о бизнес-процессах - и это правильный поворот, а не отклонение от темы.

Самое частое заблуждение - считать, что шина и микросервисы конкурируют, и надо выбрать одно.

Это разные вопросы: ESB отвечает за то, как системы обмениваются данными, микросервисы - за то, кто владеет функциональностью.

Компания с микросервисами может нуждаться в шине сильнее, чем компания с монолитом, просто потому, что точек обмена стало больше.

Возражения разработчиков против ESB при этом обычно не про технологию, а про то, что шина становится узким местом принятия решений.

Это лечится границами ответственности, а не отказом от инструмента.

Разделение системы на сервисы увеличивает число точек, где данные пересекают границу доверия.

Модель Zero Trust отвечает на это тем, что перестаёт считать внутреннюю сеть безопасной по умолчанию. И последнее, что стоит посчитать до решения, - полная стоимость владения.

Она включает не только разработку, но и эксплуатацию, дежурства, инструменты наблюдаемости и время команды на согласования.

Чаще всего именно этот расчёт закрывает спор.