Григорий Петров. Сложность, убивающая микросервисы

В сфере аутстаффинга и обучения разработчиков наблюдается тенденция, когда клиенты обращаются с запросом на декомпозицию существующих монолитных систем, например, написанных на Python, в архитектуру микросервисов с использованием Go. Ожидается, что такой переход автоматически приведет к упрощению системы. Однако на практике разработчикам приходится тратить значительные усилия, чтобы объяснить, что простота не будет достигнута, и что сложность может возрасти.

Простые микросервисы могут быть сложнее, чем монолиты.

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

В последние полтора года наблюдается осторожная критика микросервисной архитектуры. Приводятся примеры крупных сервисов, которые меняют свою структуру. Например, Amazon Prime мигрирует с микросервисов. Также отмечается, что такие сервисы, как Instagram или WhatsApp, поддерживаются относительно небольшими командами инженеров, что контрастирует с масштабами, которые обычно ассоциируются с по-настоящему микросервисной архитектурой.

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

Желание быстро обучать разработчиков является ключевым. Если 20 лет назад обучение до нужного уровня занимало около трех лет, то сейчас необходимо понимать, как мозг осознает код и что именно делает код сложным. Современная нейрофизиология предполагает, что сознание основано на долговременной памяти, содержащей сотни тысяч смыслов, которые академик Анохин называет когнитомами и связями между ними.

Смыслы, на которые не направлено внимание и которые не имеют сильных связей, деактивируются за несколько секунд. Кратковременная память оперирует теми смыслами, которые активированы в данный момент. Исследования с использованием фМРТ показывают, что количество удерживаемых элементов в рабочей памяти (кошелек Миллера) крайне низко, что подчеркивает фундаментальное различие между долговременной памятью (выжженные нейрональные ансамбли) и кратковременной (процесс их включения/выключения).

Смыслы, которые формируют основу для осознания кода в долговременной памяти, берутся из нескольких источников. Это не только синтаксис выученного языка программирования, но и опыт использования фреймворков, библиотек и внутренних идиом стека. Осмысленные имена идентификаторов также вносят вклад, помогая рассказать историю, но синтаксис составляет лишь очень малую часть общего ассортимента деталей Лего, необходимых для осознания сложного кода.

Сознание программиста можно уподобить графу, который постоянно достраивается в реальном времени за счет поступающей информации (то, что видят, слышат, ощущают) и одновременно разрушается по мере затухания смыслов. Для активации смысла он должен уже существовать в долговременной памяти. Новые детали Лего не могут быть построены в реальном времени; для их формирования требуются месяцы и годы.

Программная сложность (Soft Complexity) является фактором, который убивает проекты, поскольку программист не может отойти на шаг назад и оценить общую картину, как это делает художник. Главная проблема микросервисов заключается в сложности ориентирования. В монолитах разработчики опираются на устоявшиеся фреймворки (Django, Rails), которые дают готовые смысловые конструкции для сознания. В мире микросервисов такого универсального инструментария нет.

Каждая компания, работающая с микросервисами, вынуждена создавать собственные велосипеды, то есть внутренние платформы разработки (Dev Platform), как это сделала Spotify с проектом Эй. Для навигации по большим проектам необходимо знать карту микросервисов и карту команд, поддерживающих эти сервисы, что добавляет нетривиальные коммуникационные накладные расходы.

Kubernetes позиционируется как замечательная сетевая операционная система и язык для описания инфраструктуры, но он не является фреймворком для описания сотен тысяч строк бизнес-кода, который пишут программисты. В результате крупные компании тратят годы на разработку внутренних Dev Platform, чтобы обеспечить необходимый уровень абстракции для своих разработчиков.

Аналогия с пациентом, которому удалили гиппокамп, показывает, что формирование долговременной памяти происходит годами, а не месяцами. Разработчику, переходящему с монолита, потребуются месяцы и годы, чтобы навыки работы со сложной Dev Platform перешли в долговременную память и работа стала комфортной. В то время как стандартные веб-фреймворки формируют одинаковые детали Лего у всех разработчиков, платформы для микросервисов у всех разные.

Долговременная память все-таки формируется годами, а не месяцами.

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

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

Дэвид Хаммер Хейсон пропагандирует архитектуру «Цитадель», где ядро бизнес-логики остается в виде «Majestic Monolith», а вокруг него размещаются микросервисы для задач, требующих максимальной скорости и изоляции. При этом отмечается, что современные языки, такие как Ruby, значительно медленнее Python, который, в свою очередь, в 100 раз медленнее C++. Даже на мощном сервере с Ruby on Rails и PostgreSQL производительность может быть ограничена из-за постоянных операций чтения/записи в базу.

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