Naše cesta do cloudu

Chytrý produktový katalog WisePorter (PIM) není úplně jednoduchý typ software (více o jeho uživatelském použití si můžete přečíst na našem produktovém blogu) a také ho není úplně jednoduché provozovat, protože obsahuje řadu technologických komponent:

• Designer-frontend napsaný v Reactu
• Designer-backend a Runtime napsaný v Javě (Spring Boot, Webflux)
• Relační databáze, ideálně PostgreSQL
• NoSql úložiště Elastic
• Cache, ideálně REDIS
• rule engine pro definici, správu a výpočet kalkulací, např. OpenL Tablets nebo Apache Drools
• IAM — KeyCloak
• RabbitMQ / ActiveMQ / Kafka pro asynchronní fronty pro komunikaci mezi komponentami WisePorteru Designerem a Runtime nebo pro integraci s okolními systémy — pro import dat do katalogu nebo pro export informací o změnách v produktech v katalogu

WisePorter využívají velké i malé společnosti a každá má různé požadavky na provozování svých aplikací. Někdo preferuje provoz ve svém prostředí, jiní naopak upřednostňují poskytnutí produktového katalogu jako služby (SaaS), kdy se o samotnou aplikaci a její běh nemusejí vůbec starat. A pro tyto zákazníky jsme vytvořili WisePorter SaaS.

Produktový katalog WisePorter

Od Heroku k MS Azure

Naše první cloudové prostředí bylo Heroku, několik let jsme ho úspěšně používali (pozn. napsali jsme článek Naše zkušenosti s Heroku), ale postupem času jsme začali zjišťovat, že to naše cílové prostředí nebude a to z několika důvodů:

• Heroku je platforma, která je pro vývojáře jednoduchá, dobře se používá, do jísté míry odstiňuje potřebu devops. Nicméně tato výhoda je zároveň i nevýhodou, protože toto pro jednoduché případy velice dobře funguje, ale když je pak potřeba nastavit plnou automatizaci, oddělit vývoj od infra a provozu, tak už to je nevýhoda.
• Heroku má povedenou příkazovou řádku (CLI), je možné také použít Terraform, ale možnosti automatizace jsou omezené ve srovnání s hlavními cloud providery. Naším cílem bylo vytočit novou SaaS instanci na jeden klik.
• Heroku nabízí omezený stack technologií, pokud vám nějaké služby nebo aplikace chybějí, tak je možné využít tzn. addony a přidat si je. Nicméně i tak nemůžete vše, máte omezenou flexibilitu využití technologií, které potřebujete. Heroku není pro geeky, to je pro vývojáře, kteří chtějí primárně psát aplikace a nestarat se o konfiguraci a provoz technologií, které pro běh své aplikace potřebují.
• Heroku obsahuje řadu omezení (např. délka HTTP requestu nesmí překročit 30s nebo jiné HTTP omezení, více ve výše uvedeném článku) a tyto omezení se často prostě změnit nedají a je nutné je řešit víceméně změnou patternu řešení.
• Heroku nenabízí PAYG (pay-as-you-go) model, tedy možnost placení za skutečně spotřebovaný výkon. Na Heroku si místo toho rezervujete výpočetní výkon nebo data (obecně zdroje) a ten máte po celou dobu k dispozici za fixní cenu. Škálovat sice lze, ale pořád s vědomím toho, že mám rezervovaný výkon, do kterého se musím vejít. Výběr virtuálních strojů je omezený, často nelze odděleně řešit CPU a pamět, takže je nutné si rezervovat a platit za oboje, i když tak velké CPU nebo paměť ve skutečnosti nepotřebuji.
• Heroku nenabízí managed Kubernetes, což je pro nás zásadní nevýhoda. K8s považujeme za základní stavební kámen pro běh našich aplikačních komponent a díky tomu, že je to defacto standard, tak není tak silný vendor-lock na konkrétního cloud providera.
• Heroku negarantuje žádná SLAs, funguje v řežimu best-effort
• Monitoring a logování není součástí řešení, je nutné řešit službami třetích stran.

Na začátku letošního roku jsme se pustili do výběru naší nové cloudové platformy a dle očekávání jsme nakonec vybírali ze tří možností — Amazon Web Services (AWS), MS Azure a Google Cloud Platform (GCP).

Od začátku jsme měli jasno v architektuře celého řešení včetně preference technologií (viz Technologický stack). Na každé platformě jsme si udělali PoC s cílem rozchodit WisePorter se všemi komponentami. K implementaci PoC jsme si přizvali zkušené odborníky za dané platformy, oslovili jsme lokální partnery Azure a GCP a nebo specialistu na volné noze na AWS. Cílem bylo získat více podnětů pro finální rozhodování než jen čtením článků.

Bohužel nám z toho žádný jasný vítěz nevypadl. Všechny tři platformy mají co nabídnout a ano, AWS nabízí nejvíce služeb, je zřejmě i technologickým lídrem, ale my jsme chtěli jen základní věci — managed Kubernetes, data storage, fronty, monitoring atd. Tedy nic “advanced”, co by někdo z AWS, Azure a GCP nenabízel a výrazně se lišilo. Pokud bychom se v této fázi měli rozhodnout, tak bychom zřejmě vybrali AWS a to z toho důvodu, že jsme ho nejvice znali a měli s ním již řadu zkušeností z předchozích projektů.

Proč jsme se tedy nakonec rozhodli pro MS Azure? Je to jednoduché, protože peníze. Nejsou tím ale myšleny peníze za provoz našeho produktového katalogu na dané platformě, tam jsme žádné výrazné rozdíly nenašli. Jsou tím myšleny peníze na začátek, k rozjezdu vlastního řešení a k postupnému ladění a zkoušení, které stojí nemalé peníze. AWS nenabídl nic, GCP řádově stovky dolarů a jediný Microsoft až $120.000 v rámci programu Microsoft for Startups. Nebylo to zadarmo, museli jsme se přihlásit do uvedeného programu a uspět, tedy přesvědčit “porotu”, že děláme něco smysluplného, ale zejména, že máme růstový potenciál.

Aplikační úpravy do cloudu

Produktový katalog je Java resp. Spring Boot aplikace, která běží na libovolném aplikačním serveru, např. Apache Tomcatu nebo ji lze pouštět v embedded režimu. Architektura aplikace není zcela monolitická, nicméně nelze ani říci, že je mikroservisní. Prostě taková rozumná komponentová dekompozice :).

První velkou výzvou byla úprava WisePorter aplikace pro běh v cloudu, abychom byli schopni využít všechny možnosti cloudu jako např. škálovatelnost nebo abychom uměli provozovat desítky WisePorter SaaS instancí vedle sebe a zvládali monitoring a support. Náš seznam nefunkčních požadavků čítal přes padesát položek, více jak polovina z nich byla “must-have”, tedy bez nich jsme nemohli nasadit WisePorter do cloudu. Pro představu se jednalo o tyto skupiny požadavků:

• bootstrap / provisioning / graceful shutdown všech komponent
• sjednocenní logování
• health probes
• security — uživatelské i technické zabezpečení
• provoz v clusteru
• high-availability
• konfigurace včetně secrets
• deployment
• docker image
• …

I když nám samotná realizace zabrala několik měsíců v několika lidech, tak nejtěžším bylo vůbec takové požadavky si uvědomit a nadefinovat je a to by nebylo možné bez našich předchozích zkušeností z mikroservisní architektury. Teď předběhnu závěr, ale toto byla ta nejdůležitější část našeho úspěšného přechodu k SaaSu a zkušenosti z jiných firem mě to potvrzují.

Nové prostředí na kliknutí

Druhou velkou výzvou bylo vytvoření samotného cloudového prostředí, kde nám poběží Kubernetes a všechny další potřebné technologie. V první fázi jsme prostředí vytvořili manuálně a následně jsme řešili jeho plnou automatizaci pomocí Terraformu. Dnes umíme na jedno kliknutí vytvořit zcela nové unifikované WisePorter prostředí podle úvodní konfigurace, trvá to cca 2–3 minuty, vše plně automatizovaně.

Většinu technologií uvedených v úvodu tohoto článku řešíme formou služby přímo v MS Azure:

• Kubernetes (AKS) jako aplikační server pro všechny Java komponenty, React frontend, KeyCloak a Elastic
• Service Bus pro vstupní / výstupní fronty
• Azure Database for PostgreSQL

Azure sice nabízí Elastic jako službu, ale primárně pro účely fulltextu a Kibany, my potřebujeme Elastic zejména jako data store. Za managed službu Elastic Cloud mimo Azure bychom museli od začátku platit, protože na to se kredity od Microsoftu nevztahují. Dalším problémem by byla integrace do naší automatizace a také jsme se obávali latence (proto ji máme teď v jednom AKS na jedné virtual machine).

Podobně REDIS, ten si také řešíme sami — na AKS nám běží REDIS Sentinel. Hlavně z důvodu ceny a latence. Obě technologie navíc známe velice dobře, takže problém rozchození a spravování byl minimální.

Co jsme získali?

WisePorter SaaS jsme úspěšně spustili k prvnímu září a od října máme na této platformě a v tomto režimu prvního produkčního zákazníka. Postupně sem převádíme i dosavadní instance z Heroku. Naši misi trvající od začátku roku se nám podařilo dotáhnout do úspěšného konce. Nicméně práce rozhodně nekončí — platforma nám sice plně běží, ale je určitě co ladit — optimalizovat nastavení a sizing všech částí platformy s ohledem na co nejmenší provozní náklady, nastavit monitoring a aktivní alerting, optimálně vše zálohovat a postupně se zdokonalovat z nepříjemných výpadků (které určitě dříve nebo pozdeji budou).

Co nám WisePorter SaaS přináší:

• nesrovnatelně více možností a flexibility než nám dokázalo nabídnout Heroku
• vše standardizované (každé prostředí je stejné), vše plně automatizované
• máme garantovaná SLA, která následně můžeme nabídnout i našim zákazníkům
• dokážeme nabídnout každému zákazníkovi takovou výkonnost, kterou skutečně potřebuje. Nemáme defacto žádná omezení, během zátěžových testů jsme WisePorter pustili ve čtyřiceti instancích …
• dokážeme našim zákazníkům nabídnout PAYG model
• Azure Monitor je silným nástrojem pro monitoring standardních a vlastních metrik, prohledávání logů a alerting, pokud něco nefunguje dle představ

Chytrý produktový katalog WisePorter

Kde jsou úskalí?

Z výše uvedeného článku si můžete odnést představu, že vše šlo strašně jednoduše a přímočaře. Bohužel toto je mylná představa, těch výzev resp. úskalí je velice mnoho.

Je nutné se naučit vybalancovat neomezené technické možnosti nabízené cloudovou platformou oproti rozumným nákladům. Je potřeba změnit mindset vývojářů a devops lidí a neustále pracovat na této nákladové optimalizaci, protože není umění provozovat SaaS aplikaci s neomezenými náklady, ale provozovat ji co nejvíce cenově efektivně bez dopadu na uživatelskou kvalitu dané služby. Několik příkladů:

• nejdražší cenové položky jsou data (logy, přenosy do/z cloudu), a proto je nutné najít tu správnou rovnováhu mezi množstvím logovaných informací a jejich retencí tak, aby support produktu a případné opravy chyb byly co nejrychlejší a cenou za uložení těchto logů.
• vhodný sizing (zejména CPU, RAM), ale i správná volba disků, typu virtual machines atd. jsou vždy volbou mezi cenou, výkonem a do jisté míry i jistotou a stabilitou celého řešení. Toto bez průběžného měření a ladění není možné optimálně nastavit.
• velikost zálohovaných dat je úměrné množství dat v primární databázi a frekvenci prováděných změn. Je lepší využívat backup služeb a data odlévat bokem a platit za několikanásobně větší datový prostor než má původní databáze a nebo raději zvětšit primární datové úložiště, spolehnout se na časové řezy (funkce Azure Database) a třeba i změnit způsob ukládání dat, aby rozsah změn byl minimální a tím se při změnách generovalo méně změnových dat?

Výše uvedenými příklady chci prezentovat, že těch možností k optimalizaci je nesmírně hodně, některé se týkají pouze nastavení samotné cloudové platformy, ale vetšina má souvislost se samotnou aplikací, jak se používá, jak se integruje s jinými systémy mimo cloud apod. A tento způsob myšlení se získá až praxí a zkušenostmi. Když každý měsíc ušetříme optimalizací 10 dolarů na prostředí, tak při 20 prostředích ušetříme hezkých $200 měsíčně …

S ohledem na výše zmíněné si snad ani nedovedu představit, že bychom od první chvíle za vše měli plně platit, protože to by nás stálo tisíce dolarů měsíčně. Máme několik prostředí pro různé potřeby (vývojová prostředí pro produktový tým a pro jednotlivé projekty resp. zákazníky, prostředí pro ladění performance, pro presale dema našich potenciálních zákazníků atd.), jsme na začátku jakékoliv optimalizace, sbíráme první reálná data z provozu, sledujeme každým dnem naše metriky a snažíme se z toho všeho učit a nastavovat priority další optimalizace. Zde jsem opravdu vdečný za podporu od Microsoftu a myslím, že to mají velice dobře vymyšlené, protože se jim to vše v budoucnu několikanásobně vrátí.

Cloud není rozhodně levná záležitost, což je i častý mýtus, že je. Cloud (stejně jako mikroservisy) nejsou pro každého a je důležité si předem definovat důvody Proč? Učíme se jak cenově WisePorter SaaS nabízet našim zákazníkům, protože jeden zákazník má lepší představu o fungování cloudu a nemá problém přistoupit na PAYG model placení za infrastrukturu, jiný zákazník chce mít zase spíše jednu garantovanou a každý měsíc stejnou cenu. Musíme umět uspokojit oba typy zákazníků.

Líbí se mě jaké možnosti a funkce Azure Monitor přináší — cokoliv potřebuji, tak si mohu vizualizovat, vytvořím si vlastní metriky, přidám grafy a v čase sleduji. Podobně mohu aktivně sledovat určité ukazatele, aby mě Azure aktivně dával vědět v případě problémů, např. průměrná doba odezvy se zvýší nad 200ms nebo počet zpráv ve vstupní frontě je vyšší než 1000 záznamů. Pro vývojáře to nicméně znamená změnu myšlení — přímý přístup k samotným aplikacím, jednotlivým technologiím a logům již není často možný (a ani žádoucí), a vývojáři se musejí spoléhat na Azure Monitor, kde je řada informací zprostředkovaných, není to prostě stejné jako se připojit příkazovým řádkem k Redisu a hned pár příkazy zjistit co se tam přesně děje.

Jsem přesvědčený o tom, že jsme udělali správné rozhodnutí jít do cloudu a jsem moc rád za náš tým, který si s touto nelehkou technickou výzvou tak výborně poradil. Od začátku jsme měli předem daný termín spuštění, protože jsme již dále novým zákazníkům nechtěli nabízet řešení na Heroku. Času nebylo moc, jeli jsme ve dvou souběžných streamech — jeden aplikační přizpůsoboval WisePorter do cloudu, druhý cloudový připravoval a automatizoval nové prostředí. Získali jsme tím velice mnoho nových zkušeností a znalostí, máme na čem stavět v dalším ladění. Čeká nás ještě dlouhá cesta …