Low-code платформы (Low code application platforms, LCAP) возникли как реакция на сложность и многообразие современных средств разработки ПО.
Согласно Gartner, одним из самых известных игроков в этой области является Mendix. Продажа Siemens за космические $700 млн. это подтверждает. Так что я буду использовать эту платформу как пример, хотя аналогичные выводы будут верны и для Outsystems, Appian, Kony, Betty Blocks и других.
Итак, ориентируя продажи на топ-менеджеров, вендоры low code платформ обещают, что даже простые пользователи смогут самостоятельно создавать бизнес-приложения.
То есть разработчики больше не нужны?!
Нуу…, через несколько лет Mendix вынужден признать:
"Сейчас разработчики нужны больше, чем когда-либо"
Вот это поворот!
Похоже, в Mendix признали, что для чего-либо сложнее базовой работы с данными по-прежнему требуется профессиональный разработчик, точно так же, как для обслуживания автомобиля нужен профессиональный механик.
К сожалению, современные low code платформы просто не созданы для разработчиков, и полагаться на них в долгосрочной перспективе рискованно для бизнеса. Если в вашей компании серьезно рассматривают использование low code платформ в промышленной эксплуатации, стоит еще раз взвесить это решение. Ниже я постараюсь это аргументировать.
Отличный инструмент для прототипирования
Mendix — это действительно отличный вариант для автоматизации простых процессов или создания прототипов, доступный аналитикам или продвинутым пользователям.
Визуальный редактор позволяет описать модель данных, быстро создать экраны с помощью набора виджетов и шаблонов и даже описать логику с помощью так называемых microflows:
По завершении можно в один клик развернуть свое приложение в облаке Mendix и начать с ним работу. Так просто, что похоже на магию! И похоже, это неплохо продается.
Однако после прохождения стадии прототипа взаимодействие системы с пользователем и бизнес-логика почти неизбежно усложняются. Чтобы развивать проект дальше, требуется профессионал. Итак, давайте посмотрим на Mendix глазами разработчика.
Медленная разработка
Любая логика — будь то вычисления или взаимодействие с пользователем — должна быть описана в блок-схеме (microflow), как показано выше.
Здесь есть несколько проблем.
Во-первых, это долго. Очевидно, быстрее написать 10 строк кода в хорошей IDE, чем перетаскивать, настраивать и соединять десятки блоков.
Во-вторых, читаемость. Блоки выглядят красиво, но что значит это Sub_RegistrationValidation? Понять это не провалившись внутрь блока невозможно. Как только количество блоков вырастет до нескольких десятков, разобраться в логике станет крайне сложно.
Как альтернативу для сложных случаев, Mendix поддерживает вызовы Java кода из microflows. Код можно писать в Eclipse, что в целом неплохо, хотя многие предпочли бы более популярную IDE. Минус в отсутствии прозрачности: все точки входа находятся в microflows, так что логика разбросана между двумя слабо связанными средами. Как результат, отладка и отслеживание зависимостей затруднены.
Последнее, что я хотел упомянуть — это контроль версий.
Хорошая новость в том, что он есть. Плохая — в том, что он представляет собой урезанный вариант Subversion. Забудьте о git flow.
Отсутствие контроля
Любой, кто знаком с экосистемой Java, не может недооценивать силу open source. Когда где-то в стеке появляется ошибка, вы видите, в какой части кода это произошло. Код можно отладить, чтобы точно понять, что происходит. Можно загуглить решение. Можно отправить pull request. В крайнем случае, можно форкнуть библиотеку. Вы полностью контролируете проект.
С Mendix об этом можно забыть. Это закрытый коммерческий фреймворк, и что происходит внутри него — настоящий черный ящик. Все, что вам остается, — купить платную поддержку или ждать, что кто-то поможет на форуме с ~200 вопросами в месяц (сравните с тегом #spring на stackoverflow!).
Зависимость от вендора
Mendix наверняка довольно часто этим попрекают. Они даже опубликовали статью о том, что на самом деле нет никакой зависимости. Если читать между срок, она гласит:
Вы можете получить свои данные, DDL, UI ресурсы и код (microflow волшебным образом преобразованные в Java код).
Будет ли это исполняться или компилироваться без рантайма и API Mendix? Можно ли это поддерживать и развивать? Вопросы риторические. На самом деле потребуется полностью все переписать. Вы зависите от проприетарной платформы. Вы не владеете созданной вами системой.
Ограниченная масштабируемость
Маркетинг Mendix ориентирован на крупнейшие компании, поэтому термин "масштабируемость" постоянно мелькает в маркетинговых материалах.
В 2017 году Mendix представили stateless runtime — то есть вся информация о сессии либо хранится на стороне клиента, либо в персистентном хранилище.
Теоретически это означает неограниченную горизонтальную масштабируемость. Звучит здорово, но как обычно есть нюанс — база данных.
База данных практически всегда оказывается узким местом в корпоративном приложении. Итак, что же хранит данные за множеством stateless-серверов Mendix? Никаких сюрпризов — это старая добрая реляционная база данных. В облаке Mendix — PostgreSQL. Более того, сгенерированный Mendix DDL, скажем мягко, не совсем оптимален. Например, я видел промежуточную таблицу, которая обычно используется для моделирования отношений N:M, созданную для отношения 1:N.
Вопрос масштабируемости можно было бы решить стандартными методами: оптимизацией структуры БД, кэшированием или даже используя такие решения, как Citus. Но такой возможности естественно нет.
Единственным способом масштабирования БД остается масштабирование с использованием реплик для чтения (например, Amazon RDS). Но для записи это не сработает.
Резюмируя вышесказанное, в Mendix заложено фундаментальное ограничение масштабируемости и нет средств для оптимизации производительности.
Кадровый вопрос
Поиск квалифицированных кадров — всегда сложная задача. Казалось бы, в этом Mendix — мечта любого менеджера, ведь требования к квалификации резко снижаются.
На деле мы уже выяснили, что для реализации большинства проектов требуется профессиональная команда, независимо от инструмента. Вот только вряд ли какой-либо уважающий себя разработчик согласится работать с Mendix, так как это очевидный тупик в карьере.
Цены
Последнее, но не менее важное. Стоимость лицензии на одно приложение начинается от $1875 в месяц при условии подписки на три года, лицензия ограничена 50 внутренними пользователями.
Цена корпоративной лицензии с возможностью локального развертывания начинается от $7825, а это почти $100 000 в год.
Среднего размера предприятие с несколькими сотнями пользователей будет ежегодно оплачивать счета на десятки миллионов рублей.
Не забывайте, что речь идет об относительно простых приложениях, как вы могли понять по написанному выше. По мне, это безумие. Эта модель ценообразования также фактически делает невозможным тиражирование созданных вами приложений.
Тогда почему LCAP все еще популярны?
На мой взгляд причина кроется в разочаровании в существующих процессах. Управлять командой разработчиков в крупной организации — независимо от того, внутренняя это команда или аутсорс — оказывается слишком сложно.
Планирование бюджета, бесконечные согласования, отсутствие людей, готовых брать ответственность — думаю, это многим знакомо.
Самое забавное, что первое, что приходит в голову, когда ИТ проекты движутся слишком медленно, — это нанять еще больше разработчиков и, конечно же, менеджеров. Стоит ли говорить, что это только ухудшает ситуацию. Я знаю пару банков, в которых более 10 000 (!!!) разработчиков, и по меньшей мере половина из них занимается бесполезной работой.
В отчаянии руководители предприятий ищут решение в таких "волшебных палочках", как LCAP, якобы способных решить все проблемы.
Как выбираться из этого замкнутого круга — тема для отдельной статьи. Но это вопрос управления, а не технологий.
Не вдаваясь в подробности, если вам удастся создать небольшую квалифицированную команду из 3-10 полностью вовлеченных в проект человек, с прямым контактом с ЛПР, вы получите отличные результаты быстрее и дешевле, чем ожидаете.
Каковы альтернативы?
Сейчас есть огромный выбор инструментов и фреймворков для разработчиков.
Например, Spring Framework — самая популярная open-source технология для создания корпоративного ПО, которая отлично сочетается с веб-фреймворками вроде React или Angular. А такие инструменты, как Spring Initializr и JHipster, значительно упростили создание проектов за последние несколько лет.
Если вы хотите получить результат быстрее, стоит рассмотреть RAD инструменты, такие как CUBA Platform.
Она создана на основе того же Spring Framework, дополняет его визуальными инструментами разработки и огромным количеством готовых компонентов. Пожалуй, это ближайшая альтернатива LCAP, обеспечивающая гибкость и комфортный процесс разработки.
Окончательный выбор должен зависеть от поставленной задачи, а также навыков команды и ваших предпочтений.
Заключение
Low-code платформы отлично подходят для прототипирования. Они сокращают разрыв между бизнес-пользователями и IT, что позволяет быстро получить работающий прототип и сформировать видение будущей системы.
Поскольку пользователей прототипа очень мало, затраты на этом этапе тоже невелики. И именно в этот момент стоит остановиться!
При использовании LCAP для разработки полноценной системы скорость работы неизбежно упадет, и вы будете зависеть от дорогой, ограничивающей вас проприетарной платформы.
Автор: Андрей Глащенко
