Привет, Хабр!
В начале октября на 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 . Однако негативный опыт от использования устаревших платформ и наличие возражений показывает, что огромное число профессионалов еще не вполне понимают какие новые возможности появились на рынке и как они реально могут помочь им в решении сложнейших задач.
У меня перед глазами — целый ряд крупнейших российских технологических компаний, которые уже начали получать эти преимущества. От Сбербанка, ЛеманаПро и Альфа-Банка до Аэрофлота, Ростелекома, ведущих энергетических холдингов и крупнейших государственных проектов.