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

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

Неудобство управления этим «зоопарком» привело к тому, что появились огромные монолитные системы типа Enterprise resource planning (ERP). Их преимущество было в том, что они предложили работу по принципу «одного окна». Стали не нужны множество мелких инструментов, появился универсальный огромный колосс, который сделает всё, что нужно на вашем предприятии. Его можно бесконечно расширять функциями, которые должны быть устроены по его подобию, и которые делают его ещё больше, и благодаря которым он всё глубже пускает корни в вашу компанию.

Такой подход имеет ряд недостатков:

1. Доставка бизнес-ценности происходит довольно медленно, потому что монолитная система должна быть целиком согласована, целиком протестирована, целиком выпущена в релиз. В таких системах релизный цикл может быть 6–12 месяцев, что для современных скоростей считается очень медленным.

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

Эти две проблемы тормозили развитие компаний, потому что их невозможно обойти в рамках архитектуры монолита. Отвечая на эти проблемы, разработчики и IT-архитекторы снова начали возвращаться к идеям создания небольших сервисов, каждый из которых отлично решает свою маленькую бизнес-задачу. Они называются микросервисы.

Этот подход очень похож на то, с чего всё начиналось, когда было много независимых утилит. Разница в том, что сейчас более развиты технологии инфраструктуры, где разворачиваются микросервисы. Инфраструктура и подходы к её созданию готовы выдержать сложность управления сотнями таких сервисов. Кроме этого, сильно продвинулись вперёд принципы проектирования классов и сборок, принципы построения IT-архитектуры, модульного и интеграционного тестирования, логирования и мониторинга. Всё это дало ключ к управлению сложностью микросервисной архитектуры.