V lednu 2017 mi do emailové schránky přistál nenápadně se tvářící email od našeho klienta, kterému jsme spravovali jeho starý informační systém:
„Ahoj Honzo, nastal čas, abychom se začali bavit o našem novém informačním systému“.
K e-mailu byl přiložen vyfocený náčrtek, kde bylo v pár bodech napsáno, co má systém umět. Cíl byl poměrně přímočarý – přejít ze starého ERP/CRM, napsaného na míru v PHP a připomínajícího spíše velký školní projekt, na něco co by odpovídalo firmě, která poskytuje služby tisícům klientů a má podstatnou část agendy automatizovanou.
Přechod do Google Cloud
Je potřeba říct, že zákazník na přechodu do cloudu netrval. Spíš se nechal přesvědčit námi, protože nám už důvěřoval a zpětně hodnoceno to bylo určitě velmi odvážné. V roce 2017 sice každý o cloudu mluvil, ale jeho reálné využití v ČR bylo minimální, ale v praxi jeho využití bylo v ČR minimální, speciálně u české, netechnologické firmy.
Protože my jsme již praktické zkušenosti s podnikovými aplikacemi v cloudu měli a některé komponenty jsme si vyvinuli tzv. In-house, k návrhu jsme přistupovali takto:
- Informační systém bude serverless, aby odpadla nutnost starat se o fyzický nebo virtuální server, aktualizovat operační systém, řešit nefunkční pevné disky atp. Nutno říct, že náš zákazník neměl vlastního IT specialistu, takže tím spíš dávalo smysl vytvořit aplikaci v kontejneru na Google App Engine, což je vlastně prostředí, na kterém můžete celou aplikaci zprovoznit. I v rámci produktivního běhu jsme se navíc zpočátku vešli do tzv. Free tier mode, takže věřte nebo ne, samotný běh systému stál první rok 0 Kč.
- Databázi zajistíme formou SaaS. Důvod byl podobný – proč se někde starat o server, když potřebujeme jen databázi. Navíc pro naše účely bohatě postačovala MySQL databáze. V budoucnu jsme přidali do infrastruktury i PostgreSQL. Obojí Google Cloud podporuje a zprovoznění nebo nastavení pravidelných záloh, je skutečně jen na pár kliknutí.
- IS bude používat moderní API pro komunikaci s okolím. Komunikaci mezi backendem a frontendem jsme chtěli řešit moderně a zároveň jsme se potřebovali integrovat na 6 dalších aplikací (např. na Raynet CRM, datové schránky a SMS bránu). Proto jsme postavili moderní REST API za pomocí Google Cloud Endpoints (dnes už Cloud Endpoints ale moderní není :)).
- Autentifikaci budeme řešit externí komponentou, umožňující Single sign-on. Použili jsme Google Firebase a v našem případě to řešení bylo (a dodnes je) opět zcela zdarma, přestože jde o SaaS službu.
Nemá smysl tajit, že jsme byli a jsme nadšenci do Google Cloud Platform, a tak jsme se snažili využívat i další možnosti, které nám cloudové platforma (většinou zdarma nebo za pár korun měsíčně) nabízela. Jaké zvolit úložiště dokumentů? V Google Cloud Storage. Kam se zdrojovými kódy? Google Cloud nabízel GIT repozitář jako službu. Aplikační logování? Jasně, že pomocí Cloud Logging.
Délka a rozsah vývoje informašního systému
Když nepočítáme analyticko-koncepční část, kdy se definovaly požadavky a dělal poměrně detailní design aplikace, tak samotná implementace (začínali jsme úplně od začátku a na místo PHP jsme použili Javu 8, Spring Framework 4.3, Node.js a Angular 2), včetně migrace starých dat a náběhu produkce, byla hotová asi do 5 měsíců. Vyvíjeli jsme agilně? Ne. Zákazník byl v analytické fází velmi pečlivý, měli jsme proti sobě prakticky jen 2 klíčové uživatele, takže jsme postupovali pěkně po staru “vodopádem” s fixním rozpočtem. Ukázalo se to jako bezproblémová volba.
Přestože jsme vytvořili systém prakticky na zelené louce, pracností jsme dostali někam k rozsahu zhruba 100 člověkodnů (cca 800 hodin čisté práce). Kamarád ze známého českého software-housu mi rozsah nechtěl věřit a tvrdil s vážnou tváří, že u nich by to byl trojnásobek. My ale nejsme korporát a některé části jsme už měli hotové v šuplíku.
“ Vyvíjeli jsme agilně? Ne. Zákazník byl v analytické fází velmi pečlivý, měli jsme proti sobě prakticky jen jen 2 klíčové uživatele, takže jsme postupovali pěkně po staru “vodopádem” s fixním rozpočtem. Ukázalo se to jako bezproblémová volba”
Zhodnocení provozu v Google Cloud po 7 letech provozu
Během 7 let se rozsah řešení zvětšil minimálně o 1/3, přibyly integrace na další systémy a zároveň se zněkolikanásobil objem dat v systému (počet spravovaných klientů se nyní počítá ve vyšších jednotkách tisíců). Z toho důvodu jsme museli trochu navýšit prostředky pro backend a pro databázi. Vzhledem k tomu, že obojí je ve formě SaaS služby, znamenalo to jen pár kliknutí myší a zvýšený monitoring výkonnosti po dobu několika dní.
Kompletní měsíční náklady na běh produktivní aplikace (zcela bez serverové infrastruktury) se nyní pohybují 4.000 Kč (před přechodem z Java 8 na Java 17 byly náklady zhruba poloviční), kde asi třetinu představují náklady na MySQL databázi a zbytek je běh aplikace v Google App Engine.
Pokud jde o výpadky, za celou dobu jsme se potýkali pouze s jedním významnější omezením funkčnosti, způsobeným pravděpodobně problémem na straně Google Cloud infrastruktury. Vyřešilo se přesunutím části aplikace do jiné geografické oblasti, což byla operace na pár několik hodin. K žádné výrazné změně rozhraní, zrušení podpory nějaké komponenty nebo jiného podobnému problému za celých 5 let také nedošlo, což nás příjemně překvapilo. Zhruba po 5 letech byl pak čas na větší modernizaci systému – zejména nahrazení Javy, opuštění Cloud Endpoints (Google zastavil rozvoj a s komponentou začaly být trochu problémy), přechod na 2. generaci App Engine a povýšení verzí používaných knihoven. V průběhu času bylo také nutné přenést zdrojové kódy do GitLabu, protože Google GIT repozitář zrušil.
Celkově jsou hladký běh informačního systému v cloudu i velmi rozumné provozní náklady na běh potvrzením toho, že jsme našemu klientovi před lety poradili správně. On díky tomu mohl dál investovat do rozvoje aplikace místo do provozu.