Klíčové body
- Již několik let je nám slibováno, že bezserverové počítání (bezserverové) otevře novou éru bez specifického OS pro spouštění aplikací. Bylo nám řečeno, že taková struktura by vyřešila spoustu problémů se škálovatelností. Ve skutečnosti je všechno jinak.
- Ačkoli mnozí považují technologii bez serveru za novou myšlenku, její kořeny lze vysledovat až do roku 2006 se Zimki PaaS a Google App Engine, které oba používají architekturu bez serveru.
- Existují čtyři důvody, proč se revoluce bez serveru zastavila, od omezené podpory programovacích jazyků po problémy s výkonem.
- Počítání bez serveru není tak zbytečné. Daleko od toho. Neměly by však 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!
Toto je bojový pokřik přívrženců revoluce bez serveru. Letmý pohled do průmyslového tisku za posledních několik let stačí k závěru, že tradiční serverový model je mrtvý a že za pár let budeme všichni používat bezserverové architektury.
Jak každý v oboru ví a jak jsme také poukázali v našem článku o , to je špatně. Navzdory mnoha článkům o zásluhách , to se nikdy nekonalo. Ve skutečnosti, že tato revoluce možná dospěla do slepé uličky.
Některé ze slibů pro modely bez serveru se jistě splnily, ale ne všechny. Ne všichni.
V tomto článku se chci zamyslet nad důvody tohoto stavu. Proč je nedostatečná flexibilita bezserverových modelů stále překážkou jejich širšímu přijetí, ačkoli zůstávají užitečné za specifických, dobře definovaných okolností.
Co slibovali adepti bezserverového počítání
Než přejdeme k problémům bezserverových počítačů, podívejme se, co musely poskytnout. bylo mnoho a – občas – velmi ambiciózní.
Pro ty, kteří tento pojem neznají, je zde stručná definice. Bezserverové výpočty definují architekturu, ve které aplikace (nebo části aplikací) běží na vyžádání v běhových prostředích, která jsou obvykle vzdáleně hostována. Kromě toho mohou být hostovány systémy bez serveru. Budování robustních bezserverových systémů bylo hlavním zájmem systémových administrátorů a společností SaaS v posledních několika letech, protože (jak se tvrdí) tato architektura nabízí několik klíčových výhod oproti „tradičnímu“ modelu klient/server:
- Modely bez serveru nevyžadují, aby si uživatelé udržovali své vlastní operační systémy nebo dokonce vytvářeli aplikace, které jsou kompatibilní s konkrétními operačními systémy. Místo toho vývojáři vytvářejí sdílený kód, nahrávají jej na platformu bez serveru a sledují, jak běží.
- Prostředky v bezserverových frameworkech jsou obvykle účtovány po minutách (nebo dokonce sekundách). To znamená, že klienti platí pouze za dobu, po kterou kód skutečně spouštějí. To je příznivé ve srovnání s tradičním cloudovým VM, kde je stroj většinu času nečinný, ale musíte za to zaplatit.
- Byl také vyřešen problém škálovatelnosti. Prostředky v bezserverových rámcích jsou přidělovány dynamicky, takže systém se může snadno vypořádat s náhlými výkyvy poptávky.
Stručně řečeno, modely bez serveru poskytují flexibilní, nízkonákladová a škálovatelná řešení. Divím se, že nás tato myšlenka nenapadla dříve.
Je to opravdu nový nápad?
Ve skutečnosti myšlenka není nová. Koncept umožňující uživatelům platit pouze za dobu, po kterou kód skutečně běží, existuje již od doby, kdy byl představen v rámci v roce 2006 a přibližně ve stejné době přišel s velmi podobným řešením Google App Engine.
To, co nyní nazýváme „bezserverovým“ modelem, je ve skutečnosti starší než mnoho technologií, které se nyní nazývají „cloudové nativní“, které poskytují téměř totéž. Jak již bylo uvedeno, modely bez serveru jsou v podstatě jen rozšířením obchodního modelu SaaS, který existuje již desítky let.
Také stojí za to si uvědomit, že model bez serveru není architektura FaaS, i když mezi nimi existuje spojení. FaaS je v podstatě výpočetně orientovaná část architektury bez serveru, ale nepředstavuje celý systém.
Tak proč celý ten humbuk? S tím, jak rychlost penetrace internetu v rozvojových zemích neustále stoupá, roste i poptávka po výpočetních zdrojích. Například mnoho zemí s rychle rostoucími sektory elektronického obchodování jednoduše nemá výpočetní infrastrukturu pro aplikace na těchto platformách. Zde přicházejí na řadu placené platformy bez serveru.
Problémy s modely bez serveru
Háček je v tom, že modely bez serveru mají… problémy. Nechápejte mě špatně: neříkám, že jsou samy o sobě špatné nebo za určitých okolností neposkytují některým společnostem významnou hodnotu. Ale hlavní tvrzení „revoluce“ – že bezserverová architektura rychle nahradí tu tradiční – se nikdy nenaplní.
Proto.
Omezená podpora programovacích jazyků
Většina platforem bez serveru umožňuje spouštění pouze aplikací napsaných v určitých jazycích. To výrazně 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 spouštění aplikací a funkcí v nepodporovaných jazycích, i když to často stojí za výkon. Pro většinu organizací tedy toto omezení obvykle nepředstavuje velký problém. Ale jde o to. Jednou z výhod bezserverových modelů má být to, že obskurní, málo používané programy lze používat levněji, protože platíte pouze za dobu, po kterou běží. A obskurní, zřídka používané programy jsou často napsány v... nejasných, zřídka používaných programovacích jazycích.
To podkopává jednu z klíčových výhod modelu bez serveru.
Vazba na prodejce
Druhým problémem bezserverových platforem, nebo alespoň způsobu jejich současné implementace, je to, že na provozní úrovni obvykle nevypadají podobně. Neexistuje prakticky žádná standardizace, pokud jde o funkce psaní, nasazení a správu. To znamená, že migrace funkcí z jedné platformy na druhou je extrémně časově náročná.
Nejtěžší částí přechodu na model bez serveru nejsou výpočetní funkce, které jsou obvykle jen úryvky kódu, ale to, jak aplikace komunikují s připojenými systémy, jako je úložiště objektů, správa identit a fronty. Funkce lze přesouvat, ale zbytek aplikace ne. Jde o pravý opak slibovaných levných a flexibilních platforem.
Někteří tvrdí, že modely bez serveru jsou nové a nebyl čas na standardizaci jejich fungování. Ale nejsou tak nové, jak jsem poznamenal výše, a mnoho dalších cloudových technologií, jako jsou kontejnery, se již stalo mnohem pohodlnějšími díky vývoji a širokému přijetí dobrých standardů.
Производительность
Výpočetní výkon bezserverových platforem je obtížné měřit, částečně proto, že prodejci mají tendenci uchovávat informace v tajnosti. Většina tvrdí, že funkce na vzdálených platformách bez serveru běží stejně rychle jako na interních serverech, kromě několika nevyhnutelných problémů s latencí.
Jednotlivá fakta však svědčí o opaku. Funkce, které dříve na konkrétní platformě neběžely nebo neběžely nějakou dobu, bude nějakou dobu trvat, než se inicializují. Je to pravděpodobně způsobeno tím, že jejich kód byl přenesen na nějaké méně dostupné paměťové médium, ačkoli – stejně jako u benchmarků – většina prodejců vám o migraci dat neřekne.
Samozřejmě existuje několik způsobů, jak to obejít. Jedním z nich je optimalizace funkcí pro jakýkoli cloudový jazyk, na kterém vaše platforma bez serveru běží, ale to poněkud podkopává tvrzení, že tyto platformy jsou „agilní“.
Dalším přístupem je zajistit, aby programy kritické z hlediska výkonu běžely pravidelně, aby byly "čerstvé". Tento druhý přístup je samozřejmě trochu v rozporu s tvrzením, že platformy bez serveru jsou nákladově efektivnější, protože platíte pouze za dobu, po kterou běží vaše programy. Poskytovatelé cloudu představili nové způsoby, jak omezit studené starty, ale mnoho z nich vyžaduje „scale to one“ (scale to one), což podkopává původní hodnotu FaaS.
Problém se studeným startem lze částečně vyřešit interním provozováním systémů bez serverů, ale to má své vlastní náklady a zůstává to okrajová možnost pro dobře vybavené týmy.
Nelze spustit celé aplikace
Konečně asi nejdůležitějším důvodem, proč architektury bez serverů v dohledné době nenahradí tradiční modely, je to, že (obecně) nemohou spouštět celé aplikace.
Přesněji řečeno, je to nepraktické z hlediska nákladů. Váš úspěšný monolit by se pravděpodobně neměl proměnit v sadu čtyř tuctů funkcí spojených dohromady osmi branami, čtyřiceti frontami a tuctem databázových instancí. Z tohoto důvodu je pro nový vývoj vhodnější serverless. Prakticky žádnou existující aplikaci (architekturu) nelze přenést. Můžete migrovat, ale musíte začít od nuly.
To znamená, že v naprosté většině případů se bezserverové platformy používají jako doplněk k serverům typu back-end k provádění výpočetně náročných úloh. To se velmi liší od ostatních dvou forem cloud computingu, kontejnerů a virtuálních strojů, které nabízejí holistický způsob, jak provádět vzdálené výpočty. To ilustruje jeden z problémů migrace z mikroslužeb na systémy bez serveru.
Samozřejmě to není vždy problém. Schopnost pravidelně využívat obrovské výpočetní zdroje bez nutnosti kupovat vlastní hardware může mnoha organizacím přinést skutečné a trvalé výhody. Ale když jsou některé aplikace umístěny na interních serverech a jiné na cloudových architekturách bez serverů, správa získává novou úroveň složitosti.
Ať žije revoluce?
Přes všechny tyto stížnosti nejsem proti bezserverovým řešením jako takovým. Upřímně řečeno. Jde jen o to, že vývojáři musí pochopit – zvláště pokud poprvé zkoumají modely bez serveru – že tato technologie není přímou náhradou serverů. Místo toho se podívejte na naše tipy a zdroje na a rozhodnout, jak nejlépe tento model použít.
Zdroj: www.habr.com