Про микросервисы

На одной из ранних работ у меня был огромный монолит. Это был 2019, микросервисы уже активно использовали, но тому продукту было лет 10. Огромная база данных. Хранимые процедуры, которые мы постепенно убирали, переводя в код приложения. Разбираться было тяжело, а еще было грустно, что не работаешь с модными молодежными микросервисами. Тогда у меня сложилось ощущение, что монолит == легаси.

На следующем месте я уже писала микросервисы во всей красе: с синхронным и асинхронным взаимодействием, со своими библиотеками, и была счастлива😊

На ютубе есть канал про архитектуру { между скобок } (не реклама, с удовольствием смотрю сама), один из форматов видео — обсуждение книг. Недавно я посмотрела плейлист про книгу Сэма Ньюмана «От монолита к микросервисам». Первое видео очень интересное, гостем был Филипп Дельгядо. Моменты, которые обсуждали в этом видео, совпали с моим опытом как разработчика и лида, поэтому записала их и решила поделиться.

Основные принципы микросервисов согласно книге:
1️⃣ Независимый деплой
2️⃣ Нейтральны к технологиям
3️⃣ Общаются между собой по сети
4️⃣ Выстроены вокруг бизнес-домена

Плюсы микросервисов по Сэму Ньюману:

➕ Система становится более отказоустойчивый

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

➕ Масштабируется разработка — много разработчиков могут разрабатывать разные сервисы.

Поддерживаю, удобно параллелить работы.

➕ Меньше контекста — удобнее держать в голове, разработчик повышает экспертизу в бизнес-домене.

Тоже перекликается с моим опытом. Для решения конкретной задачи разобраться в одном микросервисе и его БД проще.

➕ Свобода в выборе технологии

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

В выпуске затронули интересный момент. Представим компанию, в которой есть внутренние продукты, каждый продукт имеет один публичный API, а внутри часто построен на микросервисах. Важно следить, чтобы другие системы компании могли ходить только на публичный API, а не на API отдельных микросервисов вашего продукта, когда им надо что-то точечно.

➕ С микросервисами проще выстраивать структуру в организации.

В выпуске это очень здорово сформулировали:
в случае ответственности команды за какой-то модуль в монолите это бывает сложно показать бизнесу. Когда же есть микросервисы — материальные объекты, единицы деплоя — показать это бизнесу становится проще. Микросервисы позволяют сделать очевидным деление на зоны ответственности. Делают связь организационной структуры и структуры продукта более наглядной.

Ведущие и Филипп отметили и другие плюсы:

➕ Микросервисы позволяют реализовать разные нефункциональные требования в рамках одного продукта.

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

У меня в продукте есть база с персональными данными пользователей, с ней работает отдельный микросервис, со своими требованиями.

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

➕ Микросервисы упрощают архитектурный надзор. В монолите сложно отследить, что кто-то напрямую пошел в БД в таблицу из другого модуля вместо работы через сервисы (может помочь ArchUnit — Java/C# библиотека для проверки архитектуры кода).

➕ Легче найм, так как есть ассоциация монолит — легаси.

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

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