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

За моими плечами 10 лет работы в IT, два года из них на позиции тимлида. На моих глазах IT-сфера развилась от прямолинейного общения до "зефирно-ласкового". Сегодня разработчики вынуждены регулярно посещать ван-ту-ваны и ретроспективы, иметь дорожную карту развития, быть мотивированными и клеить стикеры. Тимлиды обязаны давать конструктивную и доброжелательную обратную связь, решать конфликты и прочее. За всеми этими церемониями мы забываем о серьёзном профессиональном подходе к работе. А что, если окружающие нас коллеги — настоящие профессионалы, способные самостоятельно решать большинство проблем без помощи тимлида? 

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