Традиционные методы разработки корпоративных систем всё чаще не успевают за изменяющимися бизнес-требованиями — задачи и новые требования возникают быстрее, чем команды успевают пройти все фазы от разработки технического задания до релиза.
Согласно прогнозам аналитиков Gartner, в ближайшие годы ожидается бум на low-code платформ, которые позволяют значительно ускорить создание корпоративных решений за счёт использования визуальных интерфейсов и готовых компонентов, снижая нагрузку на IT-отделы и обеспечивая быструю адаптацию к изменениям.
Илья Радченко, директор по платформенным продуктам SimpleOne, рассказал в подкасте Neogenda о том, как устроены low-code платформы и почему они взлетают на российском рынке. В статье — часть подкаста, а полную версию разговора можно посмотреть на YouTube.
Что такое low-code платформа
В буквальном переводе low-code означает "мало кода". Основная идея этого подхода к разработке программного обеспечения заключается в том, что вместо написания сотен или тысяч строк кода вручную, вы создаете решения, используя готовые компоненты, подобно сборке конструктора. Преимущества такого метода включают ускорение разработки, снижение зависимости от высококвалифицированных программистов и упрощение процессов для пользователей с минимальными техническими навыками.
Low-code платформы предоставляют удобные визуальные инструменты, позволяя создавать приложения с помощью интерфейса drag-and-drop. Это избавляет от необходимости писать код для базовых операций, таких как создание интерфейсов, настройка баз данных или форм. Вместо этого вы просто перетаскиваете нужные элементы и настраиваете их.
Чем low-code лучше
В классической разработке любое изменение проходит через длинный цикл: подготовка ТЗ, передача разработчику, реализация, тестирование и развертывание в рабочей среде. В условиях, когда бизнесу требуется быстро адаптировать процессы, такой подход может быть слишком медленным и неэффективным.
В тему цифр:
создание готового решения на low-code платформе занимает 1-3 месяца;
разработчик без приставки low-code стоит 200-300 тысяч рублей в месяц;
специалист по low-code обойдется в 2-3 раза дешевле;
порог входа — техническое образование и понимание, как устроены информационные системы.
SimpleOne уже держит десятки тысяч активных пользователей на своей платформе и метит в миллионы. А команда всего 100 человек, из которых половина — разработчики. MVP сделали командой из 7-8 человек за полгода, включая и платформу, и первую коробку с готовым решением.
Кстати, про «не нужны программисты» — не совсем правда. Для сложных кейсов на платформе есть pro-code режим, в нем можно написать свой фронтенд или добавить специфичную логику на JavaScript. Такой компонент становится переиспользуемым — его можно встраивать в другие решения как обычный low-code элемент.
Зачем вообще делать low-code? На примере
В SimpleOne начали с автоматизации ИТ-департамента — построили ITSM-систему. В ней работают заявки, SLA и классический Service Desk, а под капотом — большой сложный таск-трекер, который поддерживает все процессы управления IT, основанные на лучших мировых практиках ITIL и ITSM .
Почему именно low-code:
время запуска первой версии — 3 месяца против 6+ по классике;
не нужно держать большой штат разработчиков;
партнеры могут сами кастомизировать решение под клиентов;
клиенты меняют под себя еще 20% функциональности после внедрения.
Такая система автоматизирует поддержку сервисов, считает метрики, следит за SLA и управляет инцидентами. И все это без кодинга настраивается через интерфейс платформы.
За счет low-code компания может начать с одного модуля, а потом расширяться. Например, внедрили ITSM или B2B CRM, распробовали и начали автоматизировать другие отделы. При этом остаются в рамках уже купленной платформы — не нужно покупать новые системы и думать об их интеграции. ROI такого подхода видно уже через год использования. А через 2-3 года экономия на разработке и поддержке становится существенной.
Low-code или традиционная разработка?
Рядовая ситуация в бизнесе: вышла новая версия ITIL, надо перестроить процессы. Или происходит очередная реорганизация, и половина схем работы становятся неактуальными. Обычно это значит, что нужно нагрузить разработчиков рутиной, подождать, пока они все перепишут, протестировать и молиться, чтобы ничего не сломалось.
При этом платформа отлично держит нагрузку — команда SimpleOne не стала изобретать велосипед по части масштабирования и безопасности, эти вопросы решает сама платформа. Low-code разработчик сосредоточен на бизнес-логике, а не на том, как заставить это все работать на сотне серверов.
Однако при всех плюсах есть ситуации, когда low-code не зайдет, например, тяжелые производственные процессы, работа со специфическим оборудованием, задачи, где нужна особая компетенция по железу, сложные интеграции с legacy-системами. А для всего, что связано с людьми и их задачами — HR, финансы, IT, безопасность — low-code отлично подходит. Почему? Потому что эти процессы постоянно меняются, и классическая разработка просто не успевает за изменениями.
Ситуация на рынке и конкуренция
На российском рынке сейчас два типа игроков:
нишевые вендоры, которые прикрутили к своим решениям инструменты конструктора;
изначальные low-code платформы вроде SimpleOne.
На международном уровне SimpleOne целится в нишу ServiceNow — лидера по всем квадрантам Гартнера. В поле зрения также HP Service Manager, BPMN, Pega и другие тяжеловесы enterprise-сегмента. Команда обращала внимание и на классические low-code платформы — Aria, Mendix, Zoho. Но решили сделать что-то свое, заточенное под российские реалии.
«Когда мы видели, как уходят большие вендоры, мы понимали, что образуется вакуум, и начали готовиться к этому заранее», — рассказывает Илья Радченко в подкасте Neogenda.
Что под капотом low-code платформы SimpleOne?
Стартовали с тем, что было под рукой — монолит на PHP, фронт на React. Но когда приблизились к проду, поняли — так не взлетит.
Что поменяли в процессе:
Внедрили DDD (Domain-Driven Design) разделили логику приложения на независимые части, где каждый микросервис отвечает за свою бизнес-логику;
разбили монолит на микросервисы;
начали завозить Go вместо PHP;
прикрутили Kafka для обмена событиями;
начали добавлять популярные инструменты Redis и RabbitMQ и тд;
изменили схему и принципы взаимодействия с БД.
Сейчас система держит десятки тысяч пользователей, которые активно работают в ней каждый день. В планах — дорасти до миллионов пользователей.
Интеграции тоже на уровне: REST API для двусторонней связи с любыми системами, из коробки работает с Active Directory, есть коннекторы к почтовым сервисам. Сейчас добавляют поддержку брокеров сообщений вроде Kafka — это must have для крупных корпоративных клиентов.
И главное, что все это реально работает на больших нагрузках. Решение SimpleOne целится на enterprise-сегмент: корпорации, лидеры индустрии, компании со зрелыми бизнес-процессами — поэтому вся архитектура заточена под Cloud Native и микросервисы.
***
Смотрите полный подкаст на YouTube, чтобы узнать подробности — Илья также рассказывает, как компании выбрать low-code платформу, какие подводные камни ждут при внедрении и куда движется рынок. Обсудили и перспективы ИИ в low-code: как ни странно, нейросетки уже учатся собирать решения из готовых компонентов. Кстати, про песочницу SimpleOne тоже рассказали, можно попробовать платформу своими руками.
Комментарии (5)
panzerfaust
07.11.2024 15:46Лютый маркетинговый булшит уровня "магазина на диване".
Классический цикл разработки уже не успевает за скоростью изменений в бизнесе
В АСУ ТП "программирование мышкой" местами уже десятки лет в ходу. Поинтересуйтесь, успевают там за требованиями бизнеса или все равно жеппа постоянно в мыле?
аналитики Gartner предсказывают бум low-code платформ в ближайшие годы
Тот же Гартнер прогнозирует, что ИИ заменит кодеров. Вы тут что-то одно выбирайте. Если ИИ будет настолько крут, то лоукод просто даром не нужен - проще ТЗ Чятику надиктовать. И дешевле, кстати.
В классической разработке любое изменение — это квест
И классическое текстовое программирование виновато в этом в последнюю очередь. Еще ни разу не слышал на ретро, чтобы причиной факапа называли именно необходимость писать что-то буковками на Java.
написать ТЗ, передать разработчику, подождать, пока он закодит, провести тестирование, задеплоить
И собственно, в чем ваша оптимизация? ТЗ все равно нужно, кодить все равно нужно, тестить все равно нужно, деплоить все равно нужно. Только теперь это будет делать один аналитик жеппа в мыле? Или сам дядя бизнесмен полезет выяснять, почему эндпоинт пятисотит? Или пойдет разделение на аналитик-программист, аналитик-девопс и аналитик-аналитик? Ой, что-то знакомое получается.
А сейчас каждый месяц выходит новая версия фреймворка
Хоть каждую секунду. Раскрою секрет: обновляться не обязательно. У лоу-код платформ,сюрприз, тоже есть версии и тоже стоит вопрос обратной совместимости.
специалист по low-code обойдется в 2-3 раза дешевле;
время запуска первой версии — 3 месяца против 6+ по классике;
Методику расчет в студию.
С low-code бизнес-пользователь может сам внести изменения без привлечения разработчиков.
У вас в слове "санитаров" ошибка.
В общем я понимаю: бизнес, продавать эту хохлому нужно. Но для хабра аргументы крайне жидкие.
Ant80
07.11.2024 15:46как показывает практика, основная проблема не в неумении писать код, а в неумении формализовать задачу.
mixsture
07.11.2024 15:46Под визуальный стиль написано и придумано куда меньше средств снижения сложности. ООП с объединением данных и методов работы с ними, модули, функции, пространства имен. А без этого вы на порядки быстрее добежите до максимально-осознаваемой человеческим мозгом сложности.
IDE с кодом работают в разы лучше: та же пошаговая отладка с функционалом "пропустить до ... выхода из функции/входа в функцию/следующего шага в текущей функции", остановок по условию, навигация.
Под код заточены инструменты совместной разработки.
С некоторыми проблемами выше я сталкивался лично на примере бизнес-процессов в битриксе24. Вот пример с навигацией:
Открываю бизнес процесс, вижу бизнес-схему на 6 экранов в ширину и 10 в высоту. Слежу за потоком выполнения - вот условный оператор, стрелка влево от него уходит на 2 экрана и стрелка вправо на 2: представляете, какая удобная навигация? То, что в коде делается сворачиванием ветки условного оператора одним кликом в области фокуса внимания - тут я вынужден хватать полосу прокрутки внизу окна и ездить влево-вправо, следя за линией, где она повернет. Повернула? Теперь хватаем вертикальную полосу прокрутки и опускаемся вниз до следующего визуального элемента.
Что можно сказать о производительности у разработчика с этим инструментом? Да я, похоже, в "лабиринты" играю больше, чем полезное что-то делаю.
Как вы собираетесь компенсировать эти инструменты?
just-a-dev
Ошибка заложена в самой первой фразе
Здесь идёт противопоставление несопоставимых сущностей. С одной стороны - написание большого количества кода, а с другой - составление визуальных алгоритмов из готовых компонентов.
Но ведь это 2 разные вещи (оси): низкоуровневость кода (крупноблочный/детализированный) и представление (визуальное/текстовое). Никто не мешает делать сложные алгоритмы визуальными средствами, и никто не мешает в несколько строк использовать готовые компоненты.
Так как статья пропагандирует в первую очередь визуальное программирование, а не программирование готовыми блоками, то я буду высказывать мнение именно в рамках этой оси (визуал vs текст).
Вот моё мнение:
tempick
Полностью согласен. Я погружаюсь в ue5 -- и боже, как же тяжело работать с блупринтами. Сколько не пытайся всё сделать аккуратно -- выравнять блоки (что тоже отнимает время, ведь тут нет автоформатирования, которое даёт любая IDE при работе с кодом), закомментировать блоки, всё разбить на части -- все равно это выливается в нечитаемую или трудночитаемую фигню, в которой трудно даже самому разобраться
upd: одна из главных проблем - логика в blueprints - "двумерная". Т.е. я не могу просто их читать как обычный код "сверху вниз" - логика идет сразу в двух направлениях, причем никто не мешает нафигачить блоки справа налево и снизу вверх и вообще перемешать их как угодно. И копание в этом, как и форматирование всего этого - отнимает время. Но я не хейтер blueprints. Но если в другом проекте мне дадут выбор - я лучше на плюсах буду писать