Klíčové body
- Už několik let nám slibují, že bezserverové výpočty (serverless) otevřou novou éru bez konkrétního operačního systému pro spuštění aplikací. Říkali nám, že tato struktura vyřeší řadu problémů škálovatelnosti. Ve skutečnosti je vše jinak.
- Ačkoliv mnozí považují bezserverovou technologii za nový koncept, její kořeny sahají až do roku 2006, kdy vznikly Zimki PaaS a Google App Engine — v obou případech je používaná bezserverová architektura.
- Existují čtyři důvody, proč se bezserverová revoluce dostala do slepé uličky: od omezené podpory programovacích jazyků po problémy s výkonem.
- Bezserverové výpočty nejsou zcela zbytečné. Rozhodně ne. Avšak neměly by být považovány za přímou náhradu serverů. Pro některé aplikace mohou být užitečným nástrojem.
Server je mrtvý, ať žije server!
Tak zní bojový pokřik zastánců bezserverové revoluce. Stačí rychle projít oborovými médii posledních několika let a lze snadno dojít k závěru, že tradiční serverový model je mrtvý a že za několik let budeme všichni používat bezserverové architektury.
Jak je každému v oboru známo, a jak jsme také uvedli v našem článku o , to není pravda. Navzdory mnoha článkům o výhodách , se tak nikdy neuskutečnila. Ve skutečnosti , že tato revoluce se pravděpodobně dostala do slepé uličky.
Některé z slibů pro bezserverové modely byly bezesporu naplněny, ale ne všechny. V žádném případě ne všechny.
V tomto článku chci prozkoumat příčiny tohoto stavu. Proč nedostatek flexibility bezserverových modelů stále představuje překážku jejich širšímu přijetí, ačkoliv zůstávají užitečné v konkrétních, jasně definovaných okolnostech.
Co slibovali zastánci bezserverových výpočtů
Než se dostaneme k problémům bezserverových výpočtů, podívejme se, co měly zaručit. byly četné a — občas — velmi ambiciózní.
Pro ty, kteří nejsou obeznámeni s tímto termínem, zde je stručné definování. Serverless computing vymezuje architekturu, v níž aplikace (nebo části aplikací) běží na vyžádání v runtime prostředích, která jsou obvykle hostována vzdáleně. Kromě toho lze serverless systémy hostovat i lokálně. V posledních několika letech bylo vytváření udržitelných serverless systémů hlavní starostí systémových administrátorů a SaaS společností, neboť (jak se tvrdí) tato architektura nabízí řadu klíčových výhod ve srovnání s "tradiční" klient-server modelem:
- Serverless modely nevyžadují, aby uživatelé udržovali vlastní operační systémy nebo dokonce vyvíjeli aplikace kompatibilní s konkrétními OS. Místo toho vývojáři vytvářejí sdílený kód, nahrávají ho na serverless platformu a sledují jeho provádění.
- Zdroje v serverless rámcích se obvykle účtují na minuty (nebo dokonce sekundy). To znamená, že zákazníci platí pouze za dobu, kdy je kód skutečně spuštěn. To se zásadně odlišuje od tradičních cloudových VM, kde stroj většinu času nepracuje, ale za něj je nutné platit.
- Problém škálovatelnosti byl také vyřešen. Zdroje v serverless rámcích se přiřazují dynamicky, takže systém snadno zvládá náhlé výkyvy poptávky.
Zkrátka, serverless modely poskytují flexibilní, levná a škálovatelná řešení. Je překvapující, že nás tato myšlenka nenapadla dříve.
Je to opravdu nová myšlenka?
Ve skutečnosti tato myšlenka není nová. Koncept, který umožňuje uživatelům platit pouze za dobu, kdy je kód skutečně spuštěn, existuje od té doby, co byl zaveden v rámci v roce 2006, a přibližně ve stejné době Google App Engine nabídl velmi podobné řešení.
Ve skutečnosti to, co nyní nazýváme "serverless" modelem, je starší než mnohé technologie, které se nyní nazývají "nativními cloudovými", a které poskytují téměř totéž. Jak bylo již zmíněno, serverless modely jsou v podstatě pouze pokračováním obchodního modelu SaaS, který existuje již několik desetiletí.
Je třeba také uznat, že bezserverový model není architekturou FaaS, i když mezi nimi existuje spojení. FaaS je v podstatě část bezserverové architektury zaměřená na výpočty, ale nepředstavuje celý systém jako celek.
Jaký je tedy důvod této vřavy? Nuže, jak se rychlost penetrace internetu v rozvojových zemích rychle zvyšuje, zároveň vzrůstá poptávka po výpočetních zdrojích. Například v mnoha zemích s rychle rostoucími sektory elektronického obchodování prostě neexistuje výpočetní infrastruktura pro aplikace na těchto platformách. A to je místo, kde se objevují placené bezserverové platformy.
Problémy bezserverových modelů
Problém je v tom, že bezserverové modely mají... problémy. Nechápejte mě špatně: neříkám, že jsou samy o sobě špatné nebo že nenabízí významnou hodnotu pro některé společnosti za určitých okolností. Ale hlavní tvrzení o 'revoluci' - že bezserverová architektura rychle nahradí tradiční - se nikdy neuskuteční.
Tady je důvod.
Omezená podpora programovacích jazyků
Většina bezserverových platforem umožňuje spouštět pouze ty aplikace, které jsou napsány v určitých jazycích. To vážně omezuje flexibilitu a přizpůsobivost těchto systémů.
Předpokládá se, že bezserverové platformy podporují většinu hlavních jazyků. AWS Lambda a Azure Functions také poskytují obal pro spuštění aplikací a funkcí v nepodporovaných jazycích, i když to často s sebou nese náklady na výkon. Takže pro většinu organizací toto omezení obvykle nemá velký význam. Ale tady je háček. Předpokládá se, že jednou z výhod bezserverových modelů je, že málo známé, zřídka používané programy lze využívat levněji, protože platíte pouze za dobu jejich běhu. A málo známé, zřídka používané programy jsou často psány v... málo známých, zřídka používaných programovacích jazycích.
To podkopává jednu z klíčových výhod bezserverového modelu.
Vazba na dodavatele
Druhým problémem bezserverových platforem, nebo spíše tím, jak jsou v současnosti realizovány, je, že se obvykle na úrovni operací výrazně liší. Prakticky neexistuje standardizace v oblasti psaní funkcí, nasazení a správy. To znamená, že migrace funkcí z jedné platformy na druhou zabere nesmírně mnoho času.
Nejtěžší částí přechodu na bezserverový model nejsou výpočetní funkce, které obvykle představují jen kódové fragmenty, ale to, jak jsou aplikace propojeny s připojenými systémy, jako je úložiště objektů, správa identit a fronty. Funkce lze přesunout, ale zbytek aplikace nelze. To je naprostý opak slibovaných levných a flexibilních platforem.
Někteří tvrdí, že bezserverové modely se objevily nedávno a nebyl čas na jejich standardizaci. Ale jak jsem již uvedl, nejsou tak nové a mnoho dalších cloudových technologií, jako jsou kontejnery, se již stalo mnohem uživatelsky přívětivější díky vypracování a širokému přijetí dobrých standardů.
Výkon
Výpočetní výkon bezserverových platforem se těžko měří, částečně proto, že dodavatelé snahují udržet informace v tajnosti. Většina tvrdí, že funkce na vzdálených bezserverových platformách fungují stejně rychle jako na interních serverech, s výjimkou několika nevyhnutelných problémů s latencí.
Nicméně jednotlivé fakty svědčí o opaku. Funkce, které nebyly dříve spuštěny na určité platformě nebo nebyly spuštěny nějakou dobu, vyžadují určitou dobu na inicializaci. To pravděpodobně souvisí s tím, že byl jejich kód převeden na nějaké méně dostupné médium, i když – podobně jako u benchmarků – většina dodavatelů vám o převodu dat neřekne.
Samozřejmě existuje několik způsobů, jak to obejít. Jeden z nich spočívá v optimalizaci funkcí pro jakýkoli cloudový jazyk, na kterém vaše bezserverová platforma běží, ale to poněkud podkopává tvrzení, že tyto platformy jsou „flexibilní“.
Jiný přístup spočívá v zajištění pravidelného běhu programů, které jsou kritické pro výkon, aby zůstaly "čerstvé". Tento druhý přístup je samozřejmě poněkud v rozporu s tvrzením, že bezserverové platformy jsou ekonomičtější, protože platíte pouze za dobu provozu vašich programů. Cloudoví poskytovatelé zavedli nové způsoby, jak zkrátit studené starty, ale mnohé z nich vyžadují "škálování na jednu" (scale to one), což oslabuje původní hodnotu FaaS.
Problém "studeného startu" lze částečně vyřešit spuštěním bezserverových systémů vlastními silami, ale to je spojeno s vlastními náklady a zůstává to okrajovou možností pro dobře zásobené týmy.
Nemůžete spouštět celé aplikace
Nakonec možná nejdůležitější důvod, proč bezserverové architektury v blízké době nenahradí tradiční modely: obvykle nelze spouštět celé aplikace.
Přesněji řečeno, není to ekonomické. Váš úspěšný monolit pravděpodobně nestojí za to, abyste ho převáděli na soubor čtyř desítek funkcí propojených osmi bránami, čtyřiceti frontami a tuctem databázových instancí. Z tohoto důvodu je serverless lépe přizpůsobeno novým vývojem. Prakticky žádnou stávající aplikaci (architekturu) nelze přenést. Můžete migrovat, ale budete muset začít od nuly.
To znamená, že ve většině případů jsou bezserverové platformy používány jako doplněk k interním serverům pro plnění úkolů, které vyžadují vysoké výpočetní nároky. To je výrazně odlišuje od dvou dalších forem cloudových technologií – kontejnerů a virtuálních strojů, které nabízejí komplexní způsob vykonávání vzdálených výpočtů. Toto ilustruje jednu z obtíží přechodu od mikroservisů k bezserverovým systémům.
Samozřejmě, že to není vždy problém. Možnost občas využívat obrovské výpočetní zdroje, aniž byste museli kupovat vlastní hardware, může přinést skutečný a dlouhodobý prospěch mnoha organizacím. Ale pokud některé aplikace běží na interních serverech a jiné na bezserverových cloudových architekturách, správa se dostává na novou úroveň složitosti.
Žije revoluce?
I přes všechny tyto stížnosti nemám proti bezserverovým řešením nic jako takovému. Abych byl upřímný. Jen by si vývojáři měli uvědomit - zejména pokud poprvé zkoumají bezserverové modely - že tato technologie není přímou náhradou serverů. Místo toho se seznamte s našimi radami a zdroji pro a rozhodněte se, jak tuto model nejlépe využít.
Zdroj: habr.com
