The Distributed Computing Manifesto

Александр шарит черновик своей ещё недописанной статьи и предлагает сначала понять, что вообще было в манифесте: документ на девять страниц, вроде бы из трёх частей. Первая — сервисная модель. Исходная боль описана прямо: логика жила в Perl-скриптах, которые ходили напрямую в базу и знали всё её содержимое, и в какой-то момент этого кода стало столько, что дальше так жить стало нельзя. Ответ авторов — выносить отдельные сервисы с очень хорошо определённым интерфейсом, за которым спрятана бизнес-логика, и уметь общаться с ними и синхронно, и асинхронно, в зависимости от моделируемого бизнес-процесса. Один из участников добавляет главное следствие: менять надо дисциплину. В базу напрямую больше не ходят, каждый сервис интегрируется через свой API, разработчиков приходится переучивать, и в 1998 году это выглядело совсем непривычно. Он же смеётся, что тогда сам пошёл в пятый класс, а ребята в Amazon уже склеивали сервисы по API.

Отдельно участникам понравился заявленный сдвиг мышления: уход от дата-центричного дизайна, где есть база, вокруг неё строится модель и она же напрямую выплёвывается клиенту, к раздельному проектированию модели, бизнес-логики и интерфейса взаимодействия между системами. Формулируют это так: не логику привязывать к данным, а данные пересылать к логике — сегодня очевидно, а тогда это был новый способ думать о разработке. Новым и крутым подходом в тексте названа трёхзвенная архитектура: интерфейс, сервис, база, — при том что до этого логика жила в хранимых процедурах, а кто-то, замечают участники, пишет так до сих пор, спустя почти 25 лет. Авторы нигде не названы: это манифест Amazon, написанный безымянными людьми. Опубликовал его недавно нынешний CTO компании, Вернер, который пришёл в Amazon только в 2004 году, через шесть лет после написания, и, по собственному признанию в аннотации, принимая оффер, думал, что ничего кроме базы данных и веб-серверов там нет, хотя защитил PhD по распределённым системам.

Вторую часть, про workflow, берёт на себя другой участник. Проблема показана на модели самого Amazon: корзина, заказ, жизнь заказа от начала до конца тянется через одну общую модель, которая лежит в центральной системе; масштабировать тяжело, новые сервисы добавлять тяжело, а центральная система — единая точка отказа. Авторы предлагают то, что сейчас называют оркестрацией и хореографией: либо координатор, который знает, что происходит и кто выполняет работу следующим, и передаёт её от одного к другому, либо цепочка, где каждый сервис сам знает, кому передавать дальше. Заодно резко уменьшается объём данных, с которым работает каждый сервис. Рядом лежит идея разделения доменов: данные должны принадлежать одному домену — всё про пользователя в сервисе пользователя, всё про заказ в сервисе заказа. Участники слышат в этом DDD, но аккуратно уточняют: Эванс написал свою книгу только в 2003 году, через пять лет, и авторы придумали если не домены, то как минимум контексты.

Инструменты из той же главы — хранилище состояния, где записан текущий этап заказа, и подписка на события, чтобы быстро реагировать на смену адреса доставки, получателя или самого заказа: клиент вполне может позвонить и сказать, что переехал в соседний штат, пока товар ещё не выехал. Рядом участники находят раннюю идею отдельного аналитического хранилища вместо всей истории в локальной базе. Технических деталей в манифесте нет, какая там была очередь — неизвестно; один из участников вспоминает классическую книгу 2004 года про интеграцию корпоративных приложений: технологии морально устарели, а концепции живы. Вспоминают и большую таблицу на восемь вариантов координации по осям синхронности, оркестрации и консистентности: часть комбинаций нереальна, вкладываться надо много, а эффект крошечный. Плюсы и минусы оркестрации и хореографии зеркальны, а полезность оркестрации растёт со сложностью процесса: пока он линейный и почти без отказов, хореография проще.

Александр уводит разговор в реальную историю Amazon. До 2000 года компания жила на серверах Sun с установкой «ни минуты простоя», система с сервисами всё равно получилась довольно монолитной, и всё это стоило космических денег; посмотрев на рост заказов и счёт за инфраструктуру, примерно через пять лет после запуска они затеяли переезд на дешёвые серверы и на год остановили продуктовую разработку. Повезло: пока переписывали, лопнул пузырь доткомов, чужие серверы стали продавать в десять раз дешевле, а счёт оказался процентов на 80 меньше прежнего. При этом в 2005 году главная проблема была прежней — все транзакции сайта шли через одно приложение, и выносить из него отдельно разрабатываемый, тестируемый и деплоимый сервис пришлось уже другому топ-менеджеру. Что происходило между 98-м и 2005-м, никто не знает: похоже, манифест написали, положили и достали только в 2022 году.

Дальше выстраивается линия эволюции: монолит, двухзвенная архитектура, трёхзвенная, сервисы, микросервисы 2014 года, serverless с управлением на уровне функций. Один из участников ценит в микросервисах изоляцию, независимость от платформы и практики CI/CD, купленные ценой издержек на обслуживание, другой напоминает, что микросервисы не ради микросервисов. Александр вспоминает свою первую боль: сервисов стало несколько десятков, а оркестратора для рабочих нагрузок не было — Kubernetes опубликовали только летом 2014 года. Сергей приводит рабочий пример: в Тинькофф статус заявки собирают из событий разных систем и заранее доставляют на фронт, убирая лишние задержки; собеседник добавляет, что заодно снимается лишняя нагрузка с мастер-систем. В финале обсуждают жанр: доказательств в манифесте нет, сегодня решения описывают в ADR и RFC, а манифест уместен как заявление о целевом состоянии или как сборник практик — так его применяет юнит РКО в Тинькофф Бизнесе. Выпуск честно называют экспериментальным и обещают поискать манифест ещё старше.