Привет, Хабр!
В начале октября на XIV Международной IT‑конференции «Стачка» в Санкт‑Петербурге — одном из крупнейших профессиональных событий российского IT‑комьюнити — мы решили провести эксперимент.
Что, если предложить разработчикам публично выбрать сторону в вечных холиварах? Например: Микросервисы или монолиты? Low‑code или только ручной код?
И мы запустили два баттла в Telegram‑боте. Участники конференции выбирали позицию, писали аргументы, лайкали чужие комментарии. В итоге мы собрали 121 комментарий и более 2500 реакций от реальных практиков.
Результаты выглядели убедительно:
Микросервисы: 816 лайков vs Монолиты: 232 (почти 4:1)
Low‑code: 1184 vs Против: 227 (больше 5:1)
На первый взгляд, всё очевидно: сообщество выбрало микросервисы и low‑code. Можно делать выводы о трендах.
Но когда я стал читать сами комментарии, картина оказалась намного интереснее и сложнее. Люди не просто «голосовали» — они аргументировали, рефлексировали, приводили примеры из практики. И самое ценное: даже выбирая одну сторону, честно говорили об ограничениях и ситуациях, когда правильным будет противоположный выбор.
Получился не опрос с красивыми цифрами, а живой срез того, как опытные разработчики на самом деле думают о выборе архитектуры и инструментов. И это оказалось куда важнее любой статистики.
Ниже — разбор деталей опроса и аргументов, которые показывают: в реальности всё намного сложнее, чем 4:1 или 5:1.
Микросервисы против монолитов
Начну с баттла, результаты которого выглядели наиболее предсказуемо: микросервисы набрали 816 лайков, монолиты — 232. Соотношение почти 4:1 в пользу микросервисной архитектуры.
Казалось бы, всё понятно: микросервисы — это мейнстрим, монолиты — наследие прошлого. Но комментарии указывали, что такая оценка не всегда читается однозначно.
Да, сторонники микросервисов говорили о масштабируемости и отказоустойчивости — это ожидаемо. Но гораздо чаще звучала совершенно другая тема: когнитивная нагрузка.
«Небольшие изолированные сервисы проще поддерживать, дорабатывать и тестировать» — этот комментарий набрал 21 лайк. Люди говорили не о технических преимуществах, а о том, что с небольшим сервисом проще работать — держать контекст в голове, быстрее разбираться в коде, увереннее вносить изменения.
Один из участников использовал метафору конструктора: «Как кубики в конструкторе. Из них можно составить монолит». И это точно отражает суть — микросервисы дают гибкость композиции.
А вот у защитников монолитов оказалось меньше голосов, но их аргументы были конкретнее и прагматичнее.
«Проще, если нет супер большой нагрузки» — этот комментарий набрал 22 лайка, больше, чем многие аргументы за микросервисы. И это прямое попадание в суть проблемы: микросервисы решают задачу масштаба, но что, если у вас этой задачи нет?
Ещё один важный аргумент: «Зависит от оргструктуры команды. У нас — монолит» (17 лайков). Это отсылка к знаменитому закону Конвея: архитектура системы отражает структуру коммуникаций в организации. Команда из пяти человек с монолитом может выпускать фичи быстрее, чем та же команда с десятком микросервисов, половину времени проводя на согласовании изменений API.
И самый зрелый комментарий, который я увидел: «Монолит на этапе проверки гипотезы, демо. Прод уже на микросервисах». Это не выбор «или‑или», это понимание эволюции системы.
Казалось бы, соотношение 4:1 выглядит убедительной победой микросервисов. Однако, работая над проектами разного масштаба, я постоянно сталкиваюсь с ситуациями, когда реальность оказывается сложнее статистики.
Представьте типичный стартап или внутренний сервис компании с нагрузкой в несколько тысяч пользователей в день. Монолит в таких условиях справляется отлично. Разработчики развёртывают изменения одной командой, не тратят время на настройку взаимодействия между сервисами, не борются с проблемами распределённых транзакций. Микросервисная архитектура, кажется, в такой ситуации — это преждевременное усложнение, которое замедляет команду и съедает ресурсы на поддержку инфраструктуры. На самом деле это большое заблуждение.
Сегодня не 2015, а 2025 год и на сегодня эта проблема решена за счет использования специальных микросервисных композиционных платформ, которые подробно описаны Gartner и имеют специальное название — композиционная платформа (Composable platform © Gartner). Платформа берет на себя всю сложность первичных рутинных операций и позволяет маленьким командам быстро запускать прототипы в микросервисной архитектуре, не тратя время на сложности, которые были раньше.
В том же заблуждении часто находятся и небольшие команды — 5–7 разработчиков. Им кажется, что если весь код хранится в одном репозитории, то можно быстро вносить изменения, экспериментировать с новыми возможностями и легко откатывать неудачные решения. На деле все эти задачи давно решаются современными композиционными платформами, работающими по подходам Gartner — PBC (Packaged Business Capabilities) и композиционной архитектуры. На российском рынке к таким платформам относятся, например, Platform V от Сбербанка, наша DigitalQ, а также ряд других, меньших по масштабу решений.
Особенно важна фаза жизненного цикла продукта. На этапе поиска своей ниши и аудитории, когда бизнес‑модель ещё не устоялась, нужна максимальная гибкость. Часто приходится радикально менять логику работы системы за считанные дни. В монолите очень легко запутаться. — Часто приходиться переписывать целые куски и деплоить. Композиционная платформа с встроенными механизмами быстрого визуального внесения изменений, запуска А/В тестов, тестирования разных гипотез, быстрых прототипов и визуальных изменений позволяет это делать быстро и ни в чем не запутаться.
И в тот момент, когда продукт находит свою аудиторию и начинает быстро расти, уже не приходится его переписывать с целью повышения производительности и свойств мастабирования. Продукт уже сразу из коробки готов к высоким нагрузкам, к работе с большими командами и это позволяет быстро вывести его на большой рынок.
Поэтому соотношение 4:1 отражает реальное положение дел, однако незнание возможностей, современных микросервисных платформ часто приводит к ошибочным в решениям.
Low-code: от табу к инструменту
Результаты второго баттла удивили меня больше. Low‑code набрал 1184 лайка против 227. Разгром со счётом больше 5:1.
Честно говоря, я ожидал значительно более жёсткого противостояния. Ещё несколько лет назад low‑code в профессиональном сообществе был синонимом «игрушечных решений», которые настоящие разработчики всерьёз не воспринимают. Но сейчас отношение явно изменилось.
Аргументы «за» были ожидаемыми: скорость разработки («Продукт можно создать за несколько дней, более сложный — за 2–3 недели, тогда как при создании с нуля потребуется несколько месяцев» — 30 лайков), экономическая эффективность («Команда из двух специалистов на low‑code может сделать то, что раньше требовало целый отдел» — 30 лайков).
Но больше всего меня зацепили метафоры, которые использовали участники дискуссии. Они показывали удивительно трезвую оценку без попыток выдать low‑code за панацею.
«Low code: это как готовка с полуфабрикатами. Быстро, удобно, но иногда получается не совсем то, что ожидал» — 28 лайков. Обратите внимание: автор честно признаёт компромисс между скоростью и контролем над результатом.
«Нужен MVP — бери лоу. Строишь небоскреб — бери ручной» — часть комментария с 26 лайками. Чёткое понимание границ применимости без попыток натянуть одно решение на все задачи.
А вот что действительно удивило: самые популярные критические комментарии набрали почти столько же лайков, сколько и позитивные. И это говорит о многом.
«Создать простое приложение легко, но когда бизнес‑логика усложняется, визуальная схема превращается в лапшу, которую невозможно поддерживать. Проект может упереться в потолок возможностей платформы. Это как шуруповёрт: для сборки мебели из IKEA — незаменим, но для постройки небоскрёба всё равно понадобится полноценная строительная техника» — 27 лайков.
Это значит, что даже люди, проголосовавшие «за» low‑code, соглашаются с ключевой проблемой. Нет слепой веры в очередную серебряную пулю.
«Vendor Lock» — лаконичный комментарий на 25 лайков. Зависимость от поставщика платформы действительно остаётся серьёзным стратегическим риском для бизнеса, особенно в долгосрочной перспективе. Но далеко не для всех платформ, решения на рынке эволюционируют.
Первое важное все в целом согласны, сегодня Low‑code действительно блестяще работает для определённого класса задач. Типовые интерфейсы для работы с данными, автоматизация бизнес‑процессов, внутренние административные панели — здесь преимущества очевидны. Когда нужно быстро создать форму для согласования заявок или дашборд для отслеживания показателей, low‑code даёт огромный выигрыш в скорости разработки.
Однако при работе когда речь заходит о сложной бизнес‑логике некоторые начинают сомневаться, мотивируя это серьезными ограничениями классических low‑code платформ.
На самом деле это было верно ранее, но совсем не сейчас. Старые low‑code платформы прошлого поколения действительно имеют все эти проблемы и ограничения. Но все же с тех пор как они появились уже прошло много времени. Как я уже говорил выше сегодня не 2015, а в 2025 год. Никто уже не сомневается в возможностях ИИ и в том, что значимую часть рутинных операций можно снять с разработчиков и аналитиков путем автоматизации стандартов разработки.
Современные low‑code платформы нового поколения совсем не те, что были раньше и имеют следующие важные отличительный особенности:
Отсутствие vendor lock‑in — платформа генерирует полностью открытый код, с которым можно и нужно работать. Этот код создаётся на основе самых распространённых фреймворков, таких как Spring, Angular и React, использует общепринятые библиотеки и не содержит никаких закрытых, зависящих от вендора компонентов.
Автоматизация всех рутинных, а значит — очень скучных для любого программиста — задач: управления ролями и доступом, аккуратного покрытия кода юнит‑тестами, соблюдения стандартов логирования, требований к горизонтальному масштабированию и архитектуре, формирования и публикации стандартных API, ведения документации и многого другого.
Снятие рутинных, а значит очень скучных задач для аналитиков — автоматическое тестирование на обратную совместимость, производительность, целостность бизнес процессов и многое другое.
Снятие рутинных задач с фронт‑энд разработчиков за счет полностью автоматической генерации всего интерфейса в виде микро‑фронт‑энда.
Важно, что теперь это не типовой скучный интерфейс, а полноценный, полностью открытый микрофронтенд с возможностью описать и подключить практически любой дизайн. А поскольку код открыт, в него легко добавить любые необходимые усложнения — для самых требовательных проектов.
Важно что low‑code платформы нового поколения реализуют полный SDLC цикл от проектирования, то управления CI/CD процессами, которые также снимают огромное количество головной боли со всей команды. Автотесты, авто развертывание, авто интеграция и все это в полностью открытом виде на базе наиболее популярных инструментов таких как Gitlab или Jenkins
Очень важно, что все новые платформы изначально готовы к работе с ИИ. Любые агенты могут быть подключены на любом этапе — они способны генерировать схемы логической архитектуры и бизнес‑процессов, создавать и модифицировать BI‑дашборды, интегрировать приложения между собой. По сути, это позволяет собирать новое приложение в режиме диалога — например: «создай приложение, которое будет продавать полисы ОСАГО на базе существующих в платформе бизнес‑процессов и микросервисов, а также подготовь дашборды по продажам на основе созданной модели данных». При этом ИИ выполняет все задачи в рамках правил, заложенных в платформу, а результат имеет визуальное представление архитектуры и процессов.
Очень важно, что использование современных low‑code платформ нового поколения позволяет создавать высоконагруженные и функционально сложные системы. В таких платформах уже предусмотрены механизмы горизонтального масштабирования, обеспечения высокой производительности, соответствия современным требованиям информационной безопасности, а также универсальности и омниканальности интерфейсов — вне зависимости от канала или устройства.
И так далее — можно долго рассказывать о том, как современные low‑code платформы нового поколения снимают все те ограничения, с которыми сталкивались старые решения. Те действительно были проблемными и подходили лишь для самых простых и типовых задач. Новые же платформы — это уже полноценный производственный конвейер по созданию ИТ‑решений высочайшего качества, с радикально меньшими затратами и полностью открытым кодом и архитектурой.
В целом 5:1 — красноречиво показывает, что эксперты понимают ценность «low‑code». Однако негативный опыт от использования устаревших платформ и наличие возражений показывает, что огромное число профессионалов еще не вполне понимают какие новые возможности появились на рынке и как они реально могут помочь им в решении сложнейших задач.
У меня перед глазами — целый ряд крупнейших российских технологических компаний, которые уже начали получать эти преимущества. От Сбербанка, ЛеманаПро и Альфа‑Банка до Аэрофлота, Ростелекома, ведущих энергетических холдингов и крупнейших государственных проектов.
