• Nebyly nalezeny žádné výsledky

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í.