Istnieje stereotyp, że platformy low-code tworzą oprogramowanie, które jest powolne i ograniczonone funkcjonalnie. Jak w każdym stereotypie, jest w tym trochę prawdy, ale niewiele.
Aby dowiedzieć się, jaka jest rzeczywistość, musimy najpierw zacząć od tego, jak budowane są systemy o wysokiej wydajności przy użyciu języków programowania ogólnego przeznaczenia. Przejdźmy zatem do sedna tego tematu, a następnie skonfrontujmy go z tym, co do zaoferowania ma low-code. Czy programowanie dedykowane ma naprawdę tak wielką zaletę w porównaniu z rozwiązaniami low–code? A może to wada?
Co sprawia, że oprogramowanie jest „wolne”?
Co tak naprawdę oznacza „wolny” w kontekście typowej aplikacji korporacyjnej? Przez „typowej” rozumiem klasykę 3 warstw: Web UI + usługi backendowe + bazy danych. „Wolne” działanie może pochodzić z:
- Zapytania do bazy danych są dalekie od optymalnych – brakujące indeksy, nieaktualne statystyki, złe strategie łączenia itp.
- Niepotrzebne zapytania – brak pamięci cache lub „gadatliwe” algorytmy zakładające, że pobranie większej ilości danych z bazy danych lub usług zewnętrznych jest bezpłatne i natychmiastowe.
- Niewłaściwy dobór narzędzi do zadania — takie jak używanie warstw ORM i języków ogólnego przeznaczenia do operacji masowych na bazach danych o rozmiarach TB (ładowanie, raportowanie, integracja itp.). Chociaż jest to wykonalne i łatwe, zdecydowanie nie tędy droga.
- Lekkomyślne algorytmy – widziałem „rozwiązania” z dużą ilością pętli wewnątrz pętli i niepotrzebną rekurencją dla trywialnych problemów, gdzie – zamiast tego – można użyć prostego i wydajnego algorytmu. Innymi słowy – w przypadku małych danych testowych te rozwiązania działały, ale przy większych danych testowych czas przetwarzania szybko rósł do przerażających wartości.
- I tak dalej…
Skąd bierze się wysoka wydajność?
Z pewnością najlepszym sposobem na naprawienie problemów z wydajnością jest ich unikanie od samego początku. Aby to zrobić, programiści muszą znać swoje narzędzia i planować wydajność oraz skalowalność. Potrzebna jest dogłębna i szeroka wiedza na temat różnych technologii, aby podjąć świadomą decyzję, której z nich użyć i w jaki sposób. Co więcej, kluczem do wydajności jest często wiedza, jak naprawdę działa współczesny sprzęt komputerowy. Często bazuje on na możliwości wykorzystania wielu rdzeni procesora, unikaniu blokowania i niepotrzebnych alokacji pamięci, dzięki czemu przełączenia kontekstu są utrzymywane na minimalnym poziomie, a odwołania do pamięci podręcznej procesora
na maksymalnym poziomie.
Drugim elementem sukcesu są szeroko zakrojone testy wydajności. Widziałem tutaj trzy główne przeszkody:
- brak dobrych makiet systemów zewnętrznych,
- brak dużych i złożonych danych testowych,
- brak środowiska serwerowego choćby trochę naśladującego produkcję.
Aby wypracować makiety, programiści muszą znać różne istniejące narzędzia testowe, mieć do nich dostęp lub stworzyć takie narzędzia samodzielnie. Zbieranie lub generowanie danych testowych oraz projektowanie testów również zajmują dużo czasu. Ponadto stworzenie środowiska testowego wymaga pieniędzy na zakup sprzętu lub wydzierżawienie go w chmurze – w końcu optymalizacja pod kątem małej, słabej maszyny wirtualnej może wyrządzić więcej szkody niż pożytku. Powody te często uniemożliwiają przeprowadzanie testów wydajności przed przejściem do produkcji. W rezultacie prędzej czy później na produkcji pojawiają się problemy z wydajnością, a programiści są zmuszeni do przeprojektowania architektury całego systemu ASAP.
To oczywiście może się zdarzyć nawet przy kompleksowym planowaniu i testowaniu. Bez względu na to, jakie mogą być Twoje problemy z wydajnością, głównym krokiem w jej poprawie jest identyfikacja pierwotnej przyczyny problemu. Jeśli aplikacja nie jest „wykuta w kamieniu”, ale zmienia się wraz z biznesem, jeszcze ważniejsza staje się możliwość szybkiego reagowania. Jednak w rzeczywistości szybkie reagowanie może nie być łatwe z wielu powodów; począwszy od programistów, którzy nie mają doświadczenia w profilowaniu w różnych technologiach a skończywszy na potrzebie skonfigurowania dedykowanego oprogramowania monitorującego lub zaplanowania spotkań ratunkowych z administratorami baz danych w celu zebrania statystyk zapytań i planów dostępu.
Co ma do zaoferowania low-code?
Jak widać, w świecie programowania ogólnego przeznaczenia wydajność jest trudnym wyzwaniem. Wymaga czasu i pieniędzy, a także programistów z dużą wiedzą, o których w dzisiejszych czasach coraz trudniej.
Ale w jaki sposób platforma low-code może lepiej zaadresować problemy z wydajnością? Oczywiście odpowiednie oprzyrządowanie może być bardzo pomocne przy rozwiązywaniu dużych i złożonych problemów.
Co by było, gdyby nasza platforma projektowa miała wbudowane pewne możliwości skalowania? W takim przypadku moglibyśmy wziąć je pod uwagę przy planowaniu wszystkiego innego. Aby jeszcze bardziej ułatwić projektowanie systemu, wyobraźmy sobie, że mamy gotowe interfejsy do popularnych systemów zewnętrznych, przygotowane do użytku; bez konieczności ich ręcznego tworzenia, optymalizacji i naprawiania!
A gdyby platforma dostarczyła nam narzędzi do łatwego generowania danych testowych? Nie zniechęci nas potrzeba 100 GB powiązanych danych, które mają sens, czy też nietrywialnych makiet dla interfejsów soap/rest/queue, z wymyślnymi formaterami. Możliwość ich szybkiego tworzenia byłaby bardzo użyteczna nie tylko do testowania wydajności, ale ogólnie do testowania.
Co by było, gdyby nasza platforma projektowa mogła samodzielnie zidentyfikować wąskie gardła?
Na koniec wyobraź sobie, że moglibyśmy to wszystko zrobić na jednej platformie low-code, bez konieczności uczenia się dedykowanych narzędzi integracyjnych firm trzecich! Moglibyśmy wykorzystać wszystko, czego już się nauczyliśmy, budując nasz webowy interfejs użytkownika i usługi! Moglibyśmy również użyć tej samej logiki we wszystkich scenariuszach: wsad, usługa, interfejs użytkownika, silnik reguł, a nawet generowanie dokumentów, praktycznie wszędzie!
Brzmi nieprawdopodobnie? Nie dla VSoft archITekt.
Przełamywanie stereotypów
Tak, platforma archITekt dostarcza odpowiedzi na wszystkie te pytania: „co jeśli”. Działająca zarówno w świecie scenariuszy wsadowych, jak i opartych na zdarzeniach, jej podstawowy silnik umożliwia również obsługę web UI, backend’u, przepływu procesów, usług i nie tylko.
Platforma archITekt działa dobrze w klastrach, zarówno lokalnie, jak i w chmurze, oferując łatwą skalowalność, przy odpowiednim projekcie danych. Zapewnia również dodatkowe narzędzia i usługi do generowania danych, profilowania, testowania, makietowania itp. Wszystkie te dobrodziejstwa oparte są na jednej, elastycznej strukturze i modelu mapowania, co pozwala na wykonywanie nawet najbardziej skomplikowanych zmian na drzewach danych w locie. Wszystkie kluczowe obszary są dobrze zoptymalizowane, mierzone i stale analizowane w trakcie wykonywania.
Ponadto nasza platforma „rozumie” strukturę środowiska, w którym pracujesz i oferuje pomoc na każdym kroku. Prawie nie ma potrzeby wpisywania czegokolwiek, nawet największe schematy danych są przedstawiane wizualnie jako podpowiedzi lub „duchy”, jak je nazywamy. Najczęstszych błędów można uniknąć dzięki analizie tła.
Prawdziwe studia przypadków
Rozumiem, że brzmi to niewiarygodnie, więc pozwól, że przedstawię ci kilka twardych dowodów. Dla porównania chciałbym skupić się na dwóch przykładach z życia wziętych.
Przypadek 1 – Hurtownia danych finansowych DIY
Wyobraź sobie dużą instytucję finansową z dziesiątkami formatów plików transportowanych do i z tysięcy współpracujących jednostek. Niektóre formaty (i opisane przez nie przypadki biznesowe) mają dziesiątki lat. Złożone Web CRUDS. Coraz większa integracja ze światem zewnętrznym przy użyciu prawie wszystkich możliwych rodzajów oprogramowania pośredniczącego. Cztery różne technologie baz danych. Sześć milionów podmiotów gospodarczych aktualizowanych codziennie, odczyt prawie pół miliarda atomowych rekordów.
Podejście naszej konkurencji było bardzo tradycyjne – rozwiązanie ETL do przekazywania danych do wewnątrz i na zewnątrz, aplikacja web’owa Node.js , usługi Java do integracji.
Podstawowa logika pisana 3 krotnie. Opór wobec zgłaszanych prośby o zmianę, zwłaszcza związanych z integracją z innymi systemami. Wysokie opłaty licencyjne i koszty utrzymania dla klienta.
Nasze podejście było inne – skorzystajmy z naszej platformy low-code, która ma swoje korzenie w świecie ETL i potrafi „rozmawiać” ze strukturami hurtownianymi.
Wyniki? Logika stworzona raz, a następnie ponownie wykorzystana, większość CRUDów tworzonych za pomocą zaledwie kilku metod drag & drop ze znanych już struktur baz danych.
Najciaśniejsze pętle i obszary o krytycznym znaczeniu dla wydajności są wstępnie wbudowane, obszary o dużej dynamice działalności biznesowej dostępne dla klienta do samodzielnego rozszerzenia. Wąskie gardła wydajnościowe zidentyfikowane na długo przed eskalacją, powolne harmonogramy wykonania podane na tacy do poprawy. Dwukrotnie lepszy od konkurencji. Dzięki kilku sprytnym technikom modelowania hurtowni danych nie było potrzeby utrzymywania okien konserwacyjnych dla procesów masowych. TCO niższy o rząd wielkości. Platforma low-code wygrywa pod każdym względem. Wyraz twarzy klienta, a zwłaszcza handlowców naszej konkurencji – bezcenne 🙂
Przypadek 2 – logistyka w pandemii
A teraz pozwól, że zabiorę Cię do dużej i szybko rozwijającej się firmy logistycznej. Kilkanaście milionów wydarzeń, które można łączyć, filtrować i agregować na żywo, co godzinę, dodatkowo z koniecznością przetwarzania zarówno danych historycznych oraz hipotetycznych. Każde istotne zdarzenie należy przetworzyć dokładnie raz, ponieważ bezpośrednio wpływa na realne obciążenie opłatami.
Nasz klient miał trzy główne problemy ze swoim starym, szytym na miarę rozwiązaniem:
- Dostosowywanie i wdrażanie coraz to nowych definicji produktów
- Wydajność
- Potrzeba coraz większej liczby integracji z obecnymi i przyszłymi systemami
Nasze podejście polegało na wykorzystaniu… naszej platformy low-code! Wiele zalet tego podejścia opisałem już w poprzednim przypadku, a teraz dodam jeszcze kilka. Możliwość szybkiego budowania wariantów rozwiązania dla danych historycznych i hipotetycznych pozwoliła nam odkryć w danych interesujące statystyki, o których klient nie wiedział. Co zarówno utorowało ścieżkę dla nowego podejścia do partycjonowania danych, jak i pozwoliło na znaczne oszczędności w presji IO na bazę danych (w rzeczywistości bazy danych, ponieważ zastosowano ich trzy różne rodzaje). Wykorzystaliśmy nasz silnik decyzyjny i zintegrowaliśmy go bezpośrednio z systemem, bez generowania dodatkowego ruchu sieciowego.
Ostatecznie udało nam się przetworzyć ruch z kilkunastu systemów produkcyjnych na jednym laptopie. Nasz klient nie mógł w to uwierzyć i dlatego wielokrotnie to analizował. Rozwiązanie dawało poprawne wyniki, było łatwo rozszerzalne i konfigurowalne za pomocą dedykowanych edytorów internetowych. Po raz kolejny tradycyjna wiedza (czy intuicja?) sromotnie zawiodła w konfrontacji z nowoczesnymi rozwiązaniami i sprzętem.
Podsumowanie
Sprytne platformy low-code mogą być wykorzystywane nie tylko do umożliwienia nie-programistom budowania prostych systemów. Niektóre mogą być również wykorzystywane do rozwiązywania złożonych problemów, obsługi dużych ilości danych i heterogenicznych środowisk, aby zapewnić klientom świetną wydajność oraz możliwość wykonywania dostosowań.
Paweł Marchewka
Low-code platform architect at VSoft
Zapraszam do połączenia na LinkedIn
