Pokud jste ještě neslyšeli o pojmu “Serverless”, tak se posaďte a pozorně čtěte. Mohlo by to výrazně změnit způsob jakým navrhujete a provozujete svoje aplikace - stejně jako se to v roce 2017 stalo nám v Purple Technology, kde jsme tehdy tuto technologii adoptovali, a kde o tři roky později už je 90% našich systémů “Powered by Serverless ⚡️”.

Popíšu Serverless primárně v podání cloudového poskytovatele Amazon Web Services. My v Purple Technology jsme se pro něj rozhodli, protože je to největší hráč na trhu.

Co je to Serverless?

V našem týmu jsme přemýšleli, jak bychom definovali Serverless a vyšlo nám z toho toto:

Serverless je rozsáhlý ekosystém managed služeb a z nich vyplývajících návrhových vzorů, který po spojení těchto komponent umožňuje celému systému během stovek milisekund škálovat na nulu a zpět v závislosti na nárocích na provoz.

Nicméně taková definice toho nováčkovi moc neřekne, takže v dalších dílech tohoto seriálu se můžete těšit na plno praktických ukázek a demonstrací. Zjednodušeně můžeme říct, že Serverlessová aplikace je taková, která běží pouze tehdy, když ji uživatelé používají.

Co vše lze vytvořit v Serverlessu

• REST API (Amazon API Gateway)
• GraphQL API (AWS AppSync)
• Cron - pravidelně spouštěný kód (Amazon CloudWatch Events)
• Staticky hostovanou webovou stránku s CDN (Amazon S3 + Amazon CloudFront)
• NoSQL databázi (Amazon DynamoDB)
• Frontu (Amazon Simple Queue Service)a mnoho dalšího…

Serverlessová revoluce

Nebál bych se říct, že vznik Serverlessu je stejně výrazná revoluce jako byl v roce 2008 vznik Cloudu. I přes to, že základní element, který umožnil vznik Serverlessu, byl pokrok v kontainerizačních technologiích, nejedná se primárně o technologický pokrok, nýbrž o kompletní transformaci paradigmatu návrhu a provozu aplikací.

Vizualizace technologické evoluce:

Zrození Serverlessu

Celá tato (r)evoluce začala tím, že cloudový provider AWS (Amazon Web Services) oznámil na podzim roku 2014 novou službu nazvanou “AWS Lambda”.  Tato služba umožnovala vývojářům provozovat zdrojový kód - tzv. lambda funkce - bez nutnosti správy jakékoliv fyzické či virtuální infrastruktury. To by samo o sobě nebylo až tak užitečné, pokud by zároveň s tím neoznámili i její základní “event sources” - Amazon S3 bucket notifications, Amazon Kinesis stream records, Amazon DynamoDB update streams. Tehdy se začala psát nová kapitola cloudových služeb zvaná Serverless.

Serverless není jen Lambda

Na první pohled by se mohlo zdát, že Serverless a Lambda jsou dva zaměnitelné pojmy - nicméně není tomu tak. Lambda je pouze část velké Serverlessové skládačky. Aby Lambda funkce byla v praxi k něčemu, tak k sobě vždy potřebuje nějaký další “dílek” - např. API Gateway, která se postará o propojení REST API endpointů na Lambda funkce.

Event sources

V odstavci “Zrození Serverlessu” jsem zmínil pojem “event source”, což je jeden ze základních kamenů Serverless architektury. Lambda funkce je totiž vždy spuštěna v reakci na nějakou událost - event - např. nahrání obrázku do Amazon S3 úložiště - načež Lambda funkce na základě této události spustí svůj kód, jako třeba vytvoření zmenšeného náhledového obrázku (thumbnailu).

Spouštění lambda funkcí se dělí na dva základní typy:

• synchronní - služba spouštějící lambda funkci čeká na její výsledek, na základě kterého vyhodnotí, jak v daném procesu dále pokračovat – např. REST API požadavek: request -> response
• asynchronní - služba pouze vyvolá spuštění lambda funkce, ale nečeká na její doběhnutí – např. vytvoření náhledového obrázku pro nově nahraný obrázek do S3.

Managed služby

Jednou z výrazných myšlenek v Serverlessu je maximální využití tzv. managed služeb a minimalizace produkce vlastního kódu, díky čemuž se rapidně zmenšuje množství nově vyprodukovaného technologického dluhu, což umožňuje investovat peníze raději do rozvoje produktu.

Managed služby jsou takové služby, jejichž vývoj, provoz a zodpovědnost je outsourcován na třetí stranu. Např. služba Amazon Relational Database Service - služba poskytující relační databáze jako jsou MySQL, Postgresql, MariaDB, Oracle atp. plně spravované Amazonem. Není tudíž potřeba investovat rozsáhlé prostředky do aktualizací, zálohování, bezpečné konfigurace, disaster recovery, read-replik, scalingu atd. a místo toho se ony prostředky mohou soustředit na další rozvíjení produktu.

Díky managed službám mohou i relativně malé týmu budovat a provozovat rozsáhlé projekty, což je v době obrovského nedostatku IT pracovníků velká kompetitivní výhoda.

Provozní náklady a škálování

Cloud svým příchodem zpopularizoval tzv. Pay-as-you-go pricing - volně přeloženo - zaplať jen za to, co využiješ. To stejné, ale v mnohem větší míře, platí i pro Serverless služby.

V Serverless ekosystému se v případě AWS Lambda platí za každých 100ms, kdy váš kód běží. Pro představu, nejlevnější blok s pamětí 128 MB stojí $0.0000002083.

Příklad: řekněme, že máme API Gateway endpoint napojený na lambda funkci s pamětí 128 MB a této funkci trvá zpracování požadavku a vytvoření odpovědi 500ms.
Kolik požadavků můžeme odeslat na toto API, aby výsledná částka za provoz byla $1?
Výsledek 1/($0.0000002083*500ms) je zaokrouhleně 1 milion požadavků za $1.

U ostatních Serverless služeb je cenová politika většinou nastavena “pay-per-request”. V případě úložišť jako např. Amazon S3 je ještě účtována částka za využitý diskový prostor.

Zlý jazykové tvrdí, že Serverless je předražený a že brzy po růstu zátěže na aplikaci se její provoz začne značně prodražovat. Nicméně pokud to začnete analyzovat a počítat, tak zjistíte, že v případě použití alternativy jako je Kubernetes, nebudete platit jen za infrastrukturu na které poběží vaše clustery, ale ještě budete muset zaplatit lidi, kteří se o ně budou starat. Takže ve výsledku nakonec zjistíte, že takový přístup se vyplatí jen při opravdu obrovském provozu. Navíc v prospěch Serverlessu hraje i ten fakt, že v dnešní době je zkrátka mnohem jednodušší obstarat od investorů víc peněz než hledat na přesyceném trhu práce nové zaměstnance.

Srovnání

V klasickém cloudovém prostředí je nejmenší škálovací jednotka “jedna instance”, což minimálně na několik minut zvýší resp. sníží cenu infrastruktury nejméně o jednotky dolarů. – Na níže uvedeném grafu reprezentováno modrou čárou.

V Serverless ekosystému je nejmenší škálovací jednotka “spuštění Lambda funkce”, což minimálně na 100ms zvýší resp. sníží cenu infrastruktury nejméně o $0.0000002083. – Na níže uvedeném grafu kopíruje červenou čáru.

Taková flexibilita dává Serverlessu jeho primární vlastnost - okamžité škálování na nulu a zpět. To znamená, že v případě, že vaši aplikaci nebo část aplikace v daný okamžik nikdo nepoužívá, vaše náklady na její provoz jsou v ten moment nulové.

Přehled trhu

Z počátku bylo AWS jediným hráčem na poli Serverlessových technologií, nicméně brzy po tom se připojil jak Google se svými Google Cloud Functions, tak Microsoft se svými Microsoft Azure Functions.

AWS se obecně v cloudu profiluje jako market leader a v Serverless ekosystému to platí dvojnásob. Určitě je potřeba si před začátkem vývoje prozkoumat všechny poskytovatele v závislosti na vašich požadavcích - hlavně podporované jazyky a verze runtimes. Nicméně je vysoce pravděpodobné, že skončíte u AWS.

Vendor lock-in

Jednou z obav okolo cloudu obecně je tzv. “Vendor lock-in”. Je to obava z toho, že se firma stane technologicky závislou na jednom cloudovém poskytovateli a migrace k jinému poskytovateli, např. z cenových důvodů, bude hodně nákladná nebo až nemožná, protože by to vyžadovalo příliš nákladný refactoring jak infrastruktury, tak aplikace.

U základního zdroje jako jsou virtuální instance by se v případě migrace jednalo pouze o infrastrukturní úpravy, nicméně v případě Serverless aplikace by se velice pravděpodobně jednalo o přepis větší části aplikace, což v podstatě činí migraci nemožnou.

Výsledkem je, že v případě Serverless aplikací se více méně musíte smířit s tím, že budete mít velký vendor lock-in. Nicméně i přes to mi to připadá jako velmi výhodná cena za to, co za to dostanete.

Frameworky

I přesto, že v cloudových webových konzolích si můžete ručně nastavit, co se vám zlíbí, není to určitě dobrý přístup pro produkční aplikace. Z toho důvodu jsou tu frameworky, které se starají o celý životní cyklus aplikace od zabalení přes nasazení až po smazání. Tyto frameworky jsou většinou hlavně nástroje v příkazovém řádku (CLI).

Nejpopulárnější frameworky

Serverless Framework je nejpopulárnější komunitní framework, který vznikl chvíli po veřejném zpřístupnění AWS Lambda na začátku roku 2015. Tento framework podporuje např. AWS, Google Cloud či Microsoft Azure a oplývá rozsáhlým pluginovým ekosystémem, který umožňuje vývojářům si ho dokonale přizpůsobit svým potřebám. Z těchto důvodů jsme se ho rozhodli používat i my v Purple Technology.

AWS SAM (Serverless Application Model) je framework, který vznikl v dílně AWS na podzim roku 2016, může být vhodný pro začátečníky, nicméně bych nedoporučoval ho používat na větší produkční aplikace, protože míra jeho adopce je minimální a oproti Serverless Frameworku neobsahuje možnost rozšíření pomocí pluginů.
Technicky se jedná se více méně o mutaci CloudFormation šablon s vlastním CLI pro nasazování a debugování aplikace.

AWS Amplify je mnohem komplexnější framework než výše dva zmíněné, které pokrývají pouze backendovou část aplikace. Amplify obsahuje totiž i spektrum Javascriptových frontendových knihoven, které zajišťují věci jako komunikace s REST/GraphQL API, autentizace uživatelů atp. Takže vývojářům poskytuje kompletní end-to-end balíček.

Závěr

V Purple Technology jsme velcí nadšenci do Serverless technologií a dovolil bych si tvrdit, že i znační průkopníci.

Doufáme, že touto sérií v češtině učiníme Serverless přístupnějším a začne ho v našem milovaném srdci Evropy používat více a více firem.  

V případě jakýchkoliv otázek mě neváhejte kontaktovat na Twitteru @FilipPyrek.

With ❤️ made in Brno.