30-ти секундний підсумок
low-code пришвидшує операції таких випадках:
- Прості транзакційні програми
2. Рішення для внутрішнього використання
3. Перевірка нових бізнес-концепцій чи продуктів
4. Невелика команда розробників
З більшою складністю ви отримуєте обмеження з багатьох причин:
Платформи з низьким кодом не призначені для широкомасштабної паралельної розробки та розгортання
Це найкраще працює, коли ви послаблюєте бізнес-вимоги (будьте простішими)
На відміну від обіцянки: людей, які мають належні навички, важко знайти
Зрештою, це не настільки low-code, а швидше платформа продуктивності
Ви не маєте повного контролю над роботою
Вони масштабуються підлінійно (вертикальне масштабування та спільні ресурси)
Проблеми доступності через помилоки в доменах через тісно пов’язану конструкцію
За допомогою перевірених моделей ви можете використати переваги low-code в 4 сценаріях та уникнути обмежень, коли складність зростає.
Вступ
Протягом останніх 12 місяців я працював над двома продуктами, використовуючи платформу з Low code. Один був бек-офісним додатком, а інший – онлайн маркетплейс. Для одного з них команда використовувала BettyBlocks, а для іншого – Outsystems.
Спочатку я скептично ставився до платформ з law-code . Тепер я впевнений, що ви використовуєте його для тієї мети, для якої він призначений. І саме тут речі в ІТ часто йдуть не так: люди використовують технології там, де це може бути не найкращим чином, бо це все, що вони знають, а може, тому, що це ажіотаж. Очікування великі, але незабаром з’являється розчарування. У цій публікації я хотів би поділитися з вами, як би я отримав найбільшу цінність, використовуючи платформи з low-code, і як уникнути розчарування. З точки зору ажіотажного циклу Gartner, я сподіваюся вивести вас на плато продуктивності з низькими платформами коду.
По-перше, я маю на увазі 2 основні цілі будь-якої організації програмних технологій відповідно до книги Accelerate (Форсгрен, Хамбл, Кім):
Швидко доставляйте рішення
Працюють стабільно у виробництві
Причина, по якій я використовую такий підхід, полягає в тому, що будь-яке рішення, яке я вирішую для вирішення проблеми, має допомогти мені швидше доставляти та працювати стабільніше. Якщо це не допомагає команді бути швидкими та стабільно працювати, тоді вам може знадобитися інша технологія для вашої конкретної проблеми. Крім того, може бути, що рішення з низьким кодом добре працює сьогодні, але не в наступні дні. Наприклад, тому що ваше рішення працює, коли воно невелике, але не в більших масштабах. Я перейду до цього пізніше.
По-друге, я розрізняю 2 області вирішення:
Прості транзакційні програми або CRUD-програми (Створення, читання, оновлення, видалення) з основними формами, які використовують користувачі
Більш складні веб-програми
Спочатку подумайте про внутрішні програми, щоб просто вести записи. По-друге, подумайте про веб-магазини, базари, складні потоки користувачів, рішення для різних пристроїв тощо
Подумайте про це на шкалі придатності до не дуже придатності:
Якщо у вас простий сценарій, то я б сказав, подумайте про low-code (якщо ви можете дозволити собі витрати на ліцензію). Якщо ваша проблема більше схожа на складний сценарій, продовжуйте читати.
Low-code і швидкість: це для спринту, а не марафону
На графіку нижче я уявив, як, на моєму досвіді, швидкість змінюється з часом у середовищі з low-code порівняно з рішенням ручного коду. Звичайно, я припускаю, що кодоване рішення вручну виконано добре: модульно, горизонтально масштабовано тощо.
Я хочу проілюструвати, що спочатку low-code швидкий. Для цього є кілька причин:
Навряд чи є якесь покриття котла, тому ви можете почати одразу і додати цінність з 1-го дня
Доступно багато готових компонентів, якими ви можете швидко скористатися
Однак, коли ви зростаєте, ви отримуєте зменшення прибутковості: ви можете подвоїти свою команду в розмірі, але ви не отримаєте вдвічі більший результат. Дві основні причини цього:
платформи з low-code розроблені для швидкого надання функціональних можливостей, але вони навряд чи зосереджуються на нефункціональних (ремонтопридатність, масштабованість, доступність та багато інших “-ілітій”)
платформи з low-code все ще трохи відстають від сучасних практик розробки для великих команд, наприклад, важко робити темні запуски або випуски канарок, розгортання нульових простоїв часто не є можливим, служби підтримки, такі як база даних, є спільними.
Отже, це, на мій погляд, компромісний варіант з low-code : ви швидко отримуєте функціональність, але це коштує за рахунок не функціонерів. Як тільки ви стаєте більшими, саме тоді це зашкодить, тому вам потрібно планувати цього уникати.
Я не стверджую, що всі платформи з low-code є поганими для нефункціональних осіб. Це просто не їх сила, а результат компромісу, який вони зробили. Вам потрібно це врахувати, щоб уникнути розчарування. Нижче я ділюсь кількома з цих міркувань.
Не призначений для паралельної розробки та розгортання
Низькокодові платформи, як правило, мають монолітні основи кодів. Це не обов’язково погано: монолітний дизайн – це шаблон, як і архітектура послуг або модульна архітектура. У певних сценаріях це працює добре, однак із деякими проблемами: якщо ви розгортаєтеся на виробництві, ви розгортаєте все. Як результат, всі роботи повинні бути завершені, робота не може бути незавершеною.
Вихідним шляхом може бути реалізація рішення перемикання функцій самостійно, так що функціональність за замовчуванням вимкнена і може бути ввімкнена, коли буде готова. Тоді ви можете розгорнути моноліт, поки він ще не закінчив роботу. Це здебільшого не з коробки, тому ви повинні побудувати це самостійно.
Зверніть увагу, що коли ви плануєте продовжувати працювати з невеликою командою, це не проблема. Однак, коли ви плануєте збільшити масштаб, вам потрібно діяти відповідно, використовуючи платформу з низьким кодом, щоб уникнути уповільнення, як показано на малюнку.
Послабте вимоги бізнесу, інакше це буде не так швидко
Базові рішення можна швидко розробити без надто великих технічних знань. Однак із більш складними вимогами ви швидко досягаєте меж можливостей платформи. Деякі платформи не можуть їх підтримувати, тоді як інші дозволяють більше розробляти на замовлення. Завдяки розробці на замовлення ви не отримуєте всіх низьких переваг коду з точки зору швидкості та необхідних знань. Якщо ви робите це занадто складним, не звинувачуйте систему низького коду, коли стикаєтеся з проблемами: вони не призначені для цього. Будьте простішими або виберіть інше рішення, яке більше відповідає вашим потребам.
Залучити талант важко і може сповільнити вас
Якщо ви успішно працюєте у своєму бізнесі, можливо, ви хочете збільшити кількість команди. Крім того, якщо ви вирішили зробити більше власних розробок, замість того, щоб робити їх простими, вам потрібно більше розробників для реалізації цієї функціональності.
Тут також часто починається розчарування: дуже важко знайти потрібних людей за гідною ціною. Для ручного кодування потрібні кваліфіковані інженери, і завдяки наявності багатьох відкритих фреймворків доступність є відносно високою. Низькокодові платформи – це власні системи з набагато меншим співтовариством розробників. Дуже важко залучити талановитих розробників та консалтингові компанії, які готові вам допомогти, але не за найменші витрати. Перевага швидкості може бути легко скасована за час, щоб залучити людей і пов’язані з цим витрати.
Платформа продуктивності замість платформи з низьким кодом
Вище я заявив, що вам потрібно знизити вимоги та зробити це простим, щоб ви продовжували отримувати переваги швидкості. Однак реальність така, що це дуже важко. У такому випадку низький код стає не надто низьким, і ви наближаєтесь до ручного кодування. У цьому сценарії я бачу ці платформи більше як рішення для підвищення продуктивності розробників. Платформи продуктивності для розробників замість платформ із низьким кодом. Однак у більших масштабах (кілька команд, більша база коду) ви все одно стаєте менш продуктивними з причин, згаданих вище.
Наведені вище приклади швидкості удару. Деякі не функціонери також впливають на стабільність виробництва. Вони описані в наступному розділі.
Низький код і стабільність: він працює сьогодні, але буде працювати завтра?
Коли ви доставляєте швидко, ваші клієнти або зацікавлені сторони будуть задоволені, якщо у вас низька продуктивність або часті простої. Якщо ви не можете користуватися системою, вона все одно не має значення. Ось чому в цьому розділі я ділюсь своїм досвідом щодо стабільності платформ з низьким кодом.
Відсутність повного контролю продуктивності
Як зазначено у визначенні вище, низький код допомагає створювати програмне забезпечення з графічною конфігурацією замість ручного кодування. Це призводить до (1) згенерованого коду та / або (2) метаданих, які потрібно отримати під час виконання. Обидва результати призводять до відносно низької продуктивності. Я зазначаю „відносний”, оскільки для внутрішніх програм завантаження сторінки може бути прийнятним за 3 секунди, але для електронної комерції це не так. Тепер ви можете аналізувати запит сторінки, використовуючи інструменти тестування навантаження та рішення для моніторингу реальних користувачів, щоб знайти вузькі місця, але ви можете налаштувати його лише настільки, наскільки це дозволяє платформа з низьким кодом. У поєднанні з нижченаведеними пунктами це може спричинити проблеми більшого масштабу.
Вертикальне масштабування обмежене
Низькокодові платформи часто мають фоновий та інтерфейсний рівень. Для деяких інтерфейс розділений на рівень API та рівень інтерфейсу.
Фоновий шар – це переважно реляційна база даних. Ці бази даних розроблені для узгодженості та доступності, а не стільки для масштабованості. Отже, реляційні бази даних – це дуже хороший вибір, коли вам потрібні послідовність і доступність, але якщо вам потрібна масштабованість, вам слід знати, що ви обмежені тут: ви можете масштабувати лише вертикально, отримуючи більший сервер, і це збільшить витрати на вашу ліцензію плата. Деякі реляційні бази даних підтримують горизонтальне масштабування, але більшість платформ із низьким кодом не підтримують ці бази даних.
Вибір бази даних у низькому коді не лише призводить до проблем масштабування. Див. Наступний параграф для цього.
Тісно пов’язана конструкція призводить до окремих точок відмов та великих доменів несправностей
Більшість платформ мають спільний сервер баз даних. Це означає, що коли у вас є кілька додатків або кілька модулів у програмах, всі вони зберігають свої дані в одній базі даних. Крім того, ці програми часто використовують один і той же сервер додатків, що призводить до того, що проблеми з програмами часто впливають і на інші програми. Наприклад, якщо в одній програмі є пошуковий запит, усі інші мають нижчу продуктивність. Або якщо для розгортання однієї програми потрібен час простою, усі інші додатки мають час простою.
Більшість платформ пропонують налаштування високої доступності, і ви можете використовувати це, щоб обмежити ці недоліки. Однак це знову має ціну, яка є відносно високою порівняно з іншими типами рішень.
Наразі я перелічив деякі речі, які слід врахувати, коли ви плануєте використовувати платформи з низьким кодом у більшому масштабі та для більш складних програм. Що стосується швидкості та стабільності, я перерахував три міркування. Виходячи з них, ви, мабуть, вже потрапляєте в випадки, коли платформи з низьким кодом працюють добре і де вони працюють не так добре. Дозвольте мені зараз навести вам кілька прикладів, а також рекомендовані моделі.
Випадки, коли низький код працює нормально: коли великі масштаби та стабільність (поки що) не важливі
Після прочитання всього вищезазначеного ви можете відчути, що низький код не для вас. Але, як і у випадку з багатьма ІТ-рішеннями, це може підійти. Як вже було сказано, коли ви використовуєте його за призначенням, коли використовуєте його сильні сторони та коли плануєте вирішити слабкі місця. На мій погляд, наступні випадки добре підходять для використання платформи з низьким кодом:
Вийти з цих характеристик можна кількома способами:
Ваш простий додаток перетворюється на більш складний
Внутрішня програма піддається зовнішньому світу з різними потребами / рівнем обслуговування
Ваш новий продукт добре відгукується, і ваша база користувачів збільшується
Через більший попит ваша команда зростає
Ці події позитивні, і без вашої платформи з низьким кодом, можливо, знадобилося б більше часу, щоб дістатися до цього. Тепер вам потрібно подбати про те, щоб не обмежуватися, тому що ви потрапляєте на територію, де низький код менш підходить. Тому я рекомендую планувати наступні моделі або шлях зростання.
Рекомендований шлях зростання
Поки ваші зацікавлені сторони або клієнти все ще задоволені, вам потрібно розпочати обговорення того, що потрібно, щоб зробити їх щасливими. Це не завжди легко, оскільки (як показано нижче), все це стосується архітектури та погашення технічного боргу. Обидва елементи невидимі в порівнянні з функціями та помилками.
У людей є достатньо часу, щоб обговорити особливості та помилки, оскільки вони помітні, цінні та відчутні. На відміну від цього, архітектура та технічний борг є більш абстрактними і не мають безпосереднього значення. Ось чому вам потрібно спланувати це з першого дня. Коли ви починаєте перший день, будуючи програму з низьким кодом, також ініціюйте дискусію, яка потрібна для того, щоб задати очікування та зробити всіх щасливими. Для цього я рекомендую кілька етапів, які узгоджують короткострокові цілі з довгостроковими потребами.
1 – фаза навчання
Ви починаєте з простої програми. Немає перспективи для більш складних вимог, тому ви не хочете виконувати передчасну оптимізацію.
А може, ваш новий продукт або бізнес-концепція навіть не перевірені. У вас є сподівання, у вас є дизайн і цільова група для тестування, і тепер вам потрібно доставити якнайшвидше. Також тут просто використовуйте свою платформу з низьким кодом з усіма її функціями, щоб швидко рухатися.
В обох випадках немає необхідності обробляти великі обсяги використання або підтримувати великі команди розробників. Однак почніть встановлювати очікування для наступних 3 кроків.
2 – роз’єднати задній і передній кінці
Я б почав працювати над цим кроком, як тільки ви отримаєте ознаки того, що ваша заявка буде успішною. Якщо ні, то просто залиште як є. Більшість платформ мають можливість будувати рівень API поверх своєї бази даних. Деякі можуть зробити це навіть за задумом. В останньому випадку все готово. Якщо ні, то переконайтеся, що ваш користувальницький інтерфейс підключається до рівня API, який відкриває базу даних. Переважно ви будуєте це на платформі з низьким кодом, щоб використовувати його функції для високої швидкості. Пізніше, на фазі 4, ви перенесете це на іншу платформу.
Такі рішення часто називають Back-end For Front-End (BFF) або шлюзом.
3 – масштабування заднього кінця
Тепер, коли ви роз’єднали інтерфейс і інтерфейс, ви вже можете скористатися деякими перевагами:
Ви можете самостійно розробляти інтерфейс і інтерфейс із власною швидкістю
Ви можете змінити серверну реалізацію без (занадто сильного) впливу на інтерфейс і кінцевих користувачів
Візьмемо, наприклад, веб-магазин. Коли ви шукаєте товар і натискаєте на нього, він відкриває сторінку деталей продукту. Ця сторінка містить Вміст продукту та Пропозицію товару (час доставки, ціна тощо). Вміст не сильно змінюється. Пропозиції змінюються частіше. Скажімо, у вас є проблеми з продуктивністю при відображенні вмісту та пропозицій, а ваш аналіз показує, що ефективність бази даних є вузьким місцем.
У цьому випадку вимкніть функцію Вмісту продукту та Пропозиції та поставте в окрему службу (не на вашу платформу з низьким кодом). Ви можете створити його самостійно або вибрати безголову комерційну платформу, як Commercetools. Для цієї послуги ви можете вибрати технологію, яка підходить для певного призначення, наприклад не реляційна база даних, а сховище документів для Вмісту продукту, де ви отримуєте всю інформацію про товар для ідентифікатора товару лише за допомогою одного виклику API.
Тепер повторно підключіть рівень API до нових служб вмісту продукту та пропозицій продуктів, і ось вам: тепер у вас є високо масштабована частина програми без впливу інтерфейсного або кінцевого користувача. Такий підхід називається “Задушник”.
Ви повинні помістити ці вдосконалення у свою дорожню карту продукту та постійно обговорювати їх із зацікавленими сторонами. З часом у вас з’явиться високомасштабний та доступний набір серверних сервісів, які можна будувати та застосовувати незалежно один від одного та з інтерфейсу.
4 – масштабування переднього кінця
Якщо ви просто зупинитесь тут, ви вже зробили кілька хороших кроків. Ваша залежність від платформи з низьким кодом обмежена. Ви використовуєте його переваги для швидкості та ввели альтернативи для збільшення швидкості та стабільності.
Все ще можуть бути причини, чому ви хочете представити новий інтерфейс:
Більший вплив на продуктивність
Використовуйте новітні технології інтерфейсу
Станьте менш залежними від дефіцитних навичок деяких платформ із низьким кодом
Ще більше обмежте залежності від постачальника
Те, що працювало на задній план, працює і на передній панелі. Завдяки шару API між ними ви можете ввести новий інтерфейс на тому ж інтерфейсі. Поточний інтерфейс на вашій платформі з низьким кодом може співіснувати з новою. Як тільки новий буде на рівні, ви зможете застосувати старий інтерфейс.
Крім того, ви можете створювати різні інтерфейси, якщо вам подобається один для кожного випадку використання, пристрою чи каналу.
У сценарії, коли як внутрішній, так і зовнішній інтерфейс були відсунуті від платформи з низьким кодом, ви також можете кудись перемістити рівень API, наприклад, до постачальника хмарних платформ. На цьому етапі ви успішно використали низький код для запуску програми, продукту чи бізнесу, і ви перейшли до чогось, що працює в масштабі поступово. Ви можете зберегти свою ліцензію на низький код та платформу для нових ініціатив.
Висновок: низький код є хорошим вибором при використанні за призначенням
Платформи з низьким кодом є гарним доповненням до доступних варіантів побудови цифрового бізнесу. Вам потрібно використовувати його за призначенням. І це має свої компроміси. Але це стосується всіх технологій. Щоб уникнути розчарування, використовуйте його для випадків, згаданих у статті (простий, маленький корпус, новий продукт, що перевіряється) і плануйте заздалегідь, якщо ваша ситуація зміниться (більш складний, масштабний, перевірений продукт). Якщо ви це зробите, ви отримаєте переваги та уникнете підводних каменів. Як показано нижче, ви спочатку будете швидкими, а масштаб буде швидким. Де закінчується початкова фаза, а де більший масштаб? Це залежить від конкретної платформи з низьким кодом, яку ви вибрали.
Не соромтеся залишати коментарі.
Спочатку ця публікація була опублікована за адресою https://www.linkedin.com/pulse/low-code-through-eyes-traditional-programmer-how-enjoy-de-ruiter/.
Arjen de Ruiter люб’язно дозволив нам перекласти і опублікувати цю статтю.
Temy.co - Software Development Partner 