«Кубики» вместо кода — год спустя

Ровно год назад мы опубликовали пост на трибуне, в котором рассказали историю low-code платформы Directual. Сегодня я поделюсь тем, что мы узнали на практике за год, и куда мы дальше двигаемся. Спойлер: кровавый энтерпрайз ушел на второй (и даже третий) план, а облачная версия платформы — на первый.

Что такое low-code?

Это подход, когда ИТ-продукты можно разрабатывать в визуальном интерфейсе. Также для этого в ходу близкие термины no-code или zero-code. Идея «накидывать приложение мышкой» появилась давно, но только в последнее годы такие продукты стали использоваться массово. Например, сейчас никто не кодит лендинги — их собирают на Tilda или Readymag. Даже наш текущий сайт на 100% сделан только дизайнером на no-code платформе Webflow. Предпосылки для такого подхода очевидны: программисты дорогие, плюс гибкость становится решающим фактором. Подвигать элементы мышкой и задеплоить по кнопке — это 5 минут. Писать ТЗ, ставить задачу и тестить — это дни, в лучшем случае.

Я бы выделил три группы low-code платформ:

  • для интерфейса (уже упомянутые Webflow, Tilda, Readymag и еще немало);
  • для интеграций (тут приходит на ум Zapier и IFTTT);
  • для бэкенда: базы данных, авторизации пользователей, какой-то логики и т. д.

Мы как раз сделали фокус на последнем пункте. Исторически, в нем меньше всего конкурентов, и он самый «программистский». Например, Firebase от Google можно частично отнести сюда. Или более простой Airtable. Причин неразвитости этого сегмента несколько. В том числе — стереотип, что на конструкторах можно сделать поделку на коленке, а для нормального решения надо нанимать программистов. Мы в Directual на своем примере доказали, что на современных low-code решениях можно делать как MVP стартапа, так и промышленные системы.

Смена фокуса в 2019

Начинали 2019 мы так:

  • Крупные заказчики, для которых наша же команда делала на платформе проекты: ПИК, МТС. Для примера, среди решений были: внутрення база знаний (замена Confluence, в котором не хватало системы согласования), конструктор договоров, оптимизация логистики панелевозов.
  • Пайплайн разработки строился, в первую очередь, под нужны консалтинг-офиса. Иногда в жертву функциональности приносилось удобство и продуманность фичи.
  • Стратегия «заработать денег на крупняке», а потом уже инвестировать в публичное облако для широкого рынка.

Что из этого вышло — далее.

Цикл продажи в крупную компанию — год. Минимум. За этот год надо выстроить отношения, сделать бесплатный пилот (для которого, возможно, нужны доработки в платформу), договориться с безопасниками и айтишниками об установке в контур. И под это нужен штат: продажники, инженеры, менеджеры. Собственно, половина консалтинг-команды трудилась на разных пресейлах.

Инсталляция On-Premise решения, которое создано на сложной модульной платформе — это отдельная история. У многих заказчиков нет нормальных девопсов, которые могли бы эксплуатировать платформу. И на пилот в контуре серверы выделяются очень экономно. В итоге, многие ключевые инженеры занимались тем, что поднимали платформу в разных контурах заказчиков, в том числе без доступа к интернету.

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

В конце 2019 года мы решились на следующее:

  • Сокращаем всю команду внедрения. Часть устраиваем к клиентам. Часть — переводим на партнерские отношения.
  • Текущие проекты не бросаем, но делаем силами партнеров-студий.
  • На основе отзывов, которые мы получили от 300 облачных бета-пользователей, делаем новую версию платформы. И открываем с ней публичное облако.
  • К релизу готовим качественные учебные пособия.

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

Что можно сделать на Directual?

Вот наглядная картинка из нашей документации (её мы еще обновляем, немного не успевая за фичами):

Что полностью разворачивается и настраивается на Directual:

  • База данных. Отлично масштабируется, можно делать импорт/экспорт в Excel, ставить слушатели на внешние SQL-базы. Тут же хранится и ролевая модель, и файлы, и логи приложения. Под капотом: MongoDB (для данных) и PostgreSQL (для метаданных).
  • Логика бэкенда. Наши сценарии (потоковая обработка данных) + отчеты (пакетная обработка). Из сценария можно постучаться во внешнюю систему через шаг http-запроса.
  • API и RBAC. По-сути — один модуль, исторически называется Security layer. Это конструктор API с кучей настроек: фильтры, сортировки, синхронные сценарии и т. д. Для Академии пришлось делать два отдельных урока по API-конструктору.
  • Портал Directual. Фича пока в альфе. Это то, что просили наши бета-тестеры. Не все готовы программировать свой фронтенд. Портал — это простой шаблон сайта, который поддерживает авторизацию. На страницы этого сайта можно накидывать компоненты, взаимодействующие с данными через API. Пока компонента три: текстовый блок, форма и отображение данных в виде карточек. Вот пример портала на Directual . Еще удобная функция: любую страницу можно вставлять как iframe к себе на сайт (в том числе собранному на конструкторах типа Webflow или Tilda).

Что не делается на Directual:

  • Тонкий клиент веб-приложения, для которого платформа работает как REST-интерфейс. Хотя, как я писал выше, можно вставлять embedded-элементы. Сам фронт можно делать хоть на чем: React, Angular, Vue, JQuery. Для ReactJS мы сделали и выложили в open source: библиотеку компонентов Directual.design и boilerplate для упрощения работы с платформой как бэкендом.
  • Мобильное приложение. Разрабатывается отдельно нативно или PWA, но может работать с теми же API-методами. Пример недавно запущенного iOS-приложения с бэком на Directual — Up&out (это что-то среднее между Tinder и Linkedin).

Для эффективного использования полезно знать основы проектирования баз данных и базу JavaScript (достаточно самого простого курса на той же Codecademy).

Предвосхищая вопрос: «Почему все на английском?», отвечу. Делать материалы на двух языках вдвое дольше. Поэтому мы пока выбрали один — международный.

Сколько стоит?

Бесплатный тариф позволяет делать все, но не нагружать платформу (по операциям процессинга — сценариям, и по запросам к API). Без ограничения по времени. Сколько надо, столько и эксперементируйте.

Тариф Startup. Дешево и сердито — $30 в месяц. С лимитами по нагрузке, которых вполне хватит на запуск MVP. Можно включить on-demand биллинг, тогда приложение не будет останавливаться при достижении лимитов, но будет сниматься дополнительная плата за превышение потребляемой мощности.

Business. За $300 вы получите в 20 раз выше лимиты, в 2,5 раза меньше цену за превышение. И SLA на 99% uptime. На таком тарифе у нас работают ребята из Schlumberger.

Что дальше?

Стратегически, наша задача следующая: дать простой и красивый инструмент для широкого рынка и вписаться в существующую экосистему low-code продуктов.

Тактически, будем делать упор на продвижение через контент-маркетинг, блог и полезные материалы формата «пошаговая инструкция как с помощью Directual и синей изоленты запилить стартап». Также хорошо видно, что развитии low-code продуктов большую роль играют сообщества пользователей. Присоединяйтесь к нашему — платформа уже открыта для регистрации!

В ближайших релизах мы планируем: добавить компонентов для портала, интеграцию с Zapier, новые кубики для сценариев. Вопросы и пожелания по фичам можно писать на форуме, или на почту [email protected].

Также мы рады сотрудничать с веб-студиями. Обучим, поделимся лицензионными платежами, и даже клиентов можем подогнать.

0
33 комментария
Написать комментарий...
Gennadiy Mohov

Я ботика могу запилить 😂

Ответить
Развернуть ветку
Valera Rybakoff

За LCDP будущее, но для хорошей реализации надо быть гением.

Ответить
Развернуть ветку
vic buynoff

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

Ответить
Развернуть ветку
Valera Rybakoff

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

Ответить
Развернуть ветку
Artem Shevchenko

Нет, это невозможно, потому что любое ПО это не только один код, а деньги, деньги и ещё раз деньги. Что вряд ли возможно в полном объеме для опенсорса

Ответить
Развернуть ветку
vic buynoff

Весь опенсорс построен на платном обслуживании бизнеса. 

Ответить
Развернуть ветку
SL Potapenko

расскажите это Talend c их Talend OS https://www.talend.com/products/

Ответить
Развернуть ветку
Вадим Парамонов

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

Ответить
Развернуть ветку
vic buynoff
 Ну если вести единый стандарт интеграций, как например с портами подключения на пк (usb), телефонах и т. д.

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

Ответить
Развернуть ветку
Dmitry Tinitilov

Это почти как SQL задумывался как язык для домохозяек. Домохозяйки на нем так и не пишут, но подход реализован необычный)

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Pavel Ershov
Автор

Баббл прекрасен для несложных решений. Постараемся написать сравнения лоу-код платформ в ближайшее время.

Ответить
Развернуть ветку
vic buynoff

Лоу код - по определению для несложных решений.

Ответить
Развернуть ветку
Pavel Ershov
Автор

А автомобиль никогда не станет популярнее лошади!

Ответить
Развернуть ветку
vic buynoff

Некорректное сравнение.

Ответить
Развернуть ветку
Nataniel Bampoo

Я хочу ездить - вот вам готовый автомобиль.
Я хочу быстро ездить - ну ок, вот вам быстрый автомобиль.
Но мне ещё нужен откидной верх - быстрый кабриолет ждёт вас.
И ковш как у экскаватора, ах да, он должен быть на гусеницах - эм... У нас нет вариантов для вас, создайте сами..

И тут Лоу код уходит на второй план.

Ответить
Развернуть ветку
vic buynoff

В итоге, у вас получился конструктор БЭ. БД вы взяли готовый, ФЭ тоже взяли готовый. Продукт полюбому придется в сотнях маст допиливать, надстраивать и интегрировать. Очевидный вопрос - зачем? Какую проблему конечного потребителя вы решаете?

Ответить
Развернуть ветку
Art

нет боли в этом и проблема )

Ответить
Развернуть ветку
Mikhail Yakupov

О, Павел, помню, как общались с вами по решению для email-маркетинга и dmp лет 5 назад. ( http://ritworld.com/proekt-directual-pobedil-v-nominacii-sberbank-awards-texnologii-budushhe-go-dlya-biznesa-v-ramkax-generations-2015/  ) те же блоки и схемы, входной порог от 3 млн.р., безграничные возможности в области решения узких задач. Название продукта решили оставить? Желаю удачи в этом pivot'е!

Ответить
Развернуть ветку
Pavel Ershov
Автор

Да, это развитие технологии. Спасибо!

Ответить
Развернуть ветку
vic buynoff
 кровавый энтерпрайз ушел на второй (и даже третий) план, на первое место выходят веб-студии

Намеренно убегаете от денег? То есть у вас нечто вроде социального проекта, призванного дать рынку еще один клевый, но невостребованный инструмент?

Ответить
Развернуть ветку
Pavel Ershov
Автор

Вы, наверное, не дочитали. Там описано, что энтерпрайз оттягивает на себя все ресурсы от продукта. И клевый инструмент по определению будет востребованным, иначе он не клевый на самом деле.

Ответить
Развернуть ветку
vic buynoff
клевый инструмент по определению будет востребованным

Здесь конечно можно поспорить и аргументированно возразить, но лень.

Ответить
Развернуть ветку
Art

клевый инструмент != востребованный. Что вы как в детском саду, честное слово ну.

Ответить
Развернуть ветку
Аккаунт удален

Комментарий недоступен

Ответить
Развернуть ветку
Лев Щенин

Зашёл к автору на его сайт, посмотрел видеоролик "О нас".
Девочка фигуристая очень понравилась.
К сожалению, как все разработчики, автор ничего не понимает в продажах своего сервиса.
Написал им предложение в Фейсбуке.
Как получу от них ответ - напишу здесь свой отзыв о клиенто-ориентированности этой компании.

Ответить
Развернуть ветку
Yuriy Artamonov

Какому бизнесу это может быть интересно? В документации перекати-поле.
Нет, серьёзно - пусто: 1 заголовок и 1 скриншот: https://readme.directual.com/getting-started/app-interface-overview/reports

Ответить
Развернуть ветку
Pavel Ershov
Автор

Документацию приводим в порядок!
А по вопросу: какому бизнесу может быть интересно создание ит-продуктов быстрее и дешевле?

Ответить
Развернуть ветку
Yuriy Artamonov

Пока для себя отметил, что сгенерировать проект на Java или .Net по шаблонам даст бизнесу больше, чем предложенное решение.

Ответить
Развернуть ветку
vic buynoff

Дешевых генераторов дешевых IT продуктов уже очень много на рынке. Чем ваш лучше?

Ответить
Развернуть ветку
Антон Лазовский

У вас на странице https://readme.directual.com/features техписы придумали новый почтовый протокол - STMP 

Ответить
Развернуть ветку
Pavel Ershov
Автор

Спасибо, доку приведем в порядок

Ответить
Развернуть ветку
Жандос Нуфтиев

Вроде бы классная идея, но потом я вспомнил какой бардак и раздрай во фреймворках и стандартах происходит всегда, взять хотя бы фронтенд, где чуть ли не каждый месяц новый фреймворк

Ответить
Развернуть ветку
30 комментариев
Раскрывать всегда