Jsou no-code aplikace škálovatelné?

Srpen 22, 2022

Firmy často začínají s no-code nástroji, které jim zjednodušují vytvoření procesu/služby/produktu a hlavně zrychlují vývoj. Čas pro uvedení produktu/služby na trh je v rámci no-code nástrojů v řádu dní, maximálně týdnů. Oproti tomu programování celého řešení zabere měsíce, kvartály a někdy i roky.

Proč je dobré využít no-code platformy jsme psali v tomto článku: FINN - z nuly na 100 milionů v prvním roce startupu

Když výhoda se stane brzdou

Pokud ale narazíte na limit no-code nástrojů, může se to pro vás stát brzdou v tom lepším případě. V horším celé řešení musíte zahodit a naprogramovat ho odznova - řádek po řádku.

Proto je hned od začátku důležité znát limity nástrojů, odhadnout čas, kdy se k limitům dostanete, a mít řešení, které současný systém nahradí či doplní.

3 kritické best practices, které zvažovat

  1. dobře navržený model databáze
  2. optimalizovaná logika a dotazování do databází
  3. funkční uživatelské rozhraní

Tyto 3 body je potřeba zvážit ať už volíte no-code nástroje, nebo si věci vyvíjíte sami.

U no-code platforem musíte zvážit i znalosti a dovednosti svých lidí. Nemusí být programátoři, ale musí mít “programátorské” myšlení, aby dokázali vytvářet funkční systémy. Tím je myšlena úroveň zhruba znalosti pokročilých funkcí v Excelu.

Příklad za všechny prachy

O FINNu a jeho růstu z nuly na 100 milionů korun během prvního roku jsem psal už minule. Díky no-code nástrojům byli zaměstnanci schopní testovat nové nápady téměř okamžitě. Tento růst si ale nese i svou daň v oblasti IT. Jejich senior software inženýr Ishtiaque Zafar o tom píše zde: No-code isn't scalable. Our learnings at FINN going from 1000 towards 100,000 car subscriptions.

Pro jednodušší pochopení překládám to hlavní.

  • Limity databází (airtable) - dělat tisíc řádků v airtablu a dělat deset milionů řádků v airtablu je opravdu rozdíl
  • Problémy se synchronizací
  • Přemíra užívání nástrojů jako Make pro byznys-kritické procesy
  • Extrémní závislosti na systémech navzájem - pokud owner jednoho systému něco upraví, musí udělat změnu i owner jiného propojeného systému
  • Nedostatek ownershipu (vlastnictví) - kdo vlastní co
  • Nedostatek u přístupu a kontrol změn v procesech
  • Obtížné testování

Jak s tímto dále bojovali?

Odstranění chyb v databázi

Od začátku používali jako svou databázi airtable. Časem se dostali ale k tabulkám se 400 poli (sloupci) a to už začíná být hodně nepřehledné. Navíc airtable zavedl limit na 5 dotazů za sekundu, což byla limitace.

Tím se dostali k time-outům a potřebovali to upravit.

  1. identifikovali data, která moc nevyužívají a přesunuli je do separátní databáze
  2. zreplikovali data, která se využívají napříč firmou (data o autech a předplatných)
  3. zjistili čtecí procesy, které významně zatěžují dotazování a ty četli z databáze bodu 2
  4. zjistili upravovací procesy a ty optimalizovali (například aktualizovali jen konkrétní řádek u konkrétního auta, ale ne celou tabulku, pokud u ostatních nebyla žádná změna)

Díky tomu docílili stabilního systému s nulovým time-outem.

Získání víry ve svá data

Z důvodů různých dat na různých místech s různými ownery a kvalitou zavedli několik důležitých pravidel.

  1. Vlastnictví - týmy dostali na starosti různé data sety - akviziční tým měl na starosti dataset s leady, operations dataset s předplatnými atp.
  2. Kontrola přístupu - jen dedikované týmy měli přístup a možnost úpravy daných datasetů, případně vytvořili pravidla pro ostatní, kteří chtějí k datům přistupovat/upravovat.
  3. Definování, která data se vůbec můžou měnit a která budou “nastálo”. Například předání auta může být pouze poté, co je auto zaplaceno - předávací tým si zjistí, jestli je zaplaceno v datasetu financí a až pak ho předá. Toto pole přitom může měnit jen tým financí.

Začátek kodování

Výše uvedené problémy vedli k tomu, že dál už nepůjde škálovat. I s ohledem na expanzi do USA potřebovali spolehlivý systém. Rozhodli se vybudovat nový systém s již vyzkoušenými procesy a postupy. To vyvolalo potřebu udržet stávající procesy do té doby, než bude nový vlastní systém vytvořen.

První věcí bylo omezení rizika migrace na minimum. Začali s malými věcmi a postupně to škálovali. Začali s 10 novými auty a připravili systém, které to odbaví a zároveň bude schopný to navýšit na 100, poté na 1000 až na 100 tisíc aut. Tím si i vydefinovali správné praktiky, kterých se následně drželi.

Zavedení správných praktik

  • Hlavně jednoduše - řešili dnešní problémy s vizí do budoucna aniž by řešili problémy budoucna hned od začátku
  • Oslavuj chyby - chyby se stávají a je potřeba na to myslet, zjišťovat je a učit se z nich
  • Viditelně - systém musí umět říct, co chce nebo nechce, musí komunikovat a notifikovat
  • Komplexnost jiných řešit u nás - procesy partnerů a dodavatelů nejdou řešit u nich a musí se řešit interně - dát jim prostor jak jednoduše pracovat s FINN systémy
  • Zákazník na prvním místě - zákazník musí mít jistotu, že FINN pracuje skvěle a musí mít ve spolupráci důvěru
  • Dostupnost dat - lidé by měli mít přístup k datům a to by neměl být nikdy blocker
  • Čistě je lepší než chytře - snažili se napsat kod, který je lehce pochopitelný pro kohokoliv a kdokoliv ho může měnit. 

Snížení přerušení na minimum

Toto je klíčová věc. Jelikož FINN od začátku používal Integromat (nyní Make) a přitom přecházeli na systém, že ne každý má k datům/scénářům přístup, vytvořili vlastní custom-apps přímo v Make. Člověk tak může používat přímo endpointy, ke kterým má oprávnění a k datům, které může používat. Nebo si může volat procesy, které mu správná data dají.

Udělali si tak vlastně svou vlastní interní síť microapps, které mohli lidé ve FINN volat a získávat data o předplatných, autech a dalších věcech. Zároveň přidali Retool na správu podstatných věcí, kde běžní lidé (například ze supportu) mohli vidět to podstatné a nepotřebovali si o data “volat” přes Make.

Kam se dostali?

Díky výše uvedeným krokům se dostali úspěšně ke stabilnímu řešení.

Závěrem

No-code pomohl dostat se tam, kam potřebovali. Další fáze růstu ale znamená nevyhnutelnost kodování vlastních produktů/nástrojů s využitím současných zkušenosti z no-code nástrojů.

No-code systémy budou dále využívány pro své benefity (rychlost, úspora, spolupráce) s případnou úpravou nastavení jako u Make platformy, ale přidá se k tomu ještě samotný produkt, který bude naprogramován.

Odpovědí na úvodní otázku tak je, že do určité fáze je škálovatelnost možná. Pak už ale přichází na řadu i částečné kodování. Díky no-code aplikacím se ale dokáže oddělit to, co je podstatné a má být naprogramováno, od toho, co se dál může řešit no-code platformami.