Vysoká škola ekonomická v Praze
Fakulta informatiky a statistiky
Architektura a návrhové vzory pro Serverless aplikace
BAKALÁŘSKÁ PRÁCE
Studijní program: Aplikovaná informatika Studijní obor: Aplikovaná informatika
Autor: Lukáš Philipp
Vedoucí bakalářské práce: doc. Jiří Feuerlicht, Ph.D.
Praha, květen 2021
Poděkování
Chtěl bych poděkovat mému vedoucímu doc. Jiřímu Feuerlichtovi, Ph.D. za trpělivost, připomínky a rady k řešení této práce. Dále také PokéAPI od Paula Halletta který umožňuje používat tuto API k edukativním důvodům a také společnosti Material-UI, která tvoří užasnou otevřenou knihovou komponentů pro React.
Abstrakt
Práce se zabývá problematikou FaaS modelu neboli Serverless, návrhových a architektonických vzorů, které jsou využitelné pro aplikace, které jsou postavené na této nové technologii. Cílem práce je nejprve zanalyzovat Serverless a FaaS, zjistit jejich charakteristiky a z nich vycházející výhody a nevýhody. Dále budou poté ze zjištěných informací představeny jak základní návrhové vzory, které jsou nutné pro běžný běh aplikací na tomto modelu, tak ty, které řeší palčivé problémy této technologie. K dosažení zmíněných cílů byla použita literární rešerše a analýza textů zabývajících se jak problematikou Serverless jako modelu cloud computingu, tak i prací zabývajících se specificky návrhovými vzory. V práci bylo identifikováno 8 charakteristik, 4 výhody, 4 nevýhody, ze kterých byly vytvořeny 4 kategorie motivací pro návrhové vzory. K těmto byla přidána jedna další kategorie, která se věnuje architektuře Serverless aplikací. Tyto kategorie jsou: Architektura služby, Zpoždění a dostupnost, Vázání na poskytovatele, Řízená událostmi a jako poslední Bezstavové a pomíjející. V praktické části byly poté vytvořeny 2 ukázkové aplikace využívající nalezené vzory.
Celkově bylo nalezeno 18 architektonických nebo návrhových vzorů pojednávajících o řešení problémů, které souvisejíc s touto novou technologií. Mezi základní návrhové vzory patří:
Externalizace stavu, Správce události, Api správce, Časovač. Důležité vzory poté jsou:
Nasazovací framework, který umožňuje rychlé nasazení na Serverless platformu nebo Jistič hlídající funkčnost částí aplikace, Dotazník na změny pomáhající s prací externími daty, Ohřívač funkcí, který udržuje funkce takzvaně teplé, či Řetěz funkcí, který odstraňuje problém s časovým omezením FaaS funkcí. Ovšem i zbylé vzory mohou poskytnout silná řešení pro různé problémy.
Klíčová slova
architektura, faas, funkce jako služba, návrhové vzory, Serverless.
Abstract
This thesis deals with the issue of FaaS model or Serverless, design and architecture patterns used for applications built upon this new technology. The goal of this thesis is to analyse Serverless and FaaS, identify their characteristics and the resulting advantages and disadvantages. From this information then find and introduce both the basic design patterns needed for applications built on this model and the patterns that help solve deeper problems of this technology. To achieve these goals both literature research and analyses were used to study not only texts dealing with topic of Serverless as cloud computing model but also papers discussing specifically with its design patterns. In the thesis there was identified 8 characteristics, 4 advantages, 4 disadvantages, from which there were created 4 main categories of motivations. One additional category was added that is focused on the architecture of the Serverless applications. These categories are: Service architecture, Delay and availability, Vendor lock-in, Event-driven and lastly Stateless and ethereal. Two sample applications have been created in the practical part using found patterns.
Overall, there have been 18 architectural or design patterns identified dealing with solving the problems associated with this new technology. The essential design patterns are:
Externalized state, Event manager, API manager, Timer. The important patterns are:
Deployment framework, that allows quick deployment to the Serverless platforms, Circuit breaker controlling correct functioning of different application parts, Polling for changes that helps with external data, Function warmer, that keeps the functions “warm” or Function chain, that removes the timeout limit from FaaS functions. The remaining patterns also provide powerful solutions for different problems.
Keywords
architecture, design patterns, faas, function as a service, Serverless.
Obsah
Úvod ... 9
1 Představení Serverless ... 10
1.1 Základní rozdělení cloud computingu ... 10
1.1.1 Infrastruktura jako služba ... 10
1.1.2 Platforma jako služba ... 10
1.1.3 Software jako služba ... 11
1.2 Termíny Serverless, FaaS a BaaS ... 11
1.3 Charakteristiky FaaS ... 12
1.3.1 Žádná administrace infrastruktury ... 12
1.3.2 Vysoká škálovatelnost ... 13
1.3.3 Událostmi řízené ... 13
1.3.4 Pomíjející ... 13
1.3.5 Bezstavová... 13
1.3.6 Vícejazykové ... 13
1.3.7 Cenová dostupnost ...14
1.3.8 Vysoká dostupnost ...14
1.4 Výhody a nevýhody Serverless přístupu ... 15
1.4.1 Výhody... 15
1.4.2 Nevýhody ...16
1.4.3 Shrnutí ... 17
2 Serverless aplikace a jejich návrhové vzory ... 18
2.1 Co jsou návrhové vzory... 18
Tvořivé vzory ... 18
Strukturální vzory ... 18
Vzory chování ... 18
2.2 Motivace pro Serverless návrhové vzory ...19
2.2.1 Architektura služby ... 20
2.2.2 Zpoždění a dostupnost ... 23
2.2.3 Vázání na poskytovatele ... 26
2.2.4 Řízená událostmi ... 27
2.2.5 Bezstavové a pomíjející ... 32
2.3 Shrnutí ... 36
3 Příklady aplikací využívající návrhové vzory pro Serverless ... 38
3.1 Dotazník ... 38
3.1.1 Popis ... 38
3.1.2 Využití ... 39
3.2 Webová aplikace ... 39
3.2.1 Popis ... 39
3.2.2 Využití ... 40
Závěr ...41
Použitá literatura ... 43 Přílohy ... I Příloha A: ... I Příloha B: ... III Příloha C: ... IV Příloha D: ... IV
Seznam zkratek
BP bakalářská práce
CC Cloud computing
IaaS Infrastruktura jak služba (Infrastructure as a Service) Paas Platforma jako služba (Platform as a Service)
SaaS Software jako služba (Software as a Service) FaaS Funkce jako služba (Function as a Service) VM Virtuální stroj
IDE Vývojové prostředí (Integrated development environment) BaaS Backend jako služba
S3 Simple Storage Service AWS Amazon Web Services
SDK Balíček vývojových nástrojů (Software development kit) SQL Strukturovaný dotazovací jazyk (Structured Query Language) NoSQL Nejen strukturovaný dotazovací jazyk (Non-SQL / Not only SQL) ERP Plánování podnikových zdrojů (Enterprise Resource Planning)
Úvod
Cloud computing (dále CC) je stále více se rozvíjející se model provozu online služeb, a i díky tomu by koncový podle firmy Gartner v roce 2021 by za ně měli zaplatit 304 990 milionů dolarů, tedy o necelých 19 procent více než v předchozím roce (Katie Costello and Meghan Rimol, 2020). Ve studii od společnosti Gartner lze nalézt všechny 3 klasického rozdělení CC a to specificky: IaaS (infrastruktura jak služba), PaaS (platforma jako služba) a SaaS (software jako služba), ovšem chybí zde jeden z novějších přírůstků do možných modelů služeb a to FaaS (funkce jako služba) známa spíše jako „Serverless architektura“ doslovně přeloženo jako: „architektura bez serveru“, která bude tématem právě této práce. Tento růst podporuje především rozdíl právě v ceně FaaS oproti klasickým cloudovým řešením (Vaidyanatha, 2020).
Důvodem pro zvolení této práce je především aktuálnost tématu, a to díky stále se rostoucímu trhu, který se svým předpokládaným ročním růstem 22,7 procent převyšuje průměrné navýšení celého cloud computing trhu (Valuates Reports, 2020). Dále také zkušenost s vývojem webové aplikace využívající Serverless Framework od firmy Serverless, Inc., který umožnuje aplikace psané například v Next.js (Framework pro open-source JavaScriptovou knihovnu React) jednoduše nasadit na FaaS službu AWS (Amazon Web Services) Lambda od společnosti Amazon či na podobné platformy.
Teoretická část bude zahrnovat rešerši a analýzu dostupných publikací, ať článků, vědeckých prací, dokumentací a knih základních informacích o FaaS a Serverless. Práce se především zaměří na užívané návrhové vzory v Serverless prostředí. První kapitola bude zaměřena na představení Serverless, FaaS, rozdíly mezi nimi, základní informace FaaS a následně jaké výhody a nevýhody tento model CC obsahuje. Poté zjištěné charakteristiky budou využity pro hledání návrhových vzorů, které řeší problémy neboli motivace, při tvorbě aplikací na Serverless platformě.
V praktické části bude vytvořeno a prezentováno k čemu může být model použit ať už v malých či větších službách za uplatnění dříve zjištěných informací. Tato část bude vytvořeno za pomoci AWS Lambda z důvodu předchozí zkušenosti s prací na platformě. Specificky bude předvedena webová aplikace pracující s daty z databáze a menší funkce.
Cílem práce je nejprve zanalyzovat Serverless a FaaS, zjistit jejich charakteristiky a z nich vycházející výhody a nevýhody. Dále budou poté ze zjištěných informací představeny jak základní návrhové vzory, které jsou nutné pro běžný běh aplikací na tomto modelu, tak ty, které řeší palčivé problémy této technologie.
V teoretické části bude použita literární rešerše a analýza k nalezení podrobných informací k Serverless. Především potom pro zjištění možných návrhových vzorů rozřazených do skupin podle motivací pro ně.
1 Představení Serverless
Definice cloud computingu podle Oxfordského slovníku je následující: „počítačový systém na kterém jsou data a software uloženy především na centrálním počítači ke kterému se uživatelé připojující přes internet.“ (Oxford Advanced American Dictionary, 2021). Pojem cloud computing není zapotřebí dlouho představovat díky jeho velké popularizaci v posledních letech lidmi pohybujícími v IT zaběhnutý a také díky tomu, že běžný uživatel chytrého telefonu se s ním setkává na denní bázi. V klasické představě o této službě jsou poskytnuty 3 distribuční modely:
• Infrastruktura jako služba (IaaS)
• Platforma jako služba (PaaS)
• Software jako služba (SaaS)
V další části bude v rychlosti rozebráno rozdělení CC a jeho distribucí pro následné snaží vysvětlení v čem se Serverless (FaaS) liší.
1.1 Základní rozdělení cloud computingu
1.1.1 Infrastruktura jako služba
V IaaS se poskytovatel služby zavazuje koncovému uživateli, ať už jednotlivci či společnostem poskytnout infrastrukturu na kterou bude uživatel moct používat dle svých potřeb. Typicky je toto bráno jako vytvoření Virtuálního stroje, anglicky „Virtual Machine“
(VM). Uživatel v tomto případě získá hardware, kde je mu umožněno nakonfigurovat tento server podle jeho potřeb. EC2 služba od společnosti Amazon umožňuje nastavit: Operační systém (Windows nebo Linux, jakou distribuci Linuxu, zda MacOS, Ubuntu či Red Hat), výpočetní sílu (počet jader procesoru, velikost operační paměti) nebo jaké a kolik disků bude server používat pro data. Po úspěšné konfiguraci může uživatel nainstalovat a provozovat službu jako na normálním serveru či počítači ve fyzické podobě (Amazon, 2021a).
1.1.2 Platforma jako služba
Distribuční model PaaS naopak poskytuje uživateli předem dané produkty, které může využít ke svému užitku a odstraní potřebu k nastavení infrastruktury. Uživatel tedy dostane IDE (Integrated development environment) připojené k aplikace spuštěné pomocí platformy k provozu webových aplikací. Dalším příkladem může být databáze do které uživatel nahrává data a nezajímá se o nastavení serverů na kterých tento produkt ve skutečnosti ukládá tato data, příklady takových produktů mohou být: MongoDB Atlas, AWS DynamoDB atd.
Hlavním rozdílem mezi IaaS a PaaS nachází uživatel především díky sníženému počtu starostí, a to díky odstranění nutné znalosti architektury stabilní infrastruktury, nemalých
bezpečnostních rizik a také ve snížení ceny díky odstranění vstupních nákladů v podobě nákupu hardwaru, licencí pro daný server a času stráveném na architektuře serverů.
Uživatel PaaS se tedy obejde s minimální znalostí infrastruktury a dá se říct, že již neztrácí čas staráním se o to, na čem jeho produkt poběží a může své síly, či svých programátorů, plně soustředit na řešení byznysových problémů a vývoj svého produktu.
1.1.3 Software jako služba
Posledním modelem v klasickém rozdělení je SaaS, který tvoří největší podíl na trhu s CC (Katie Costello & Meghan Rimol, 2020). Software jako služba se dá také nazvat jako cloudové aplikace, kdy se jedná o koncový software. Mezi tyto aplikace se řadí služby běžící v prohlížeči, mobilní či desktopové aplikace které nějakým způsobem komunikují s centrálním serverem přes internet. Hlavními charakteristikami jsou tedy automatické stahování nových aktualizací, pokud není stanoveno jinak může uživatel počítat s tím, že používá nejnovější verzi aplikace. Zde se také objevuje takzvaný model více obyvatelů, kdy jedna distribuce aplikace je schopna sloužit více uživatelům. SaaS aplikace také velmi často běží na systému předplacení, kdy uživatel platí měsíční paušál za poskytované služby, které se mohou lišit podle ceny předplatného (Jamcracker, 2020).
Tyto aplikace zahrnují obrovské spektrum možností od větší služeb pro celé firmy zaměřující se na výpomoc s komunikací se zákazníkem a prodejem (SalesForce), přes sociální sítě jako je třeba Facebook až po aplikace zaměřené na poslech hudby příkladem Spotify nebo iTunes. Co odlišuje SaaS od ostatních distribučních modelů je tedy především to, že je užíván především koncovým uživatelem pro určitý, předem daný, softwarem stanoveným způsobem.
1.2 Termíny Serverless, FaaS a BaaS
Termín Serverless se velice často používá jako synonymum pro FaaS, ovšem je to spíše slovo nadřazené a je v něm zahrnut také model „Backend jako služba“ (BaaS). Aplikace popsané tímto modelem mají typicky tlustého klienta (rich client). Toto znamená, že velká část služeb je poskytována nezávisle na serveru mohou to být například mobilní či jednostránkové webové aplikace, jako ukázku se dají uvést online verze Wordu a Excelu od společnosti Microsoft právě díky práci s daty na straně uživatele, kdy server obstarává především ukládání souboru anebo Photopea, což je český online klon Adobe PhotoShopu. Tento typ aplikací z velké části spoléhá na jiné cloudové služby například pro přihlašování (AWS Cognito, OAuth 2.0) nebo na databázové služby (Firebase, Atlas MongoDB) (Roberts, 2018).
Serverless jako takový naznačuje jistý druh pohledu na službu, která má jak velké výhody, tak jisté nevýhody, které je vždy potřeba zvážit v případě migrace či vývoje nové aplikace.
Pojmenování by se dalo nazvat jako zavádějící či až chybné, protože tyto služby se bez serverů jako takových neobejdou k tomu, aby správně fungovaly. Co tento termín znamená v případě modelu FaaS je především odstranění nutnosti, aby aplikace či služba neustále běžela na nějakém serveru. Toto je jedním z velkých tahounů této nové technologie.
Uživatel při používání tohoto modelu vždy platí podle doby a síle výpočetní jednotky.
Zákazník tedy místo klasického modelu, kdy platí za server s aplikací, která neustále běží a naslouchá na příchozí dotazy naopak platí přímo za dobu, kdy služba poskytující řešení uživateli zachytí, že se funkce má spustit na serveru na předem stanovený čas, než bude opět označena jako „studená“ a opět vypnuta. Podrobněji to, jak toto funguje bude probráno níže.
Tento technologický model byl prvně oznámen společností Amazon na jejich konferenci re:Invent v roce 2014, kde představili jejich službu AWS Lambda. Cenový model, pod kterým poběží ta to služba, byl zde představen také, kdy namísto placení za počet a velikost jednotlivých funkcí, které budete v AWS Lambda mít, se bude platit za časový interval měřených v milisekundách. Toto se dá považovat za velmi benevolentní řešení v podobě cenového modelu. Na této konferenci byla technologie představena za pomoci dema, kdy funkce AWS Lambdy byla napojena na S3 (Simple Storage Service) bucket (jiný produkt od společnosti, který je zaměřený na úschovu souborů) a čekala na nahrání souboru.
Tato práce se zaměří především na význam slova Serverless v použití jako synonymum pro FaaS.
1.3 Charakteristiky FaaS
Model jako takový má několik charakteristik, které sdílí nebo oddělují od ostatních cloudových služeb:
• Žádná administrace infrastruktury
• Vysoká škálovatelnost
• Řízené událostmi
• Pomíjející
• Bezstavová
• Vícejazykové
• Vysoká dostupnost
• Cenová dostupnost
1.3.1 Žádná administrace infrastruktury
Jeden z velkých tahounů marketingu FaaS řešení u Amazonu je to, že uživatel nepotřebuje žádnou znalost toho, jak spustit, nastavit nebo spravovat servery. Toto se projevuje tím, že uživateli stačí nahrát pouze kód funkce do rozhraní služby v ZIP souboru nebo v případě AWS Lambda, pokud je kód větší jak 10 MB tak vybrat kde je soubor umístěn v jejich S3 řešení (Amazon Web Services, Inc, 2014)
Co toto znamená pro firmy je především méně administrace a více času pro vývojáře na psaní kódu. Toto také napomáhá například s bezpečností, kdy službu hlídají ti nejlepší z nejlepších a není zapotřebí se starat o aktualizace či jiné problémy.
1.3.2 Vysoká škálovatelnost
Další velkou výhodou, která zároveň navazuje na první charakteristiku, je že díky automatické správě infrastruktury, na které běží funkce či celé aplikace může poskytovatel automaticky navyšovat počet kontejnerů na kterých kód běží. Toto způsobuje obrovskou výhodu, kdy v případě že aplikace získá na popularitě se nemůže stát takzvaný „Slashdot efekt“, kdy služba není připravena na nápor nových požadavků a začne být přehlcena a přestane plnit tyto požadavky. Toto se může stát na cloudových nebo on-premise architekturách.
1.3.3 Událostmi řízené
Tato charakteristika je jedním ze základních kamenů FaaS modelu. Narozdíl od běžných serverů neběží služby na této distribuci neustále, naopak čekají až na zavolání událostí z ekosystému poskytovatele, kdy je následně spuštěna na omezenou dobu, pokud nebudou znovu zavolány v tomto intervalu. Jako příklad lze uvést spuštění funkce jednou za hodinu pomocí časovače.
1.3.4 Pomíjející
Pomíjející v tomto případě znamená, že kód se spouští v takzvaných kontejnerech, kdy po události jako je například změna v databázi, server dostane informaci o tom, že má spustit svůj kód. Po spuštění a provedení mají poskytovatelé nastavený takzvaný timeout pro každou funkci. Pokud na ni nebude zaznamenán další požadavek, bude vypnuta a přejde do takzvaného „cold state“ neboli „studeného stavu“. Tento stav vypne kontejner a jeho výpočetní síla bude poskytnuta pro jinou funkci jakéhokoliv uživatele. Tento interval trvá 5 až 15 minut a liší se dle poskytovatele.
1.3.5 Bezstavová
Tato charakteristika navazuje na předchozí, a to tím, že kvůli neustálému vypínání a zapínání funkce a využívání kontejnerů nemůže kód uchovat stav mezi jednotlivými spuštěními.
Při designování těchto funkcí, jakákoliv data, u kterých může nastat změna, musí být uchována externě, tedy být převedena do databází, souborů atd. (Chowhan, 2018).
1.3.6 Vícejazykové
Jak Azure Functions, tak AWS Lambda podporují více programovacích jazyků, u každého se však může lišit doba spuštění kontejneru, ale programátor není omezen znalostí jazyků, a tudíž si může vybrat, jaký jazyk je právě pro jeho řešení tím nejlepším. Amazon spustil jejich službu s podporou Node.js a postupně přidal nativní podporu pro Javu, Go, PowerShell, C#, Python a Ruby. Také existuje možnost pomocí API (Application Programming Interface) vytvářet funkce v dalších jazycích. Toto umožňuje velké skupině uživatelů využívat tohoto řešení bez nutnosti se prvně naučit nový jazyk, ale také převést již existující aplikace do tohoto modelu bez nutnosti přepsání. Dále není nutné psát pouze
v jednom jazyce ovšem lze využít jazyk, který se hodí specificky pro daný problém (Bardsley et al. 2018).
Následuje příklad, jak by taková funkce mohla vypadat. Vývojář potřebuje pro svou aplikaci vytvářet z obrázků nahraných na jeho webovou galerii menší náhledový obrázek. Rozhodne se napsat tuto funkci v Node.js z důvodu znalosti jazyka a použít AWS Lambda díky cenové dostupnosti. Aplikace jako taková nemá v sobě uchovaná žádná data a používá pouze externě získané soubory. Programátor nemusí řešit, na jaký hardware použít nebo jak si pořadí se škálovatelností, protože to AWS Lambda řeší automaticky i při velkém náporu uživatelů.
1.3.7 Cenová dostupnost
Dalším velkým bodem v popularitě Serverless a FaaS jako takového je cenová dostupnost, a to díky cenovému modelu, na kterém celá služba běží. Na rozdíl od ostatních modelů uživatelé platí za skutečný čas užívání. Toto se může projevit především u menších aplikací, které nejsou příliš vytížené požadavky uživatelů. Tento čas je měřen ve stovkách milisekund a pro mnoho společností umožňuje značné snížení výdajů. Microsoft nabízí jejich službu Azure Functions v ceně 0.000014 eura za GB-sekundu (GB-sekunda je čas běhu funkce vynásobený počtem RAM, kterou funkce využívá) a 0.169 eura za milionů požadavků (Microsoft, 2021a). Oproti tomu jejich řešení virtuální strojů je ceněno na hodinu a nejlevnější řešení začíná na 0,007 eura za hodinu (Microsoft, 2021b). Pokud FaaS bude porovnáno s PaaS, lze vyvodit, že FaaS je vhodnější pro krátké a předpovídatelé služby.
Naopak PaaS je vhodný spíš pro časově nepředpověditelné procesy (Albuquerque Jr et al., 2017).
1.3.8 Vysoká dostupnost
Velká část společností poskytující FaaS mají svá datacentra ve velkém množství lokací po celém světě, je tedy velmi nepravděpodobné, že by se funkce nespustila. Například společnost Amazon má svá datová centra v 80 zónách ve 25 regionech po celé planetě (Amazon, 2021b). Toho je docíleno právě díky nevázanosti na určitou infrastrukturu, kód lze spustit ve virtuálním kontejneru, který není nijak omezen tím, kde ho lze vytvořit.
1.4 Výhody a nevýhody Serverless přístupu
IT obor jako takový se neustále vyvíjí, a to platí dvakrát u nových technologií. FaaS je stále novou technologií, která se vyvíjí a nachází nové způsoby využití, ale rozhodně to není řešení všech problémů IT, ať už webových aplikací či jiných služeb. Jako každá technologie má svá pro a proti.
1.4.1 Výhody
Škálovatelnost
Navyšování kapacity produktu díky Serverless přestává být problémem právě díky myšlence, která stojí za celou technologií. To jsou virtualizace a abstrakce provozu kódu na serveru. Pokud poskytovatel zaznamená, že funkce bude potřebovat větší paměť nebo když služba zažívá větší provoz, než by server zvládl, dokáže jednoduše navýšit kapacitu. Ta je potřeba k tomu, aby uživatelé, kteří chtějí využívat službu, zaznamenali co nejmenší problém, a to vše bez jakéhokoliv zasažení administrátora.
Snížení administrace
Díky jednoduchému spuštění kódu a provozu aplikací na FaaS modelu bez nutnosti inicializace serveru či jeho provozu a administrace se enormně sníží to, co vývojář musí vědět o používání serverů. Patří sem například nastavení routingu, zajištění bezpečnosti či hardwarové potíže.
Více času pro vývoj
A právě díky snížené administraci se redukuje takzvaný „čas k trhu“, tedy doba, mezi kterou je produkt vymyšlen až k tomu okamžiku, kdy je spuštěn na trh. Programátor pouze nahraje složku s kódem do rozhraní poskytovaného službou, o vše ostatní se již postará služba samotná. Pokud se jedná o složitější aplikaci, tak lze využít různých frameworků, jako například Serverless Framework, který umožnuje automatického nahrání celých aplikací pomocí konfiguračního souboru a příkazu v příkazovém řádku. Proto se vývojáři mohou soustředit především na řešení byznysových problémů namísto řešení nastavení serverů.
Snížení ceny
Všechny předchozí výhody včetně samotného cenového modelu, který je poskytován provozovateli FaaS modelů přispívají ke snížením ceny. A právě díky nepotřebě speciálních správců serverů, snížení doby vývoje a celkové redukci výdajů za backend se může cena provozu aplikace snížit až o 278 % (Vaidyanatha, 2020).
1.4.2 Nevýhody
Přehlednost
Myšlenkou FaaS je rozdělení velkých monolitických aplikací do menších funkcí. Právě z této myšlenky vzniká menší přehlednost díky širokému segmentování. Dalším problémem je, že díky abstrakci celé infrastruktury způsobuje menší přehlednost kvůli nižším možnostem testování klasickým stylem, což může způsobit problém v debuggingu například u větších aplikací, kde jsou jednotlivé funkcionality velkým shlukem provázaných menších funkcí.
Řešením mohou být například externí aplikace na monitorování a logování.
Zpoždění
Dalším problémem, který na rozdíl od ostatních pocítí hlavně uživatel samotné služby namísto vývojáře, je cold start, tedy doba, za kterou poskytovatel FaaS řešení inicializuje funkci od prvního dotazu na ní. Tato nevýhoda se také liší dle poskytovatele a také podle programovacího jazyka, který funkce používá. Časy se mohou lišit až několika sekundami (Mikhail Shilkov, 2021a). I kvůli studenému startu musí být převod existujících aplikací do Serverless modelu zváženo, protože lze pozorovat značný rozdíl oproti například PaaS modelu (Albuquerque Jr et al., 2017).
Vázání na poskytovatele
To, co je potřeba pro spouštění aplikace, se také může lišit dle poskytovatele. Pokud tedy píšeme kód například na AWS Lambda, nemusí stejný kód fungovat v Azure Functions či Google Cloud Functions. Ještě více se naše provázání s poskytovatelem může prohloubit, pokud použijeme vícekrát zmíněný příklad s náhledovými obrázky. K takové situaci dojde, pokud využijeme službu poskytovatele i na správu souborů nebo jejich databáze. Cena na přesun z jedné služby na druhou se poté zvýší více než u běžného kódu. S tímto ovšem bojují některé frameworky, které jsou multiplatformní nebo zvyšují abstrakci kódu od platformy.
Snížení kontroly
Co pro jiné může být výhodou, je pro jiné nevýhodou, v tomto případě se jedná o přehlednost toho, na jakém hardwaru software běží. Nemožnost větších úprav, sledování, specifikace či kontrola běhu může být pro některé uživatele velkým soustem, protože je to poměrně velká změna oproti současné situaci, kdy přesně víme, jaký hardware je užíván.
Dalším problémem mohou být bezpečnostní útoky kvůli tomu, že jednu infrastrukturu používá více aplikací, tudíž se zvětšuje pravděpodobnost, že se aplikace stane cílem či vedlejší škodou útoku.
1.4.3 Shrnutí
Serverless přístup je silným nástrojem především pro menší aplikace, týmy nebo firmy, které nemají tak obsáhlý rozpočet na provoz, velké zkušenosti s infrastrukturou nebo chtějí moderní přístup k vývoji. Výše zmíněné úspory na provozu aplikací oproti starším systémům jsou velkým hnacím motorem pro tuto novou technologii a jsou také důvodem, proč se k ní přiklání stále více firem. Ovšem úspory nejsou vše a pro některé aplikace se tento model nehodí. Robustní již běžící aplikace mohou být příliš náročné na konverzi k Serverless přístupu, případně velké aplikace, kde funkce mohou trvat i několik minut, nejsou vhodné pro FaaS model. Někteří uživatelé mohou mít problém se ztrátou kontroly a přehledu nad aplikací. Pro některé uživatele může být dále zásadním problémem málo informací o tom, na jakém hardwaru aplikace běží.
Serverless přístup jako každá technologie má svá pro a proti, každý její uživatel si musí říct, zda je tento model pro jeho specifické potřeby vhodný. Dá se ovšem očekávat, že jak bude technologie dospívat, část problémů zmizí díky větší podpoře komunity po celém světě.
Příkladem je vázání na poskytovatele nebo přehlednost aplikace. Ovšem existují problémy, které budou Serverless provázet po celou existenci, protože jsou způsobeny tím, na čem je model postaven.
Na co se tedy dá využít Serverless? V roce 2018 uspořádala společnost Serverless, Inc., která pracuje na frameworku pro více platformové nasazování aplikací do Serverless prostředí (o tom dále později), dotazník ohledně toho, k čemu tento framework využíván. Z odpovědí je jasně vidět, že nejčastějším způsobem pro FaaS a Serverless jsou právě API, funkce na zpracování dat, propojení služeb třetích stran atd. (Passwater 2018).
Co nám tyto data říkají, je to, co se dá vyčíst právě z charakteristik FaaS a tedy, že se tyto služby hodí především pro menší aplikace či služby, u kterých vyžadujeme, aby byly vždy dostupné, ovšem není u nich zapotřebí, aby byly provozovány na neustále běžícím, silném serveru a nejsou pod velkým náporem uživatelů. Pro robustní aplikace s velkým počtem uživatelů a velkým provozem jsou naopak vhodnější klasická on-premise či cloudová řešení, ať už je to z důvodu lepší kontroly nad hardwarem či výhodnějším cenovým řešením pro více vytížené aplikace.
2 Návrhové a architektonické vzory Serverless aplikací
V předchozí části byly rozebrány základní charakteristiky Serverless a FaaS a s nimi i jejich přednosti a nedostatky. Tato část práce probere návrhové vzory Serverless aplikací a následně zhodnotí využití v reálném světě s uvedením příkladů. V této práci budou návrhové vzory rozděleny podle řešených problémů neboli motivací.
2.1 Co jsou návrhové vzory
„Návrhové vzory jsou znovu použitelná řešení pro vývoj softwaru. Fungují jako šablony, které může vývojář použít při tvorbě aplikací. Nejsou určené pro specifické programovací jazyky, ale používají se jako best practices či obecná pravidla, která mohou být využita napříč různými vývojovými prostředími.“ (Sharpen Productions, 2021)
Jak je možné z definice vyčíst, návrhové vzory nemusí být určeny pro programovací jazyky.
V mnoha případech jsou spojeny s určitou technologií. Ve velké části z nich se vyskytuje popis tříd, a tudíž se vážou na objektově orientované programovací jazyky (Java, C# atd.).
Každý návrhový vzor by měl popisovat, jaká je motivace (problém), která za ním stojí, dále by měl obsahovat samotný popis možného řešení.
Návrhové vzory se dělí na tři typy:
• Tvořivé
• Strukturální
• Chování
Tvořivé vzory se zaměřují na tvorbu jednotlivých objektů v systému pro specifický případ a na to, kolik právě tohoto objektu má v systému být. Mezi příklady patří Jedináček (omezení počtu instancí na jednu) nebo Abstraktní továrna (spojení rodiny objektů, které mezi sebou nějak souvisí).
Strukturální vzory se pak starají o vztahy jednotlivých tříd, částí kódu či objektů.
Příkladem může být Adaptér (upravuje třídy pro potřeby jiné) či Dekoratér (přiděluje dynamicky odpovědnosti jiným objektům)
Vzory chování jsou zaměřeny na komunikaci mezi jednotlivými objekty, také napomáhají s jejich flexibilitou. Příkladem může být Řetěz povinností (pomáhá s řízení dotazu skrz více objektů) dále Příkaz (parametrizace požadavků pro jejich lepší rozdělení).
Pro lepší vysvětlení bude použit příklad. Vývojář aplikace spravuje databázi a chce uživateli poskytnout možnost ji používat, zároveň ovšem nechce, aby v ní prováděl změny. Motivací
je tedy umožnění uživateli aplikace přístup k databázi s omezenými právy, není žádoucí, aby mohl vidět citlivá či smazat důležitá data. Využít lze tedy návrhový strukturální vzor Proxy, kterým radí v tomto případě vytvořit zástupný či dočasný objekt, kterému budou přidělena oprávnění. Ta budou vyhovovat stanoveným potřebám a neohrozí data jiných uživatelů. I toto řešení přináší jisté nedostatky, například pak zpomalení odpovědi či větší složitost kódu díky novým objektům. Ovšem ochrana proti nezodpovědným uživatelům a usnadnění pochopení kódu díky použití zdokumentovaných řešení, tyto problémy převyšují (Alexander Shvets, 2021).
2.2 Co jsou architektonické vzory
„Architektonický vzor je obecné, znovu použitelné řešení k často se vyskytujícímu problému v softwarové architektuře v daném kontextu. Tyto vzory často popisují několik možný problémů při vývoji softwaru. Například jak řešit limitace počítačového hardwaru, zajistit vysokou dostupnost a minimalizovat rizika pro byznys.“ (Taylor et al., 2009)
Na rozdíl od návrhových vzorů se tento druh zabývá tím, jak je celá aplikace sestavena a jak její části na sebe navazují, spolupracují nebo mezi sebou komunikují. Ať už je to rozdělení jednotlivých aplikací do několika vrstev. Příkladem může být rozdělení do 4 vrstev a to prezenční, aplikační, byznysové a datové. Dalším příkladem poté může být vzor klient- server, peer-to-peer a mnoho dalších (Mallawaarachchi, 2020).
Tyto vzory se zaměřují na velké množství technologií v různých oborech IT. Oblasti, kterými problémy, kterými se mohou zabírat jsou: datová architektura, velikost služeb, analýza textu či různé způsoby rozhodování v oboru umělé inteligence.
2.3 Motivace pro Serverless návrhové vzory
V předchozí kapitole byly popsány jisté charakteristiky Serverless, tato část některé z těchto charakteristik využije jako motivaci pro návrhové vzory, které pomohou s řešením problémů, které se mohou objevit. K těmto 4 vzniklým kategoriím bude přidána pátá, která bude popisovat architekturu funkcí či celých aplikací na platformě.
• Architektura služby
• Zpoždění a dostupnost
• Vázání na poskytovatele
• Bezstavové a pomíjející
• Řízená událostmi
Tento list poslouží jako motivace pro návrhové vzory, které budou popsány více do hloubky, dále bude poukázáno na jejich možná využití. V této části nebudou popsány všechny nalezené vzory, pouze ty, kterých motivace souvisí s výše zmíněnými charakteristikami a řeší jejich problémy. Řeší zajímavý problém či základní potřebu pro provoz na tomto
modelu. Výjimkou jsou první 3 vzory, které se zabývají architekturou aplikace, zatímco navazující kategorie řeší specifický problém.
2.3.1 Architektura služby
Tato část je zaměřena především na to, jakou architekturu vybrat pro aplikace v Serverless světě nebo například pouze pro API. Narozdíl od zbylých kategorií se nebude jednat o to, jak strukturovat pracovní postup aplikace či jejích částí, nýbrž o to, jakým způsobem vytvořit architekturu aplikace. Důvodem pro používání jednotných vzorů architekturních vzorů je především snadné zaučení nových vývojářů a zvýšení přehlednosti u větších aplikací atd.
API neboli rozhraní pro programování aplikací umožňuje dvěma aplikacím komunikovat mezi sebou. Jako API se dá považovat také kontaktní místo, mezi někým, kdo informaci požaduje (dotaz) a někým, kdo informaci poskytuje (odpověď) (Red Hat, Inc, 2021).
Příkladem takového API může být dotaz, který bude obsahovat jméno a příjmení uživatele a jako odpověď přijde výpis uživatelů, který odpovídá těmto kritériím. V této práci se bude jednat o modelovou ukázku takového API na serveru za pomoci jednoduchých dotazů pro získání (GET), upravení (PATCH), vytvoření (POST) či smazaní (DELETE) dat z databáze.
Monolithic pattern (Monolitický vzor)
Zdroje: [(Rud, 2019), (Hefnawy, 2021), (Richardson, 2021), (Retter, 2020)]
Motivace: Rychlý vývoj, spuštění a otestování funkcionality
Řešení: Tento vzor zahrnuje všechen kód služby do jedné velké Lambda funkce či u jiných technologií jako jeden adresář. Využití pro tento vzor je především z důvodu rychlého vývoje a jednoduchosti propojení funkcí mezi sebou. Vyskytuje se tedy často u menších aplikací operujících na FaaS či na začátcích aplikací pro otestování funkcionality, takzvaný „proof of concept“ (Rud, 2019). Je zde také možné snížit šanci na „cold start“, kde díky častým dotazům bude funkce evidována jako „warm“, a tudíž nebude nikdy po delší dobu vypnuta a nebude nutné ji znovu inicializovat (Hefnawy, 2021).
U větších funkcí poté začnou být výhody zastíněny nevýhodami jako například:
• Zpomalení inicializace funkce na serveru
• Snížení přehlednosti funkce úměrně k velikosti
• Změny či chyby v částech kódu mohou způsobit dominový efekt ve zbytku aplikace
• Zbrzdění rychlosti vývoje více lidmi
Proto je možné najít tento kód v historii většiny služeb na dnešním trhu, příkladem je Netflix. Ovšem firmy z monolitického vzoru přecházejí na jiný druh architektury, protože se může stát něco podobného jako právě výše zmíněné společnosti (Richardson, 2021).
Netflixu v roce 2008 kvůli jedné chybě na několik dní nefungoval systém (Rud, 2019). Od té doby firma rozdělila svůj software na více jak 700 mikroslužeb a přesunula se na AWS s tím,
že využívá do určité míry i FaaS funkce například na rozdělení nahraných videí do 5minutových kousků pro další práci (Retter, 2020).
Microservice pattern (Vzor mikroslužeb)
Zdroje: [(SmartBear Software. 2021), (Hefnawy, 2021), (Benetis, 2017)]
Motivace: Velká škálovatelnost a odolnost vůči chybám
Řešení: „Architektura mikroslužeb neboli mikroslužby je způsob vývoje softwarových systémů, který se zaměřuje na stavbu samostatných funkčních modulů s definovanými rozhraními a operacemi.“ (SmartBear Software. 2021)
To v praxi znamená, že aplikace nejsou jedním velkým repositářem, kde se shromažďují všechny funkce, které aplikace obsahuje, ale jsou spíše rozděleny do jasně definovaných menších aplikací, které obstarávají nějakou část daného celku.
V případě API by se tedy jednalo o rozložení jednotlivých akcí nad databází na jednotlivé funkce. Na rozdíl od předchozího typu tedy budeme mít samostatnou Lambda funkci pro každou akci (Hefnawy, 2021).
Tento styl umožňuje bezpečný a přehledný systém pro produkční verzi aplikace, protože chyba v jedné funkci nezasáhne žádným zásadním způsobem ostatní části aplikace. Také zvyšuje agilitu vývoje díky tomu, že jednotlivé týmy či jednotlivci mohou jednoduše přidávat další funkcionalitu bez větších změn celé aplikace (Benetis, 2017). Napomáhá k urychlení hledání chyb díky tomu, že je přesně známo, odkud chyba přišla a lze očekávat většinou jeden druh odpovědi (Hefnawy, 2021).
Mezi nevýhody tohoto přístupu patří:
• Velký počet funkcí, obzvláště pak u FaaS, kde jsou funkce ještě menší než u běžných mikroslužeb
• Vetší šance na „cold start“ u méně užívaných funkcí
• Pomalé nasazení
Toto se může projevit v reálném světě například tím, že jedna mikroslužba bude u společnosti Netflix obstarávat profily seriálů, tedy část, kde se zobrazuje, kolik má seriál dílů, o čem je, kdo v díle hraje atd. Naopak jiná funkce se bude starat o jejich nahrávaní.
Díky tomuto řešení se již nestane, že služba, která se stará o nahrávání souborů přestane fungovat a nezřítí se celý systém, ale pouze jednu jeho část. Uživatel nemusí o tomto problému ve výsledku vůbec vědět.
Service pattern (Vzor služeb)
Zdroje: [(Hefnawy, 2021)]
Motivace: Vyšší přehlednost funkcí při zachování odolnosti vůči chybám
Řešení: Tento typ se dá nejsnáze využít nad NoSQL (Not only Structured Query Language) databází jako je například MongoDB, kdy lze rozdělit akce podle objektů. Na příkladu API bude každá Lambda funkce obstarávat jeden objekt, k němu pak všechny 4 akce (Hefnawy, 2021). Není potřeba vždy rozdělit funkce přes model, lze také každé funkcionalitě přidělit zvláštní funkci a její akce.
O tomto vzoru lze tedy říct, že se jedná o kombinaci monolitu s mikroslužbami, kdy kombinuje vyšší přehlednost, rychlejší nasazení, ovšem zároveň umožňuje vyšší odolnost vůči chybám a snazší práci více týmů na jiných částech aplikace. Další výhodou této architektury je vyšší šance, že funkce bude zachována jako teplá díky častějšímu volání (Hefnawy, 2021).
Problém tohoto stylu je ovšem v tom, že nedělá ani jednu z těchto věcí pořádně a za cenu výhod monolitu získává jeho jisté nevýhody.
• Složitější debuggování, díky většímu počtu možných odpovědí
• Větší funkce, a tudíž pomalejší inicializace Rozdíl mezi vzory
Obr 1 Ilustrace struktury jednotlivých vzorů, kruhy symbolizují Lambda funkce a jaké akce ovládají Nejsnazším způsobem, jak jednoduše vysvětlit rozdíl mezi těmito přístupy je poté přímo na kódu pro RESTful API. Tato API bude mít za úkol práci v databázi, a to nad tabulkami osoba a zvíře. Akce budou u obou tabulek stejné tedy pro vytvoření (POST), upravení (PATCH), smazání (DELETE) a nalezení (GET).
U monolitického vzoru by všechny tyto akce měla na starost jedna velká Lambda funkce.
Její výhodou by tedy byla eliminace častého cold startu, ovšem náročnější debugging a dá
se očekávat, že by byla i dražší. Tedy v monolitickém vzoru by každá služba využívala několik velkých Lambda funkcí.
Vzor služeb by měl dvě Lambda funkce. Každá z těchto funkcí by obstarávala všechny 4 akce nad každou tabulkou. Aplikace nad tímto vzorem by se tedy skládala z více středně velkých funkcí.
Posledně pak mikroslužby, kde by každá akce měla vlastní funkci a taková aplikace by se skládala z obrovského množství malých funkcí. Díky tomu se dá očekávat, že uživatel častěji narazí na cold start, ovšem vývojář získá mnohem snazší debugging a nezávislost celého systému.
2.3.2 Zpoždění a dostupnost
Studený start patří k těm nejznámějším charakteristikám pro veřejnost, především z důvodu, že ji uživatelé pociťují nejvíce kvůli delšímu času na spuštění u prvního dotazu na funkci. V této oblasti lze pozorovat pokrok, jelikož někteří poskytovatelé dokážou u
„rychlejších“ jazyků dosáhnout časů kolem jednotek sekund.
V dnešní době je podle společnosti Google doporučená doba na načtení stránky mezi 1 až 2 sekundami, kdy se šance na odchod uživatele po tomto časovém intervalu zvyšuje až o 60 procent (Google LLC, 2017). Pokud tedy společnost provozuje svůj web či jeho část na Serverless technologii a poskytovatel ho má zaevidovaný jako studený, tak se podstatně zvyšuje šance na odchod potenciálního zákazníka či uživatele. Jak tedy omezit dobu, za kterou se aplikace spustí nebo alespoň snížit dobu čekání uživatele na odpověď pro jeho dotazy?
Lambda warmer (Ohřívač funkcí)
Zdroje: [(Intent Solution Group, 2019), (Likness, 2020), (Serverless Heroes, Inc., 2017), (Neves, 2021), (Daly, 2020)]
Motivace: Omezení počtu studených startů a dobu, po kterou musí čekat.
Doba, za kterou jednotlivý poskytovatelé FaaS vypnou kontejner, ve kterém čeká funkce na událost, se liší. Ovšem většinou se pohybuje mezi 5 až 15 minutami, například pro AWS Lambda lze hovořit o intervalu mezi 5 až 7 minutami (Mikhail Shilkov, 2021b). Pokud se tedy bude jednat o méně používanou službu či bude slabší provoz, může se uživateli stát, že na studený start narazí hned několikrát, bude-li procházet více částí webu nebo ho procházet pomalu.
Řešení: Problém se dá řešit, pingováním této funkce v určitém časovém intervalu, aby se udržela teplá (Likness, 2020). Tento časový interval by měl ideálně být podobný jako je nejkratší možná doba, kdy poskytovatel vysadí kontejner s funkcí (Serverless Heroes, Inc., 2017). Například u služby AWS Lambda by to mělo být 5 minut. Ideální pro toto řešení je
využití Časovače (o tom později), který umožňuje v předem stanoveném intervalu zapnout funkci, a tudíž ji udržet naživu (Daly, 2020).
Alternativním řešením by mohlo být nahřátí funkce při vstupu na stránku, která předchází této funkci. Tedy pokud jsme na stránce o správě uživatelů, vyšleme ping na funkce, které spravují jednotlivé akce. Tento styl má nevýhodu u velkých aplikací, kdy se toto může stát nepřehledným.
Dalším způsobem, může být využití pluginu do používaného frameworku, který tento problém řeší bez zbytečné konfigurace na straně poskytovatele a udržuje funkce teplé pomocí nastavení přímo v kódu (Neves, 2021).
Tento vzor navýší cenu této Lambda funkce i přes velmi krátké volání, ovšem právě díky cenovému modelu, kdy se platí pouze za dobu, kdy funkce vypočítává, a ne za to, kdy čeká na dotaz, se toto řešení dá aplikovat, pokud existují obavy o možnou ztrátu zákazníků.
The Circuit Breaker (Jistič)
Zdroje: [(Daly, 2018), (Amazon Web Services, Inc, 2019b), (Coulter, 2020), (Bardsley et al., 2018)]
Motivace: Snížení času na odpověď při chybě
Jak bylo identifikováno v první kapitole, z charakteristik Serverless vychází, že jich velká část využívá mnoho API třetích stran. Tedy aplikace, které nespravuje samotný uživatel, pouze využívá jejich služeb pro své potřeby. Příkladem mohou být jednoduché API na získání současného kurzu až po složitější na získávání a upravování dat pracovníku v aplikaci na správu pracovní doby.
Čím více takových API tím více možných chyb v systému, z čehož vychází delší doba čekání na odpovědi, zároveň pak i výpočetní doba, za kterou poskytovatel FaaS platformy dostane zaplaceno. Jak tedy eliminovat možné vyhozené peníze při volání na zrovna spadlou API?
Řešením je vytvoření takzvaného Jističe
Řešení: Jistič bude sledovat počet chybných odpovědí ze strany API. Pokud překročí předem určený počet chybných odpovědí, tak automaticky začne vracet chybovou odpověď uživateli bez volání na API a po předurčeném intervalu se opět otevře. Ovšem nebude fungovat stejně jako za běžného provozu, protože šance, že stále nebude funkční, je poměrně velká. Po uplynutí tohoto intervalu se opět otevře tato cesta s menší kapacitou, tedy přibližně na 20 procent, a bude dále sledovat, zda je již v pořádku. Pokud se ukáže, že je API stále chybová, tak se opět zavře a restartuje se tento interval. Naopak, pokud se ukáže, že je již funkční, tak ji lze opět otevřít v plné síle a už není potřeba většině uživatelům vracet automatickou zprávu o chybě (Daly, 2018).
Zásadní výhodou tohoto řešení je snížení času, který aplikace prostojí při čekání na chybovou odpověď, a tedy placení za dobu běhu funkcí (Coulter, 2020). Díky tomuto řešení lze také předejít kritickým chybám a zbytečnému tvoření nových funkcí (Bardsley et al.,
2018). U Serverless rčení: „Čas jsou peníze“ platí dvakrát. Bohužel, toto není nejjednodušší řešení na implementaci, právě kvůli bezstavovosti Serverless. Tento vzor se tedy hodí především, pokud se jedná o aplikaci velmi vytíženou aplikaci s mnoha dotazy na pozadí.
V tomto případě bude peněžní ztráta z dlouhého prostoje značná.
Obr 2 Přeložený ilustrace možného postupu Jističe (Daly, 2018)
The Scalable Webhook (Do fronty)
Zdroje: [(Beswick, 2021), (Romero, 2019). (Daly, 2018), (Microsoft, 2018), (Zambrano, 2018)]
Motivace: Škálovatelnost dotazů na neškálovatelný server
Na AWS Lambda funkcích je nastavený výchozí limit počtu souběžně spuštěných funkcí na 1000 pro jeden region (Beswick, 2021). To znamená, že pokud funkce obdrží v jednu chvíli 2000 dotazů, polovina z nich automaticky obdrží chybový kód. Podobný problém také může nastat, pokud se jedná o méně agilní řešení, než jsou právě FaaS funkce, například klasické databáze, kde bývá limit nastaven na počet dotazů v jednu chvíli.
Řešení: Vytvořením fronty před samotným serverem a zamezení přetížení
Pokud mezi API bránu a funkci vložíme takzvaný frontový systém dosáhneme chtěného efektu. Tento systém umožní vytvořit z velkého počtu dotazů frontu, ve které bude několik menších balíčků dotazů, které jsou rozložené do delšího intervalu. Díky této frontě nebude zapotřebí odpovídat chybovou hláškou na tyto dotazy. Rozdělí tedy dříve zmíněných 2000 dotazů do menších balení, které je služba schopna obstarat, například 500.
Při využití Do fronty pro stabilizaci API lze pomocí frontové služby odeslat klientovi zprávu o zpracovávání jeho dotazu (202), kdy uživatel dostane vizuální odpověď. Následně je proveden dotaz v pozadí a jsou odeslána zpracovaná data ze serveru na uložený kód kontaktu s klientem (Romero, 2019) (Beswick, 2021).
Tento vzor slouží jako obrana aplikace především při náhlém externím nárůstu dotazů, proti potencionálnímu přetížení a následnému pádu, a to ať už se jedná o ochranu funkce vlastní či třetí strany (Microsoft, 2018). Tento vzor by neměl mít znatelný dopad na běžný provoz aplikace, ovšem poskytuje obrovskou výhodu při práci pod velkým náporem (Daly, 2018).
Frontou je poskytnuta větší odolnost, škálovatelnost a je umožňeno vývojářům předpovídat, pod jakým náporem budou pracovat jejich funkce a služby (Zambrano, 2018). Dále také existuje možnost ušetření za cenu služby, jelikož není potřeba nastavovat sílu funkce na maximální provoz, postačí nastavení provozu na běžný (Microsoft, 2018).
Problém pro frontové systémy pak tvoří synchronní dotazy, kdy dotazovatel očekává okamžitou odpověď a nemůže bez ní pokračovat, protože mohou vzniknout výdaje za prostoj na dvou funkcích.
2.3.3 Vázání na poskytovatele
Nasazovací framework
Zdroje: [(Apex Software, 2021), (Serverless, Inc., 2021b), (The Apache Software Foundation, 2021), (Umiker, 2019)]
Motivace: Nechceme být vázání na poskytovatele kvůli snaze o snížení výdajů
Takzvaný vendor lock-in může být problémem z mnoha důvodů, ať už se jedná o snahu o udržení nákladů na minimum, nespokojenost s dosavadním řešením či o snahu o využívání nových specifických technologií, které jiný poskytovatel neumožňuje.
Řešení: Tento problém lze řešit za pomoci frameworků, které umožňují automatizaci nahrávání kódu do různých řešení od Serverless poskytovatelů. Výběr tohoto frameworku bude probíhat za pomoci zjištění toho, které poskytovatele podporují (AWS, Microsfot, Google atd.) a jaké programovací jazyky jsou na nich dostupné (Node.js, Next.js, Python atd.). Po výběru frameworku a jazyka následuje nastavení jak na straně poskytovatele, tak ve vývojovém prostředí.
Existují dva druhy frameworků, jedny pracují s existujícími CC řešeními (Serverless Framework, Apex Up atd.) a druhé naopak vytváří vlastní Serverless prostředí (Apache OpenWhisk atd.).
První možný se nastavuje především pomocí souborů existujících v repositáři aplikace, tedy například typu JSON či YML (Serverless, Inc., 2021b). V těchto souborech se odehrává samotné nastavení různých služeb na straně poskytovatele. Zde lze nastavit, jaká práva může mít služba, pod jakým URL se aplikace zobrazí nebo to, jak se bude jmenovat úložiště se soubory a mnoho dalších podrobnějších nastavení. Nastavení toho, jaký účet bude pro tyto služby využit, se ukládá v souborech frameworku. Zde se odstraní další starosti s administrativou z toho důvodu, že o nahrání, nastavení a spuštění aplikace u poskytovatele se stará pouze jeden soubor a o ostatní se postará framework.
U některých frameworků jako Apex Up nebo Claduia.js vzniká problém, kdy je možnost nasadit tato řešení pouze na AWS Lambda. Toto je způsobeno především rozdělením společností přes poskytovatele Serverless prostředí, a to díky tomu, že 70 procent z nich využívá právě řešení od společnosti Amazon (Conway, 2017). V tomto nám tedy umožňuje skutečnou svobodu především Serverless Framework, který nabízí všechny hlavní hráče na poli Serverless (Serverless, Inc., 2021b).
Druhou možností je potom spuštění vlastního Serverless řešení na lokálním či veřejném serveru, kdy naopak lze získat zpět jistou kontrolu nad tím, jak se alokují prostředky pro aplikaci. Tento typ na rozdíl od předchozích vyžaduje více znalosti a má složitější zprovoznění, ovšem poskytuje větší kontrolu nad aplikací (The Apache Software Foundation, 2021). U Apache OpenWhisk, je zapotřebí ke spuštění Java, Docker a Node.js a lze ho mít funkční během několika minut, ovšem pro plné využití těchto služeb bude nastavení trvat déle než u předchozího typu. Zde vzniká stejný problém provázání s poskytovatelem jako při vývoji pro jistý typ cloudu.
Po nastavení těchto frameworků lze již programovat jako za normálních okolností s možností provozování aplikace v lokálním prostředí, následně pak nasadit aplikaci, v některých případech až pomocí jednoho příkazu (Serverless, Inc., 2021b). Následně je třeba vyčkat na oznámení o skončení nasazení a lze vstoupit na poskytnutou adresu, kde je testováno, zda aplikace běží tak, jak má.
Využitím frameworku získáme větší flexibilitu při snaze o přechod na jiné cloudové řešení.
Samozřejmě se musí dát pozor, aby nedošlo ke svázání s jedním z poskytovatelů i přímo v aplikaci do jejich ekosystému. Poté by se mohlo stát, že výdaje na samotnou migraci by byly vyšší než ušetřené výdaje u nového poskytovatele. Ovšem i u frameworků, které podporují pouze jednu platformu je snížena provázanost na poskytovatele díky vytvoření aplikace s větší abstrakcí nad řešením.
2.3.4 Řízená událostmi
Event Processor (Správce události)
Zdroje: [(Pekkala, 2019), (Amazon Web Services, Inc, 2014), (Hong, Srivastava, Shambrook, & Dumitras, 2018)]
Motivace: Chceme spustit funkci při vyvolání události
Řešení: Správce události spravuje funkce, které čekají na to, až se něco stane v jiných částech ekosystému poskytovatele. Tyto funkce jsou napojeny například na tabulky v databázích či úložiště souborů a čekají na změnu dat v nich (Pekkala, 2019).
Častým příkladem tohoto vzoru je práce se soubory v uložišti. Tento příklad byl použit společností Amazon při prvním představení AWS Lambda služby. Když systém zaznamená, že uživatel nahrál nový soubor do S3 úložiště, vyšle na napojené Lambda funkce informaci o této události a přiložený soubor. Funkce se následně spustí, provede v ní nastavený kód a vytvoří náhledový obrázek zpět v úložišti. Tento systém je efektivnější verzí staršího přístupu takzvaného Dotazníku na změny, kdy se dříve spouštěl kód v časovém intervalu pro zjištění změn, pokud nějaká změna byla nalezena, byl spuštěn kód odpovídající za chtěnou funkcionalitu (Amazon Web Services,Inc , 2014).
Toto je poměrně velká výhoda především pro snížení ceny a rychlost provedení této akce, protože se spustí pouze, když je potřeba a není zde žádná prodleva ani zbytečně utracené peníze za prázdný běh funkce.
API gateway (API správce)
Zdroje: [(Amazon Web Services, Inc, 2021a), (Daly, 2018), (Likness, 2020)]
Motivace: Chceme spustit funkci při vyvolané události z internetu
Řešení: Tento problém lze řešit vytvořením takzvaných API správců, například společnost Amazon nabízí službu API Gateway. Brána umožňuje naslouchat na URL adrese, ať už pro veřejné či interní dotazy.
Samotný Amazon nabízí dva možné návrhové vzory. Tyto dva vzory se liší počtem vytvořených bran. U prvního vzoru se jedná o vytvoření více bran pro každou funkci či skupinu funkcí, na které zavolá mateřská funkce s informacemi, které jí uživatel poskytl. To způsobí, že každá brána určí, která část kódu obsluhující žádanou funkci bude spuštěna pomocí poskytnutých parametrů v požadavku (Amazon Web Services, Inc, 2021a). Tedy pokud chceme změnit uživatele a nějaké položky, funkce by zavolala na brány určené pro uživatele a položky, které by poté určili, který kód v jim podřízených funkcí se spustí podle zadaných parametrů.
Obr 3 Ilustrace API Gateway s více API bránou pro každou sekci funkcí (vlastní tvorba)
Druhý nabízený vzor je vytvoření jedné velké brány, která má na starost všechny funkce.
V tomto případě by tedy funkce zavolala na bránu s příkazem o uživateli a položce, dále by byly touto bránou spuštěny funkce zodpovědné za akce nad těmito modely (Likness, 2020) (Daly, 2018).
Obr 4 Ilustrace vzoru ve verzi s jednou API bránou (vlastní tvorba)
Hlavním rozdílem mezi těmito vzory je tedy to, kde je nastaveno, kdo se stará o spuštění nutných funkcí. V prvním případě se o to stará samotná funkce. Zatímco v případě druhém je tato logika přenesena na bránu, která následně určí podle zadaných parametrů, která funkce má být spuštěna.
Periodic Invoker (Časovač)
[(Pekkala, 2019), (Hong, Srivastava, Shambrook, & Dumitras, 2018), (Amazon Web Services, Inc, 2021)]
Motivace: Spustit funkci v pravidelném intervalu
Řešení: Tento vzor funguje na podobném principu jako „Správce události“, ovšem namísto čekání na oznámení o události, o změně dat či podobné akci se spustí předem definovaný interval pomocí jiné služby v ekosystému. Toto je jedna z nejzákladnějších služeb, kterou podporují všichni hlavní poskytovatelé (Azure Scheduler, AWS CloudWatch Events a Google Cloud Scheduler).
Možnosti nastavení této služby jsou buďto časový interval, tedy například 5 minut, jako v případě dříve zmíněného Ohřívače funkcí nebo je nastaveno datum, například vždy první den v měsíci (Amazon Web Services, Inc, 2021).
Časovač může také působit jako základní prvek pro jiné, složitější vzory. Využívá se především pro zálohování, čistění databáze a další nenáročné služby. Také na něm staví některé další návrhové vzory, jako například „Dotazník na změny“.
Polling Event Processor (Dotazník na změny) Zdroje: [(Pekkala, 2019)]
Motivace: Chceme provést akci při změně stavu, ovšem služba nevytváří události
Řešení: Podobně jako u Časovače i zde se jedná o akci prováděnou v předem daném časovém intervalu. Na rozdíl od dříve zmíněného Správce události tak služby, na které je napojen Dotazník neumí vytvořit událost. Jedná se tedy především o aplikace třetích stran či zastaralé služby (Pekkala, 2019).
Vzniklý problém tedy řešíme kombinací Správce události, Časovače a Externího stavu.
Událost, na kterou funkce čeká, ovšem neobsahuje informace o tom, co se změnilo, pouze oznámuje, že se má funkce spustit. Funkce po spuštění zašle požadavek napojeným službám, u kterých zažádá o současná data, pokud to lze. Poté získá data na své straně, která jsou uložena v externím úložišti a porovná tyto verze mezi sebou. Pokud zjistí, že se data liší v námi nadefinován způsobu, spustí kód, buďto ve stejné funkci nebo odešle zjištěné informace na navazující funkci. Naopak, pokud se zjistí, že se data neliší, funkce pouze vytvoří záznam o svém průběhu, oznámí, k jakému závěru došla a ukončí se (Pekkala, 2019).
Dotazník je využíván spíše z nutnosti než z důvodu velkých výhod. Oproti dotazování na tato data pokaždé, kdy je nutno je využít, má Dotazník stále určité výhody a ušetří čas a peníze.
Problémem vzoru jsou ovšem ta spuštění, kdy žádná změna nenastala, a tudíž vzniká výpočetní čas, za který sice platíme, ovšem běží na prázdno. V případě že Dotazník ještě neprovedl svůj cyklus, může se stát, že funkce proběhne se zastaralými daty.
Aggregator (Agregátor)
Zdroje: [(Pekkala, 2019), (Daly, 2018), (Likness, 2020), (Abbott, 2020)]
Motivace: Potřeba využití více dat z více služeb Řešení: Spojení více koncových bodů do jedné funkce
U dnešních aplikací je velmi běžné, a to ať už díky popularitě mikroslužeb či velkému množství aplikací třetích stran, že klient pro správný průběh svého kódu potřebuje získat nutné informace z několik různých API. Jako příklad lze využít situaci, kdy se uživatel snaží získat data o poloze, počasí a čase k danému místu (Pekkala, 2019).
Namísto toho, aby klient vytvořil 3 dotazy na různá místa, vytvoří se jeden koncový bod, který tato data získá, zpracuje a odešle nazpět uživateli (Daly, 2018). Tímto docílíme menší
náročnosti klienta a přesune se odpovědnost z jeho strany na stranu serveru, v tomto případě funkce.
Výhodou tohoto vzoru je zjednodušení komunikace mezi jednotlivými prvky služby, snížení náročnosti pro klientskou stranu a zrychlení vývoje. Naopak problémem může být delší doba získávání dat z důvodu přidání dotazu a zvýšení šance náchylnosti na chyby (Abbott, 2020). Tento vzor by bylo možné zařadit pod charakteristiku zabývající se zpožděním díky tomu, že tento přístup získá data zpravidla rychleji než mnoho dotazů na straně klienta.
Router (Řadič)
Zdroje: [(Taibi et al., 2020), (Daly, 2018)]
Motivace: Jednoduchá rozřazení podle obdržených dat
Řešení: Na rozdíl od Agregátoru, který volá všechny na něj napojené funkce, Řadič podle informací v dotazu spustí jen ty funkce, které splňují kritéria. Tento vzor by se dal přirovnat k níže zmíněnému Stavovému stroji, který tvoří podobná řešení, ovšem je schopný přehledněji zorchestrovat mnohem složitější akce. Proto se Řadič využívá především u jednodušších požadavků, u kterých by se nevyplatilo vynakládat prostředky za služby typu AWS Step Fuctions, které jsou schopny řídit složitější pracovní postupy (Taibi et al., 2020).
„O Řadiči by se dalo říct, že je to glorifikovaný Switch“ (Daly, 2018). Z dat, které Řadič získá z dotazu způsobených událostí, se Řadič rozhodne, kterou z na něj připojených funkcí zavolá a spustí její kód. Pokud má původní dotaz dostat odpověď, vzniká z důvodu dvojího placení problém, protože funkce Řadiče čeká na odpověď, a tudíž se platí za provoz funkce (Taibi et al., 2020).
Proxy (Proxy)
Zdroje: [(Alexander Shvets, 2021), (Pekkala, 2019), (Microsoft, 2017)]
Motivace: Využití starší služby v nové aplikaci
Řešení: Proxy, někdy také „Protikorupční vrstva“, pomáhá udržet konzistentní způsob dotazování a typu dat, který klient využívá v případě, kdy aplikace potřebuje tyto informace získat ze starší služby, a to ať už je migrace plánovaná či se jedná o zastaralou aplikaci třetí strany. V některých případech je zapotřebí využít aplikací u kterých je možné, že se jejich styl dotazování, typ odpovědí či obojí bude lišit se zbytkem aplikace (Pekkala, 2019). Je tedy zapotřebí vytvořit právě Proxy, která se stará o tento problém, zajišťuje tak konzistentní způsob dotazování a dat skrz celou aplikaci.
Pokud řešíme tento problém tímto způsobem, lze dosáhnout potenciálního zrychlení vývoje díky konzistenci dat a dotazů. Vzor samotný se skládá pouze z jedné funkce, která naslouchá požadavku od aplikace, funkce poté přetvoří požadavek do formátu kompatibilního se starší
službou. Proxy následně vyčká na odpověď, kterou přetvoří na formát odpovídající modernější aplikaci a odešle je nazpět.
Problémem je poté zvýšení doby, za kterou aplikace získá dotazovaná data, dále také nutnost vytvoření nové služby, kterou je zapotřebí udržovat a kontrolovat kvůli chybám (Microsoft, 2017). Tento vzor se dá využít v kombinaci s dalšími, například s API správcem, Řadičem atd.
2.3.5 Bezstavové a pomíjející
Na rozdíl od běžných aplikací neumí FaaS uchovávat stav, který se může měnit například podle výsledku předchozí invokace funkce. Ve skutečnosti je možné, že si funkce zachová tento stav pouze po dobu, kdy bude teplá, tudíž se na to nelze spoléhat a FaaS funkce se berou jako bezstavové právě kvůli jejich pomíjivosti (Roberts 2018).
V praxi to znamená, že je standardem ukládat stav, který se může měnit, do externích uložišť, a to ať už je se jedná o počet předchozích zavolání či o výsledek posledního průběhu funkce. Právě protože není možné se spolehnout na to, kdy dojde k vypnutí kontejneru s funkcí a stav je posléze uveden do původního stavu, jako kdyby došlo k inicializaci funkce poprvé.
Tato část je věnována představení různých způsobů, jakými je možné přizpůsobit aplikaci limitům FaaS technologie z pohledu stavu a pomíjivosti.
Externalized State (Externí stav)
Zdroje: [(Pekkala, 2019), (Amazon Web Services, Inc 2019), (Chowhan 2018), (Roberts 2018)]
Motivace: Chceme uložit stav/data, která se mohou měnit po použití funkce
Řešení: Asi nejzákladnějším způsobem, jakým lze vyřešit problém, je napojení funkce na databázi či úložiště souborů. Jednou z možností, jak toho docílit, je například řešení od AWS a jejich Lambda funkce. Zde lze jednoduše číst a přepisovat v souboru uložený stav v S3 za pomoci přidělení oprávnění pro tuto funkci. Lambda funkce jako takové mají předinstalované AWS SDK, díky kterému lze tohoto jednoduše dosáhnout (Amazon Web Services, Inc 2019).
Ovšem díky připojení dalších služeb k funkci se může dojít ke zpomalení, tudíž navýšení ceny průběhu funkce. Je tedy důležité využívat tohoto vzoru pouze u funkcí, kde je zapotřebí mít stav uložený.
