Книга представляет собой обзор паттернов разработки распределенных приложений используя контейнеризацию.
Начинается она с обзора паттернов для случаев, когда контейнеры располагаются на одной физической машине.
Sidecar — второй контейнер рядом с основным, расширяющий его функциональность. Как теория ок. Примеры автор приводит сначала про добавление поддержки https к легаси системе — наверно имеет право на жизнь, если легаси настолько старое, что и правда засунуть его в контейнер будет проще. Следующий пример понравился уже сильно меньше — контейнер который добавляет мониторинг соседнего и некую веб морду с данными о использовании ресурсов. Имхо для таких целей нужен все таки какой-то централизованный мониторинг причем с графиками по времени и т.п. типа как даёт заббикс. Поэтому пример выглядит нежизненным. Третий пример про реализацию доставки изменений через гит репозиторий посредством контейнера который в цикле делает пулл из него. Ну такое. Имхо правильным будет всё-таки когда доставку изменений производит сторонняя система по событию пуша в гит репозиторий, а не трата ресурсов на пулл в цикле.
Дальнейшие рассуждения про то какими должны быть контейнеры, чтобы их можно было переиспользовать хороши, но в целом вытекают из правил для любого модуля, только с поправкой на реалии контейнеров. Внешний интерфейс, документирование, стабильность API и вот это все.
Ambassador — через второй контейнер происходит взаимодействие с внешним миром. От первого примера про шардинг у меня знатно подгорело. Пример собственно про то, что сделаем шардинг редиса так, чтобы для приложения он был как будто один и нам его менять не пришлось. Поднимают 3 независимых редиса, и контейнер-прокси запросы к себе распределяет на них. Ааааа! Кластер редиса делает это сам по себе из коробки, давая при этом ещё и отказоустойчивость. А если заменить редис на какую-то не key-value базу — то там так просто на прокси запросы от приложения не поделишь, совсем приложение не трогая. Другие примеры — сервис-брокер для сервис-дискавери и канареечный релиз / дублирование продакшн трафика на тестовое окружение. Первый да, могу понять, если сервис-дискавери делается не посредством днс. Со вторым так и не смог для себя придумать, когда это было бы полезно делать со стороны клиента, а не сервера принимающего запросы — тестировать то мы будем изменение поведения сервера.
Адаптер. Похоже на амбассадора по сути, но смысл использования — предоставление интерфейса, который основной контейнер не предоставляет. Тут у меня наконец-то вопросов не возникло. И кейсы с мониторингом редиса и изменением формата логов понятные.
Дальше в книге начинаются паттерны для распределенных систем и там уже все выглядит вполне понятно, но в то же время и весьма лайтово (сильно лайтовее книги с кабанчиком). Рассматриваются шардирование, реплики стейтлесс сервисов, scatter/gather паттерн (отправка запросов сразу на несколько серверов и объединение ответа от них в ответ пользователю). Примеры по прежнему не впечатляют, но уже скорее из-за своей простоты. Например пример где делают консистент хешинг на nginx, но при этом на фиксированном в конфиге числе апстримов, учитывая что до этого шла речь про изменение числа шардов, ожидал бы тут какой-то пример, где это самое число шардов можно было бы менять на лету.
Следующая глава посвящена FAAS — function as a service. Общие рассуждения о применимости, удобстве и экономической обоснованности при разной нагрузке полезны. А вот первый предлагаемый пример использования странный — предлагается декоратор по такой схеме: пользователь -> декоратор -> основное приложение. Если декоратор условная лямбда на Амазоне, то если ответ идёт по тому же пути, то декоратор висит все время запроса и мы платим за все это время. Чтобы эта схема была экономически не провальна, мне кажется, нужно усложнять получение ответа от основного приложения в таком сценарии, что никак не согласуется со сценарием — просто добавим декоратор на FAAS, чтобы не править основное приложение.
Выбор мастера и владение (ownership) ресурсом. Первая глава в книге, к которой у меня нет претензий. Более того — она дала мне очень важный инсайт, т.к. на самом деле речь в ней идёт о распределенном локе. Распределенные локи активно используются у нас в коде ( реализованы через редис ). И почему-то раньше я не задумывался о том, чтобы использовать их же для того, чтобы только один наш демон читал определенную очередь (по пулл модели), а думал как-то дополнительно прикручивать zookeper и какой-то более сложный механизм выбора мастера. Глава дала хорошую пищу для размышлений. Также полезной была мысль, что хотя современный оркестратор способен обеспечивать некоторые гарантии fault tolerance, перезапуская упавший контейнер и перенося его с упавшей машины — этого недостаточно при частом деплое.
Последние три главы посвящены очередям и обработке сообщений. Хорошо описано, хотя как по мне поверхностно. Но полезно было взглянуть на это с точки зрения использования контейнеров как замены библиотек.
Общее ощущение от книги — она простовата и наверно скорее полезна как обзорная для новичков. Примеры скорее учебные и не очень близки к реальным. Но в целом прочитать было полезно.
