Привет, Хабр!

Недавно принял участие в панельной дискуссии про микросервисы. Планировался холивар «монолит vs микросервисы», но получился, на мой взгдяд, интересный разговор с реальными кейсами. Собрались специалисты с интересным практическим опытом: Павел Куликовский (Цифра банк), Антон Мартынов, Алексей Захаров (Axiom JDK), Андрей Почтов (АЭРО) и Александр Тырышкин (DEVTALE).

У нас вся новая линейка продуктов крутится на микросервисах, которые создаются на единых стандартах и правилах, заложенных в экосистему Digital Q. Экосистема берет на себя многие сложности при работе в микросервисной архитектуре и это сильно экономит нам время, но тем не менее мне были интересен взгляд коллег. 

Я решил собрать основные мысли из дискуссии в статью — получилось про эволюцию подходов, грабли, полезность low-code и как всегда чуть чуть про ИИ. В конце коллеги поделились полезной практической литературой, которой сами пользуются. 

Кому лень читать лонгрид — полная версия дискуссии Rutube. Если будут мысли и вопросы - задавайте в канале Dev Q&A, где собирается сообщество разработчиков.

Буду рад обсуждению и/или вопросам по существу.

Проклятие монолита: почему от него все сбежали

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

Первая и, пожалуй, самая главная проблема — хрупкость и сложность поддержки. Монолит стал напоминать башню из «Дженги»: вытаскиваешь один маленький блок, а рухнуть может все. Критическая зависимость от знаний отдельных разработчиков только усугубляла ситуацию.

«Самое неприятное в больших монолитах — это сложность сопровождения. Если монолит большой, любое изменение может нарушить целостность всей системы. А если опытный разработчик уволился, новым специалистам разобраться в коде крайне сложно», — объясняет Александр Сахаров, директор по работе с партнерами компании «Диасофт».

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

«Мы находимся в эре глобальной цифровизации. Если раньше прикладная система имела 20-30, максимум 200 статусов информации для обработки, то сегодня их количество увеличилось на порядок. Развивать это в монолитной архитектуре становится практически невозможно — упираемся в производительность и информационную безопасность. Именно поэтому микросервисная архитектура становится необходимостью для современных систем», — отмечает Александр Сахаров.

«Самое неприятное — это сложность сопровождения. Если монолит большой, любое изменение в нем может нарушить целостность всей системы. Кроме того, России нужно обогнать весь цивилизованный мир, который все это время рассказывал, что нам нужно ставить импортные решения и все будет хорошо. Но на недавнем примере Аэрофлота мы видим, что это не так. Так что сейчас все российские компании проходят через активный процесс импортозамещения. Но чтобы пройти его быстро, нужно выполнить колоссальный объем работы в распределенной структуре, разными людьми, разными командами. Добиться того, чтобы эти команды одинаково работали в монолитной архитектуре, очень сложно. Здесь на помощь приходят микросервисная архитектура и low-code платформы, которые позволяют стандартизировать разработку», — говорит эксперт.

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

«На мой взгляд, основной вопрос в выборе архитектуры — это размер проекта. Я не представляю, как в Сбере или ВТБ можно сделать монолит для банковского приложения. Когда у вас 100-200 команд разработки, монолитная архитектура становится узким местом — все изменения проходят через одну кодовую базу. Микросервисная платформа позволяет командам работать независимо», — объясняет Павел Куликовский, Tech Lead в «Цифра банк».

И наконец, четвертая проблема — монолиты оказались чужими на празднике жизни современных облачных технологий. Эпоха эластичности, гибридных сценариев и контейнеризации потребовала от архитектуры гибкости, которую монолит дать не мог.

«Выбор архитектуры всегда остается за архитекторами и заказчиком. Если мы движемся в сторону микросервисной архитектуры, то это вопрос облачных платформ. Когда заказчик хочет строить гибридные сценарии, где часть сервисов работает локально, а часть — в облаке, когда нужна эластичность, то для монолитов такие сценарии реализовать сложнее», — объяснил Алексей Захаров, директор по технологическому консалтингу Axiom JDK.

Именно поэтому переход на микросервисную архитектуру выглядел, да и сейчас выглядит, как глоток свежего воздуха. Идея разбить неповоротливого монстра на небольшие, независимые и легко управляемые части казалась спасением. Это был не просто хайп. Это была отчаянная попытка решить реальные, наболевшие проблемы: вернуть управляемость, ускорить разработку и обеспечить отказоустойчивость. Но удалось ли? И какой ценой?

Из огня да в полымя: ловушки микросервисов

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

Первый удар пришелся по кошельку и команде. Очень быстро выяснилось, что микросервисная архитектура — это дорого. И дело не только в написании кода.

«Не секрет, что микросервисы — это дорогое удовольствие, которое к тому же требует от сотрудников более высокой квалификации», — прямо говорит Андрей Почтов, СТО в АЭРО.

Новые реалии потребовали отдельных DevOps-инженеров, сложных систем мониторинга, логирования и совершенно иного подхода к тестированию. Обслуживание всей этой распределенной системы стало отдельной, крайне трудоемкой задачей. Особенно остро это почувствовали те, кто создает тиражируемые продукты без использования микросервисной платформы.

«Представьте, вы создаете рыночный продукт на микросервисах. Когда вы передаете его заказчику, начинается самое интересное: вам обрывают телефон с вопросами "А как работает этот сервис? А что делать с тем?". В итоге инженеры на стороне клиента оказываются в крайне затруднительном положении. Без единой микросервисной платформы или low-code платформы управлять таким зоопарком становится почти невозможно», — делится наболевшим Алексей Захаров (@AlexZ0), директор по технологическому консалтингу Axiom JDK.

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

«Зачастую команды просто бездумно "фигачат" сервисы, не задумываясь о последствиях. В итоге получается так называемая "цепь микросервисов", где отказ одного критического компонента, например, биллинга, валит все приложение», — сетует Александр Тырышкин, основатель DEVTALE LLC.

Третья проблема — коммуникационный хаос. Чем больше независимых команд работает над своими сервисами, тем сложнее им договариваться.

«Сервисная архитектура растит количество команд, людей, взаимодействий. И самые высокие потери эффективности и скорости происходят на стыках», — подчеркивает Андрей Почтов.

В какой-то момент поддержка инфраструктуры начинает отнимать недопустимо много ресурсов. Антон Мартынов предлагает простую метрику, чтобы понять, что что-то пошло не так: «Если вы видите, что на обслуживание инфраструктуры для поддержки микросервисной архитектуры уходит более 30% времени всей разработки, это уже тревожный звоночек. Возможно, вы все слишком усложнили и стоит подумать о low-code платформе для упрощения процессов».

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

Трактор вместо лопаты: спасет ли Low-code от хаоса?

Когда стало очевидно, что для эффективной работы с микросервисной архитектурой нужен суперпрокачанный эксперт, а таких на рынке единицы, индустрия начала искать обходной путь. Решением, по мнению многих, должны были стать low-code платформы — своего рода «экзоскелеты» для разработчиков, которые берут на себя всю рутину и скрывают сложность распределенных систем.

Идея проста и элегантна: вместо того чтобы каждая команда набивала свои шишки с микросервисной архитектурой, можно дать им инструмент, который заставит всех работать по единым правилам. С таким видением выступает Александр Сахаров из «Диасофт». Он говорит, что их микросервисная платформа позволяет аналитикам и архитекторам визуально проектировать микросервисы, после чего по нажатию одной кнопки генерируется весь бэкенд-код, API и даже документация.

«Весь сгенерированный код предоставляется в полностью открытом виде, поэтому программисты могут его дорабатывать, усложнять, использовать наследование, создавать новые компоненты и интегрировать дополнительные модули. Аналогичным образом low-code платформа формирует микрофронтенд, который также построен на микросервисной архитектуре. Вся система работает на принципах event-driven и design-driven архитектуры, где компоненты взаимодействуют через Kafka. Это обеспечивает надежную и масштабируемую коммуникацию между сервисами», — уточнил Александр Сахаров.

Это не только ускоряет создание MVP, но и решает проблему нехватки квалифицированных кадров для работы с микросервисной платформой, которых в больших компаниях может быть 90%.

«Заставить сотни разработчиков с разным опытом мыслить единым образом практически невозможно. Дай каждому в руки лопату — и он выкопает яму своего собственного, уникального образца. А если посадить его за трактор, все ямочки будут одинаковыми. Примерно такая логика работы low-code платформы», — приводит яркую аналогию Сахаров.

Этот тренд подтверждают и другие эксперты. Но может ли low-code «трактор» полностью заменить мастерство «копателя» и его возможности рыть креативно? Не превращается ли low-code платформа в новый, еще более сложный монолит, со своими ограничениями и правилами?

Монолит-луковица: как отделить слои, не доводя до слёз

Эксперты говорят, что пока одни пытались приручить микросервисную архитектуру с помощью low-code платформ, другие пришли к выводу, что проблема лежит глубже — в самом подходе к проектированию. Оказалось, что выбирать между «плохим» монолитом и «сложными» микросервисами вовсе не обязательно. Существует третий, эволюционный путь — создание «правильного» монолита.

Что это такое? Это модульная система, построенная на проверенных временем принципах, таких как SOLID и «луковая» (Onion) архитектура. Она выглядит как монолит, развертывается как монолит, но внутри устроена так, что ее можно безболезненно развивать и, при необходимости, «распиливать» на микросервисную архитектуру.

«Самая серебряная пуля, на мой взгляд, которую я уже 10 лет применяю, — это луковичная архитектура. Ты просто сразу делаешь многослойный монолит. Но если вдруг ты за час можешь написать микросервисную архитектуру из этого монолита, тогда стоит переключаться на микросервисы. Если не можешь — делай лучше монолит, закрывай свое MVP и смотри, как на это реагирует рынок», — делится своей стратегией Александр Тырышкин.

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

«Если мы разрабатываем что-то в режиме MVP, то, скорее всего, предлагаем модульный монолит, который потом можно будет достаточно безболезненно перепилить уже в полноценную микросервисную архитектуру, если проект получит свое продолжение», — подтверждает Антон Мартынов.

«Сегодня мы видим достаточно хорошую автоматизацию всех процессов, необходимых для поддержки и развертывания проектов на микросервисной архитектуре. Это вселяет надежду, иногда ложную, что существует одна волшебная кнопка, нажав которую можно за две минуты запустить микросервисную платформу любой сложности и больше с ней не взаимодействовать. На самом деле любая универсальная low-code платформа имеет основное слабое место: когда требуется кастомизация, возникают проблемы, которые перекроют все затраты на внесение изменений. Классический подход предполагает, что лучше оставаться в парадигме универсальности, но не всех клиентов удается в этом убедить. Иногда требования настолько специфичны, что после нескольких месяцев разработки в рамках универсальной микросервисной платформы сталкиваешься с проблемой, которая изначально в её рамки не укладывалась. Вот тут начинаются основные затраты, которые делают проект адским для всей команды и DevOps», — отмечает эксперт.

Он советует очень аккуратно подходить к выбору решения на старте.

«Я придерживаюсь позиции, что необходимо реализовывать монолит с возможностью быстрой адаптации. Потом из него можно сделать микросервис, скорее всего вручную, но он будет работать именно так, как нужно. При этом важно понимать требования к микросервисной архитектуре: какие должны быть договоренности, какими свойствами должны обладать сервисы, какую информацию передавать между собой, как не блокировать друг друга, какую логику выносить, чтобы они не упали цепочкой. Как организовать взаимодействие не через классический API, а через Kafka», — добавил Антон Мартынов.

В основе такого «правильного» монолита лежат фундаментальные принципы чистого кода. И здесь эксперты сходятся во мнении: без SOLID никуда. Для тех, кто мог подзабыть, эта аббревиатура скрывает пять фундаментальных принципов проектирования, которые помогают строить систему не как запутанный клубок зависимостей, а как хорошо продуманный механизм из независимых, легко заменяемых модулей.

«Всем знать Solid! Этим методам 25 лет, и они до сих пор работают. Живите в SOLID, но не перебарщивайте», — призывает Александр Тырышкин.

Ему вторит и Павел Куликовский: «На самом деле, если следовать просто SOLID, то уже получится практически чистая архитектура, которая будет легко масштабироваться и разбиваться на более маленькие сервисы без необходимости в сложной микросервисной платформе».

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

Монолит, микросервисы и третий игрок — ИИ

Казалось бы, мы нашли золотую середину. Но в 2024 году в архитектурные споры вмешался новый, непредсказуемый игрок — искусственный интеллект. AI-ассистенты и кодогенераторы изменили правила игры, пообещав стать тем самым «трактором», который уравняет шансы и решит проблему нехватки квалифицированных кадров для работы с микросервисной архитектурой.

Идея выглядит соблазнительно. Андрей Почтов рассказал об эксперименте, в котором системный аналитик, вооруженный базовыми знаниями Go и помощью ИИ, смог в одиночку сгенерировать полноценный интеграционный микросервис для микросервисной платформы. «Раньше таких людей называли full-stack, а теперь, похоже, появляется "крафтсман", который может все делать сам. В конечном счете это оказалось экономически целесообразнее, чем работа трех человек», — отметил он.

Здесь и открывается интересный парадокс. С одной стороны, создать с помощью ИИ огромный, сложный монолит — задача практически невыполнимая из-за ограничений контекста и токенов. Нейросеть просто «забудет» начало, пока дойдет до конца. А вот сгенерировать небольшой, изолированный микросервис с четко определенной задачей — это как раз то, в чем ИИ силен. Получается, сама природа искусственного интеллекта подталкивает нас к микросервисной архитектуре. И если этот тренд продолжится, не ждет ли нас ренессанс микросервисов, где главным архитектором, раздающим небольшие, понятные задания, станет человек, а «кодерами» — рой нейросетей, работающих через low-code платформу? Однако, даже в этом сценарии, слепое доверие к сгенерированному коду может быть опасно.

«Без хорошей подготовки и понимания проблем ИИ дает решение "в лоб". Ты смотришь и понимаешь, что вот здесь неправильно, вот здесь это тоже сделано неверно», — предупреждает Антон Мартынов.

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

«Не всегда то, что генерирует ИИ, безопасно. Мы рекомендуем дополнительно после работы AI и джунов проверять код специальными инструментами. Доверяй, как говорится, но про безопасность не забывай», — настаивает Алексей Захаров.

Получается, что ИИ, как и low-code платформы, становится тем самым «трактором», который призван сгладить острые углы микросервисной архитектуры. Он берет на себя рутину, позволяя разработчикам фокусироваться на логике, а не на бойлерплейте. И если учесть, что набирающая популярность «луковая» архитектура по своей сути является идеальным плацдармом для перехода к микросервисной архитектуре, напрашивается интересный вывод. Возможно, мы стоим на пороге ренессанса микросервисной платформы, где связка «грамотный архитектор + ИИ + low-code платформа» сделает этот подход по-настоящему массовым. Не замкнется ли в таком случае вечный круг, по которому разработчики ходят от монолитов к микросервисам и обратно?

А какой путь выбираете вы? И что вы думаете про микросервисную архитектуру, ИИ, монолиты и low-code платформы. Поделитесь своим мнением в комментариях!

Эксперты рекомендуют книги по теме:

«Чистый код. Создание, анализ и рефакторинг» — Роберт Мартин
«Микросервисы. Паттерны разработки и рефакторинга» — Крис Ричардсон
«Предметно‑ориентированное проектирование (DDD). Структуризация сложных программных систем» — Эрик Эванс
«Communication Patterns: A Guide for Developers and Architects» — Jacqui Read