Дословно перевести можно как-то так: Заголовок: Прощайте, микросервисы: от сотен проблемных «детей» к одной суперзвезде Открывашка: Микросервисы — это сервис-ориентированная архитектура программного обеспечения, при которой серверные приложения строятся из множества узкоспециализированных, легковесных сетевых сервисов. Заявленные преимущества — лучшая модульность, меньшая нагрузка на тестирование, более гибкая композиция функциональности, изоляция окружений и автономность команд разработки. Противоположность этому подходу — монолитная архитектура, где значительный объём функциональности сосредоточен в одном сервисе, который тестируется, развертывается и масштабируется как единое целое. В Twilio Segment мы рано приняли микросервисы как лучшую практику. В ряде случаев это отлично сработало — но, как вы скоро узнаете, в других оказалось не так уж хорошо. На раннем этапе развития Twilio Segment мы дошли до переломного момента в одном из ключевых компонентов продукта. Казалось, мы падали с дерева микросервисов, задевая каждую ветку по пути вниз. Вместо того чтобы ускорять работу, небольшая команда увязла в лавинообразно растущей сложности. Ключевые преимущества архитектуры превратились в обузы. Скорость разработки резко упала, а количество дефектов — взлетело. В конце концов команда оказалась в ситуации, когда двигаться вперёд стало невозможно: три инженера на полной ставке тратили большую часть времени просто на то, чтобы система продолжала работать. Нужно было что-то менять. Эта статья — история о том, как мы сделали шаг назад и выбрали подход, который лучше соответствовал требованиям продукта и потребностям команды. === Насколько инженеру захочется прочитать такую статью? Дети какие-то, суперзвёзды... А вступление в духе "давайте договоримся про термины и понятия"? Дело вкуса, конечно. Но что может получиться, если в название поместить тизер проблемы и решения, квинтэссенцию пользы? А в открывашке расшифровать – описать ситуацию, в которой читатель сможет себя представить, потому что жизненно? Заголовок: Как микросервисы стали тормозом. И почему мы вернулись к монолиту Открывашка: Изначально микросервисная архитектура решила реальную проблему - изолировала очереди и убрала “head-of-line blocking”, когда один упавший адресат тормозит всех. Но дальше начался рост репозиториев, расхождение версий общих библиотек, рискованные обновления и операционная нагрузка. К тому же каждый сервис обладал своим профилем ресурсов и ручной настройки автоскейла. В итоге команда объединила 140 сервисов в один монолит, собрала монорепо и стабилизировала тесты через запись/воспроизведение HTTP-трафика. === Что может получиться – статья на 20к просмотров в первые сутки, 33к за пару недель. Само собой, если бы по сути статья была так себе, а вы сделали клёвый заголовок и открывашку, то магия вряд ли бы случилась. Но и в обратную сторону тоже: если статья классная по содержанию, не упускай возможность показать её большему числу людей, за счёт осознанных усилий про причёсыванию парадной витрины текста. === Эту историю принёс Вова Невзоров @vova_dev. Рассказывал, как готовил статью для связки Хабр/телеграм-канал @system_design_world, смотрел доклад про быстрые приготовления для статей на Хабр, поймал эффект "20к просмотров в первые сутки". Сама статья – тут. 👍 – норм 🤔 – ну такое ❤️ – пойду погляжу канал Вовы, любопытно про такой контент 🤬 – не интересно про статьи на Хабр 🔥 – прикольный трюк, попробую для следующей статьи пошаманить заголовок и открывашку в таком духе 🤯 – но мы же не знаем, сколько просмотров собрала бы статья с дословным переводом? предъявите ваши А/Б-тесты! На всякий вот ещё карапулька, зачем делать переводные тексты на Хабр. Почему не стоит недооценивать потенциал этого жанра статей.