Low-code: мифы и реальность

Алексей Пушкарев, ведущий архитектор продуктовых решений ELMA, — об основных мифах о Low-Code платформах, их опровержении, о трендах на рынке Low-Code и грамотном применении таких технологий для решения различных бизнес-задач.

«Хорошие» и «плохие» задачи для Low-code

Не существует жестких требований под задачи, подходящие для Low-code, но есть определенные маркеры, указывающие на то, что система подходит для конкретных задач, и на них можно опираться. И первый такой маркер — если клиент разрабатывает приложение для сотрудников своей компании, а не публичный сервис, не социальную сеть или новостной ресурс, а именно что-то, что сотрудники будут интенсивно и ежедневно использовать. 

Следующий маркер – это автоматизация рутинных задач: Low-code решения автоматизируют некую ежедневную работу, взаимодействие и коммуникации со своими сотрудниками в таком формальном режиме. 

Также Low-code хорош, если у заказчика постоянно меняются требования (что встречается нередко на рынках, в том числе в связи с изменением трендов). Нужна какая-то динамичная, меняющаяся сфера. Именно это чаще всего касается основного бизнес-процесса компании по созданию своего продукта, который должен адаптироваться под рынок, постоянно меняться, по которому постоянно возникают доработки. 

Еще один важный аспект – автоматизация бюрократии. Low-code заменяет бумажные процессы на автоматизированный инструмент, параллельно решая все формальные вопросы. 

И последний маркер — это ориентация на эффективность. Low-code хорош, если подход всей компании ориентирован не на идеальные, а на своевременные и качественные решения.

Одновременно существует ряд маркеров, свидетельствующих о том, что Low-code не подходит. Во-первых, это задачи обработки массивов данных: в Low-code системах они моментально сводятся к коду, и именно преимущества самой системы здесь раскрыть невозможно. Поэтому лучше сразу же решать такие задачи программными инструментами.

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

Еще один фактор – это уникальные и сложные интерфейсы. Если основная ценность приложения – как раз сложные интерфейсы (например, система моделирования геологического пласта с уникальным 3D-интерфейсом и возможностью построения этих сложных схем), то Low-code система будет не очень подходить из-за специфических требований и необходимости кастомной разработки. Проще уже подходить тогда с High-code подходом.

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

Не “дружит” с Low-code и специализированный софт наподобие графических, текстовых и музыкальных редакторов из-за особенностей интерфейса и ориентированности на одного сотрудника. И, наконец, для микробизнеса применение своей разработки тоже нельзя назвать оправданной, такая автоматизация не будет окупаться в силу масштаба. В таких случаях лучше либо работать вообще вручную, либо брать какие-то коробочные решения. Из этого правила могут быть исключения, но в общем случае это так.

Нужны ли для Low-code разработчики?

В рекламных объявлениях часто пишут, что с покупкой Low-code платформы бизнес-пользователи смогут создавать свои приложения без участия программистов. Звучит весьма заманчиво, но, к сожалению, в жизни все немножко сложнее. 

Сама по себе разработка и сама сложность задач – она такая, что требует компетенций по архитектуре, по навыкам структурирования данных, аналитического и местами даже программистского мышления. У бизнес-пользователей не всегда все это есть. Конечно, с опытом работы и по мере изучения инструмента они уже начнут создавать приложения все лучше и лучше, но в целом это не главная задача. 

Значит ли это, что вообще не стоит привлекать к разработке бизнес-пользователей? Тоже нет. Есть ниша, в которой себя Low-code вполне себе неплохо проявляет. Это различные локальные решения. Довольно многим знакомы корпоративные решения наподобие Excel, на которых держится половина бизнеса: когда пользователи сами делают свои таблички, в них ведут свой учет, выстраивают свои процессы. И для таких локальных разработок как раз подойдут Low-code решения. С их помощью легко без программистских навыков создать какую-то несложную форму и у себя в отделе, например, это использовать. По мере роста и тиражирования решения на всю компанию уже стоит подключить профессиональных лоу-кодеров, которые смогут имеющееся решение переструктурировать, сделать его лучше, правильнее и уже приносить пользу не на уровне какого-то отдельного сегмента бизнеса, а уже на уровне всей компании.

Без специалистов с техническим бэкграундом в работе с Low-code не обойтись. Они нужны для разработки. Но и пользователь без навыков написания кода способен запустить несложный бизнес-процесс, работать с несложной структурой данных или запустить приложение для одного отдела.

Миф: Low-code не выдерживает высокой нагрузки 

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

Если говорить про системы с миллионами пользователей, с обработкой терабайт данных в секунду, то, скорее всего, Low-code здесь будет не лучшим решением. В этих случаях требуется тонкая, сложная оптимизация, которая под силу не каждому разработчику. Тут нужна команда из программистов уровня senior, которые умеют такие задачи решать.

Но если брать решения, используемые внутри компании, то, как правило, штат – это не несколько миллионов сотрудников, а сотни и тысячи. Современные Low-code системы успешно проходят тесты на 10 тысяч сотрудников, но разработчики постепенно повышают планку и хотим взять следующие рубежи. И на этих нагрузках вполне себе можно справляться. 

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

Также не стоит забывать про оптимальное написание и оптимизацию Low-code решений, чтобы грамотные специалисты проверяли либо кодовую часть, либо построение решения. С помощью Low-code, как правило, задачу можно решить несколькими способами, и нужны специалисты, способные определить правильный способ. Естественно, нужны еще и архитекторы: они должны уметь правильно построить структуру решения, от которой будет идти вся разработка. И тогда можно прибегать к такому способу, как вынесение тяжелых операций на внешние сервисы. Если речь идет о тяжелой обработке данных, ее можно вынести в отдельный High-code сервис и интегрировать с ним Low-code систему, чтобы не нагружать основные рабочие процессы.

Миф: программист напишет быстрее

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

Конечно, алгоритмы тоже можно  реализовать через BPMN, но это нецелесообразно. 

Low-code системы в своих конструкторах привносят новые концепции, которыми начинает думать задействованный в работе с ними программист.  Когда происходил переход от машинного кода, от ассемблеров, к языкам высокого уровня, тоже происходила подобная трансформация. Люди переставали думать в математических операциях и адресах ячеек памяти, у них появлялись новые концепции: объекты, переменные, потоки, каналы. Все эти структуры – они меняют мышление, само то, как мы думаем при построении нашего приложения. Так и Low-code стремится для автоматизации именно бизнес-задач дать такой инструмент, на котором удобнее думать разработчику. В его основе лежат конструкторы процессов и интерфейсов, за счет которых в разработку привносятся новые абстракции и меняется мышление программистов.

Реалистичные ожидания от Low-code

Главное в работе с Low-code — сформировать реалистичные ожидания от этого инструмента и применять его грамотно и к месту. По сути, Low-code – это такой фреймворк для разработки, просто в отличие от программных фреймворков он использует не только код, но еще и визуальные средства для конструирования своего приложения. 

Бизнес-пользователи могут решать какие-то свои локальные задачи, а в случае масштабирования и перехода на более сложный уровень уже стоит подключать профессиональных лоу-кодеров, которые специализируются на системе. Грамотный подход к IT-инфраструктуре, к самому созданию своих приложений позволит строить высокопроизводительные решения и достигать результатов. 

Еще один вывод состоит в том, что Low-code – это не просто компоновка кусков кода, а платформа, способная дать пользователю новые абстракции для мышления при построении своих приложений. 

Зависимости от поставщика в случае использования Low-code систем не избежать, но если грамотно подойти к выбору поставщика, то должно быть все хорошо. Важно оценивать:

• как долго компания работает на рынке;
• есть ли политические и экономические риски ее ухода с рынка;
• каков приоритет продукта в портфеле компании.

Сейчас на российском рынке внедряются практики CI/CD. О них, может быть, не так громко говорят, как о тенденциях на рынке Low-code в целом, но многие вендоры пытаются внедрить этот подход для построения не просто каких-то неважных ненагруженных приложений, но и тех, от которых многое зависит. При этом за счет длительного и тщательного процесса тестирования, вы можете быть уверенными, что решение будет хорошо работать.И при выборе для типовых задач, которые похожи у большинства компаний, вполне можно прибегать к коробочным решениям, а для работы с уникальными частями IT-инфраструктуры очень хорошо подходит грамотно выбранная Low-code платформа.