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