Кто только не писал о микросервисах! Я не писал - исправляюсь. Наипервейший первый первоисточник по этой теме - статья М. Фаулера и Дж. Льюиса от 25 марта 2014г. У нас тема появилась примерно через год после этого. На протяжении последующих 5-6 лет были популярны версии о том, что же такое микросервисы: - Это обычные сервисы, только маленькие. - Это сервисы, код которых умещается на один экран. - Это сервисы, которые разработчики могут написать за спринт (обычно 2 недели). - Да просто еще один термин придумали. - Это SOA сервис, но в docker. На вопросы "что такое маленький?", "маленький плюс 100 строк кода - это все еще маленький или уже нет?", "чем маленький/быстро написанный сервис отличается от обычного сервиса в рамках концепции SOA?", "разработчик какой квалификации должен уложиться в две недели?", "если тот же код запустить вне докера - уже не микросервис?" внятных ответов не поступало. Версии эти несостоятельны. Нет определений, четких границ, разделяющих понятия, или определения сформулированы в относительных координатах - у каждого своих. Подобные интерпретации можно встретить и сейчас, но значительно реже.

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

Вспомним, как тема микросервисов "заезжала" на наш рынок. К этому времени в отрасли накопились как организационные проблемы "долго/дорого", так и технические проблемы, связанные с масштабированием решений. Если приложения еще хоть как-то можно было масштабировать горизонтально, особенно если они были stateless, то СУБД были настоящей проблемой при растущем бизнесе. Либо вертикальное масштабирование - дорогие, мощные машины (+ резерв), которых хватало только на некоторое время, либо кластерные решения от вендоров с очень дорогими лицензиями и недостатком квалифицированных специалистов для сопровождения на рынке. Обычной экосистемой в корпоративной среде того времени была Waterfall + SOA + SOAP + XML + SQL + ESB + манолиты + ручное развертывание + централизация + платформы. Когда принесли очередное "наше всё" - Agile/Scrum, внезапно выяснилось, что с ним в одном флаконе шли REST + JSON + контейнеризация + микросервисы + DevOps + CI/CD + децентрализация + облака. Иногда еще были Spring и NoSQL, включая In-memory. Это была новая экосистема, а поскольку бизнес ринулся в продуктовую трансформацию, она довольно быстро вытеснила старую.

Одним из главных преимуществ МС было то, что функционал системы можно разделить между отдельными командами и ускорить разработку. Это история не техническая, а организационная. Техническое преимущество тоже было - появилась возможность горизонтального масштабирования в том числе баз данных без адских затрат. Для обеспечения слабой связанности между МС требовалось в пределе обеспечить каждый из них собственной если не базой данных, то хотя бы схемой. Отдельную схему при необходимости можно перенести в отдельную БД на отдельных не очень больших мощностях. Правда за это пришлось заплатить...

Продолжение https://t.me/itarchmind/44