Внезапно очень хорошая книга. Внезапно, потому что в названии книги явно говорится, что она про построение микросервисов, хотя на самом деле она скорее о построении программных продуктов разного размера и о том, какие трансформации необходимы в том случае, если мы хотим, чтобы над одним продуктом могли эффективно работать большое количество людей.
При этом значительное число предлагаемых практик, советов и рассуждений полезны и для компаний нашего размера, где микросервисы были бы только вредны (в том числе советы не использовать то-то и не лезть туда-то, если вы маленькие и у вас нет проблем, для решения которых это то-то и туда-то придуманы)
Автор начинает с рассуждений зачем вообще нужны микросервисы и какие альтернативы им есть — монолит, модульный монолит, распределенный монолит. И сразу выделяет главное, для чего в принципе нужны микросервисы — возможность независимого развития и деплоя. Если у вас много команд и необходимо, чтобы отдельные команды могли независимо развивать свою часть продукта и независимо его деплоить, уменьшая вероятность сломать и задеть прочие части продукта — то микросервисы вам вероятно нужны. Если команд у вас мало и вы маленькие — надо обязательно оценивать повышенные расходы на поддержание микросервисов — как инфраструктурные, так и организационные и когнитивные — и думать, перевешивают ли они ожидаемые бонусы.
Автор не скупится на описание минусов микросервисов (тем более что потом всю книгу будет описывать в основном плюсы):
— С ними сложнее работать разработчикам — развернуть локально систему из большого числа микросервисов практически невозможно
— Поэтому же микросервисы гораздо сложнее тестировать, особенно когда речь идет о end to end тестах
— Инфраструктурно — это всегда бо‘льшие затраты
— Мониторинг — усложняется в разы, как и вообще понимание того, насколько хорошо работает сейчас наша система
— При каких-то поломках поиск причин может быть крайне сложным
— Latency — физика беспощадна, сетевые вызовы всегда дороже, если один вызов пользователя проходит через множество сервисов — он может быть нестерпимо медленным
— Data consistency — если у каждого сервиса своя БД — то какая из них источник правды?
После этого автор переходит к описанию как строить микросервисы и рассматривает следующие моменты (отмечаю не всё, т.к. книга длииннная и там много всего, а только то, что показалось полезным, очередной рассказ по верхам про саги например — не очень):
— Как проектировать микросервисы — очень много отсылок к DDD — и в принципе краткое изложение идей оттуда
— Как распиливать монолит — основные идеи и отсылки к книге Monolith to microservices (она у меня как раз лежит в списке на чтение) — сами идеи уже много где встречал, но тут они хорошо собраны рядом.
— Паттерны общения между сервисами — синхронное, асинхронное и через общие данные. Тут была очень важная мысль, что общая БД — это в том числе способ общения, очень асинхронный — и поэтому и возможное место место взаимозависимости.
— Как производить изменения взаимосвязанных микросервисов — некоторые моменты зависят от используемых технологий, но многие идеи общие — про максимальное сохранение обратной совместимости и по возможности постепенное изменение, вместо breaking changes. Важный момент — не забывать про человеческую часть изменений — в процесс изменений должно быть заложено информирование всех, на кого оно влияет, а также согласование скорости изменений и их необходимости.
— Тестирование. Автор бегло проходит по пирамиде тестирование и с сожалением отмечает, что e2e тесты писать становится очень сложно. Иногда до невозможности. Чтобы как-то компенсировать это предлагает использовать тесты на контракты ну и тестирование в проде.
— А чтобы тестировать в проде — нужна повышенная observability. Тут глава была очень полезная, т.к. observability нужно всем — не только микросервисам. Основная идея проста — необходимо построить набор инструментов и сбора статистики, который бы позволял понимать, что сейчас происходит в системе. Для этого никак не обойтись без агрегации логов, агрегации метрик и желательно чтобы их формат и состав был стандартизирован между всеми микросервисами.
— Дальше опять идет про то, где микросервисы делают жизнь скорее сложнее — безопасность (упоминается концепция Zero Trust) и стабильность. Да, с одной стороны микросервисы позволяют сделать так, чтобы изменение в маловажной области не свалило всё приложение, но с другой — X сервисов — это X мест, где что-то может пойти не так (особенно вспоминая про нестабильную сеть) и всё общение между сервисами должно предусматривать возможность проблем / таймаутов и т.п. с другой стороны.
Последняя глава посвящена тому ради чего вообще делают микросервисы — людям. Организации работы большого количества команд. Упоминается много идей из Team Topology (видимо одна из тех книг, которую я еще не читал, но ее так часть упоминают, что есть ощущение, что все основные идеи из нее уже слышал). В частности stream-aligned teams, enabling teams, platform teams.
В целом — очень много информации, ничего особенно революционного и нового, но хорошо собрано и скомпоновано всё вместе, с отсылками на другие книги, где отдельные вопросы рассматриваются подробнее.