Расскажу историю, которую сам долго не мог уложить в голове. Знаете, какая компания однажды срезала свои расходы на ошеломляющие 90%, просто вернувшись от микросервисов к старому доброму монолиту? Не безденежный стартап из гаража. Не пет-проект энтузиаста на выходных. Сама Amazon — её сервис Prime Video. Та самая Amazon, чья AWS зарабатывает миллиарды в год, продавая всему миру инфраструктуру под микросервисы, тихо призналась: иногда монолит просто выигрывает.
Этот разворот от компании, которая, по сути, и написала правила игры в распределённых системах, вызвал в облачном сообществе короткое замыкание. Оригинальную запись в блоге Amazon позже удалила — но интернет, как известно, ничего не забывает, и мы к ней ещё вернёмся.
Я лет пять-шесть подряд бубню на каждой ретроспективе одно и то же: не тащите микросервисы туда, где они не нужны, и тем более — не тащите их раньше времени. После истории с Prime Video я вдруг обнаружил, что в этом окопе нас уже целая компания — и среди соседей попадаются весьма уважаемые архитекторы.
И всё-таки в большинстве технических разговоров микросервисы по-прежнему подаются как единственный взрослый способ строить софт. Они правят бал на конференциях, в блогах и в вакансиях. Команды берут их не потому, что этого требует задача, а потому, что так «принято» — и потому что строчка в резюме весомее. «Cloud-native» незаметно стало синонимом «микросервисы по умолчанию», будто всё остальное устарело, как дискеты.
Микросервисы действительно решают реальные проблемы — но в по-настоящему больших масштабах. А большинство из нас в таких масштабах не работает. Давайте честно, по-дружески, без слайдов и евангелизма, разберём вопрос, который индустрия почти разучилась задавать: должны ли микросервисы быть выбором по умолчанию?
На бумаге микросервисы выглядят роскошно. Вместо одного большого монолита вы режете приложение на десятки маленьких сервисов. Каждый можно писать на своём языке, отдавать отдельной небольшой команде и катить в прод по собственному расписанию. Нужно больше мощности — масштабируете ровно тот кусок, что под нагрузкой. Независимые деплои, автономные команды, разноязыкие стеки, эластичное масштабирование. Звучит как мечта.
А теперь мелкий шрифт. Каждое разделение создаёт шов, а каждый шов — потенциальную точку отказа. Внутри монолита вызов функции мгновенный и предсказуемый. Между сервисами тот же вызов превращается в сетевой запрос: медленнее, ненадёжнее, иногда с противоречивыми данными на выходе. А когда сервисов десятки или сотни, вам внезапно нужны версионирование, эволюция схем, распределённые транзакции, трассировка, централизованные логи и крепкие CI/CD-конвейеры — просто чтобы это вообще держалось вместе.
Старая диаграмма Gartner про этот компромисс предельно честна: микросервисы меняют простоту одной кодовой базы на сложность множества движущихся частей. В масштабах Netflix такой обмен оправдан. Но когда операционные плюсы не перевешивают цену, команда начинает платить временем — за отладку, за согласование, за тонны связующего кода, который только и делает, что удерживает продукт на плаву.
Микросервисы оправданы в очень конкретных сценариях — там, где разные бизнес-функции и правда требуют независимого масштабирования и деплоя. Обработка платежей (критична по безопасности, меняется редко) принципиально не похожа на систему рекомендаций (прожорлива до памяти, живёт в бесконечных A/B-тестах). Разные модели масштабирования, разные циклы релизов, разные профили риска — вот здесь отдельные сервисы себя оправдывают.
Успех микросервисов держится на чётких границах бизнес-доменов, которые совпадают со структурой команд — это, по сути, закон Конвея в действии. Если ваша организация естественно распадается на автономные команды с разными зонами ответственности — возможно, микросервисы зайдут. А вот стартап, который целиком помещается за одним столом и наедается двумя пиццами, под это описание не подходит — согласитесь?
Большинству команд просто не хватает предпосылок: выделенного владельца у каждого сервиса, зрелого CI/CD, надёжного мониторинга и — главное — такого масштаба, который оправдал бы операционные накладные. Стартапы, которые хватаются за микросервисы раньше времени, потом, как правило, об этом жалеют.
Вы берёте микросервисы, чтобы решить реальную проблему независимого масштабирования? Или просто создаёте больше сложности, чем требует ваша задача?
амое забавное, что отыгрывают назад как раз те, кому микросервисы по идее нужнее всех, — технологические гиганты. И результаты, мягко говоря, заставляют задуматься.
Amazon Prime Video: минус 90% к счёту
Май 2023-го, инженеры Amazon признают немыслимое: Prime Video уходит от микросервисов обратно к монолиту. Их команда контроля качества видео (VQA) построила, казалось бы, образцовую распределённую систему — AWS Step Functions и Lambda следили за тысячами видеопотоков через независимо масштабируемые компоненты. На бумаге — идеальный serverless.
На практике — провал. Марчин Кольны написал в том самом, ныне заархивированном блоге Prime Video Engineering, что в их конкретном случае распределённый подход почти не приносил пользы. Их «бесконечно масштабируемая» система захлебнулась всего на 5% ожидаемой нагрузки — её утопили накладные расходы на оркестрацию.
Решение оказалось до неприличия простым: собрать всё обратно в один процесс. Итог — минус 90% к стоимости и заметный прирост производительности. Узким местом, кстати, оказалась не сама обработка, а перегонка промежуточных данных через S3 между сервисами — она стоила дороже, чем полезная работа.
Twilio Segment: от 140 сервисов — к одному быстрому монолиту
Ещё в 2018-м платформа клиентских данных Twilio Segment описала похожий разворот в предельно откровенном посте с говорящим заголовком «Прощайте, микросервисы». Их зоопарк разросся до 140+ сервисов и превратился в операционный хаос. В какой-то момент трое штатных инженеров большую часть времени тушили пожары вместо того, чтобы что-то строить.
Они сами сформулировали диагноз честнее некуда: вместо ускорения маленькая команда увязла в разрастающейся сложности, и достоинства архитектуры обернулись обузой — скорость падала, а количество дефектов росло. Лечение было радикальным: слить все 140+ сервисов обратно в единый монолит. Эффект мгновенный — тесты, которые раньше шли час, стали проходить за миллисекунды, а за год команда внесла 46 улучшений в общие библиотеки против 32 в эпоху микросервисов.
Shopify: здравый смысл вместо хайпа
У Shopify одна из крупнейших в мире кодовых баз на Ruby on Rails — больше 2,8 миллиона строк. И вместо гонки за микросервисами они осознанно выбрали модульный монолит: единую кодовую базу с жёсткими внутренними границами. Их инженеры прямо рассудили, что микросервисы принесут собственный ворох проблем, и предпочли модульность, чтобы не платить операционный налог.
Если даже пионеры микросервисов отступают, почему мы всё ещё держим их за истину в последней инстанции?
Когда тревогу бьют не блогеры, а люди, лично построившие системы, которыми мы восхищаемся, — стоит хотя бы прислушаться. (Болельщики на поле не выходят: те, кто громче всех топит за «cloud-native», редко строят высоконагруженное сами.)
«Наконец-то появились реальные результаты всей этой теории — и стало видно, что на практике микросервисы, пожалуй, самый соблазнительный способ переусложнить систему.» — Дэвид Хайнемайер Ханссон (DHH), создатель Ruby on Rails
Образ песни сирен у DHH здесь к месту: микросервисы манят элегантностью, а команды нередко разбиваются о скалы сложности.
«Я убеждён, что одной из крупнейших архитектурных ошибок прошлого десятилетия был тотальный переход на микросервисы.» — Джейсон Уорнер, бывший технический директор GitHub
Уорнер знает, о чём говорит: GitHub работает в масштабах интернета, а до этого он рулил разработкой в Heroku и Canonical. И добавляет он не менее резко — что процентов девяносто всех компаний в мире спокойно жили бы на монолите поверх кластера баз данных с репликами, кэшами и прокси, и этого бы хватило.
«Микросервисы — настолько фундаментально и катастрофически плохая идея, что в будущем вырастут целые многомиллиардные компании, которые будут лишь сдерживать причинённый ими ущерб.» — Ник Шрок, соавтор GraphQL
Человек, буквально создавший инструмент для жизни с распределёнными данными, советует обратное: не распределяйте без нужды. Возможно, к нему пора прислушаться.
«Мы переводим многие наши микросервисы в макросервисы — сервисы оптимального размера. Именно потому, что тестировать и поддерживать тысячи микросервисов не просто сложно: в долгую это создаёт больше проблем, чем решает в моменте.» — Гергей Орос, Uber
«Ставлю на то, что монолит обгонит почти любую микросервисную архитектуру. Просто посчитайте сетевую задержку между сервисами плюс сериализацию и десериализацию каждого запроса.» — Келси Хайтауэр (известный по работе с Kubernetes и Google Cloud)
Хайтауэр тот твит потом удалил — но арифметика никуда не делась и продолжает выставлять микросервисам счёт. Когда о тревоге говорят те, кто реально решал проблемы распределённых систем в энтерпрайзе, это уже не ворчание скептика.
Если бывший технический директор GitHub считает, что 90% компаний не нужны микросервисы, вы точно уверены, что входите в оставшиеся 10%?
Автор: Коробов Алексей
© Коробов А.Е., 2026
