От микросервисного монолита к оркестратору

Источник: Блог Александра Бындю

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

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

Этап №1. Монолит

1.1 Характеристики

Обычно монолитную архитектуру можно описать так:

• Единая точка разработки и деплоя
• Единая база данных
• Единый цикл релиза для всех изменений
• В одной системе реализовано несколько бизнес-задач

Погружение в контекст: - Pattern: Monolithic Architecture - Бизнес-гибкость через микросервисную архитектуру - Don’t start with a monolith

1.2 Проблемы

• Система единая, при этом решает много разных бизнес-задач. Разные бизнес-задачи развивают разные подразделения компании и двигаются с разной скоростью. Отсюда возникает проблема с взаимозависимыми релизами разных подразделений, когда все ждут самого медленного.
• Сложно масштабировать бизнес-приложения, которые объединяет монолит. Это приводит к тому, что не учитываются особенности каждого приложения, и масштабирование делается неэффективно.
• При выборе технологического стека для новой бизнес-задачи приходится подстраиваться под среду разработки монолита, хотя этот выбор не всегда является наилучшим.
• Система уходит в релиз целиком, поэтому должна быть протестирована целиком. Это приводит к сложному регрессионному тестированию, затягиванию процесса тестирования и репотинга багов всем поставщикам изменений, замедлению скорости релизов, и, соответственно, увеличению времени time-to-market.