Твиты DDH

Недавно человек с ником DHH (или DDH, каждый раз путаюсь) твитнул, что микросервисы — скам. Видимо, он знаменитость, потому что эту новость обсуждали всем интернетом. Фанатов DDH несколько огорчило то, что во втором твите он признался: первый написал за него чат-гпт. Странный подход к работе с аудиторией: обычно люди читают человека, потому что верят ему. Писать при помощи нейросетей, а потом вскрывать этот факт — немного странно.

Однако важно другое. Каждый раз меня удивляет факт: почему, чтобы осознать простую вещь, нужен твит знаменитости? Разве у людей нет головы на плечах? Если бы речь шла о голове! Неужели не хватает банальных ощущений и восприятия? Когда сел на кактус и больно — разве мы думаем, что делать? Но с микросервисами история противоположна. Людям неудобно — но они глубже садятся задницей на кактус. Обещают себе и другим, что еще немного — и станет легче. Нет, не станет. Ни через три месяца, ни через три года.

Без всяких ГПТ я расскажу, что такое микросервисы на практике. И прежде всего: желаю их фанатикам попасть в проект, где микросервисов не три, а тридцать. Бойтесь своих желаний, уважаемые, потому что вы заговорите по-иному. Одно дело — рисовать круги и стрелки на маркерной доске, другое — отлаживать цепочку из пяти вызовов.

Я варюсь в подобном аду уже два с половиной года и накопил негативный опыт. Он тоже важен: поможет не вестись на провокации, когда кто-то заливает про микросоверсы, Гугл и так далее.

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

Если нет трассировщика запросов, ни о каких микросервисах не может быть и речи. Должна быть админ-панель, где вводишь айди, и показано дерево с таймингами.

Передача данных по сети — целая вечность по сравнению с передачей указателя. Сериализация данных — тоже нетривиальная задача, где сплошные компромиссы. JSON читается человеком, но избыточен и поддерживает мало типов. Protobuf — быстр, но порог входа высокий, нужен обвес. gRPS быстрее обычного REST API, но это фреймворк с высоким порогом. К тому же REST API так или иначе остается для браузера.

Если делать микросервисы по уму, то не хватит никакого воображения, чтобы охватить масштаб. Судите сами: во-первых, одних лишь сервисов недостаточно, им нужен API-гейтвей — согласно бест-практис. Этот гейтвей отвечает за глобальный роутинг, лимиты и многое другое.

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

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

Когда жалуешься на микросервисы, говорят — вы не умеете их готовить. Что ж, может быть, где-то в мире есть фирма, где микросервисы сделаны по уму — я этого не отрицаю. Но гораздо чаще я видел другое — сервисы сделаны через задницу, и при этом говорят, что трудности временны. Сейчас мы добавим Кафку, асинхронное взаимодействие, gRPC — и тогда полетим. Увы, этого не происходит.

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

Сервисы могут быть написаны очень плохо. Я уже год борюсь с тем, что важный сервис проглатывает ошибки. Возвращает пустой результат {"data": []} и пишет в лог. Не читаешь логи? Твои проблемы.

Владение сервисом может быть как благом, так и проклятьем. У него может быть неудобная апишка, но владельцев это не интересует. Заведи задачу — может быть, через три месяца возьмем в работу. А пока что так, у нас другие дела.

Я смотрю на это и думаю: похоже, все эти идеальные микросервисы бывают только в раю. Столько требований, столько ограничений, столько бест-практис, что кажется — нужно быть богом или супер-мозгом, чтобы организовать все правильно. При этом — в разумное время и бюджет(!), и еще параллельно делать бизнес-фичи(!!).

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

Еще ни разу я не видел задачи, которая бы не решалась монолитом и Постгресом. Ни разу — без преувеличений. Только не рассказывайте про Гугл. Во-первых, это другая весовая категория, а во-вторых — в том же OpenAI один мастер-инстанс Postgres. Вполне можно выйти на уровень Faang за счет простых технологий.