Serverless není o fyzické absenci serverů. Toto není zabiják kontejnerů ani přechodný trend. Jedná se o nový přístup k budování systémů v cloudu. V dnešním článku se dotkneme architektury bezserverových aplikací, podívejme se, jakou roli hraje poskytovatel bezserverových služeb a open-source projekty. Nakonec si promluvme o problémech používání Serverless.
Chci napsat serverovou část aplikace (nebo dokonce internetový obchod). Může to být chat, služba publikování obsahu nebo nástroj pro vyrovnávání zatížení. V každém případě bude spousta starostí: budete muset připravit infrastrukturu, určit závislosti aplikací a přemýšlet o hostitelském operačním systému. Poté budete muset aktualizovat malé součásti, které neovlivňují provoz zbytku monolitu. No, nezapomeňme na škálování při zátěži.
Co když vezmeme efemérní kontejnery, ve kterých jsou již předinstalované požadované závislosti a kontejnery samotné jsou izolovány od sebe navzájem a od hostitelského OS? Monolit rozdělíme na mikroslužby, z nichž každou lze aktualizovat a škálovat nezávisle na ostatních. Umístěním kódu do takového kontejneru jej mohu spustit na jakékoli infrastruktuře. Už lepší.
Co když nechcete konfigurovat kontejnery? Nechci přemýšlet o škálování aplikace. Nechci platit za nečinné běžící kontejnery, když je zatížení služby minimální. Chci napsat kód. Zaměřte se na obchodní logiku a uvádějte produkty na trh rychlostí světla.
Takové myšlenky mě přivedly k počítačům bez serveru. Bez serveru v tomto případě znamená ne fyzická absence serverů, ale absence starostí se správou infrastruktury.
Myšlenka je taková, že aplikační logika je rozdělena do nezávislých funkcí. Mají strukturu událostí. Každá funkce provádí jeden „mikroúkol“. Vše, co potřebuje vývojář, je načíst funkce do konzole poskytnuté poskytovatelem cloudu a dát je do vzájemného vztahu se zdroji událostí. Kód bude na požádání spuštěn v automaticky připraveném kontejneru a já zaplatím pouze dobu provedení.
Pojďme se podívat, jak bude nyní vypadat proces vývoje aplikace.
Ze strany developera
Již dříve jsme se začali bavit o aplikaci pro internetový obchod. V tradičním přístupu je hlavní logika systému prováděna monolitickou aplikací. A server s aplikací běží neustále, i když není zátěž.
Abychom mohli přejít na bezserverové, rozdělíme aplikaci na mikroúlohy. Pro každý z nich napíšeme vlastní funkci. Funkce jsou na sobě nezávislé a neukládají stavové informace (bezstavové). Mohou být dokonce napsány v různých jazycích. Pokud jeden z nich „spadne“, celá aplikace se nezastaví. Architektura aplikace bude vypadat takto:
Rozdělení do funkcí v Serverless je podobné práci s mikroslužbami. Mikroslužba však může provádět několik úkolů a funkce by v ideálním případě měla provádět jeden. Představme si, že úkolem je shromažďovat statistiky a zobrazovat je na žádost uživatele. V přístupu mikroslužby je úkol prováděn jednou službou se dvěma vstupními body: zápisem a čtením. V bezserverovém počítání to budou dvě různé funkce, které spolu nesouvisí. Vývojář šetří výpočetní zdroje, pokud se například statistiky aktualizují častěji, než se stahují.
Bezserverové funkce musí být provedeny v krátkém časovém úseku (timeout), který určuje poskytovatel služby. Například pro AWS je časový limit 15 minut. To znamená, že dlouhodobé funkce budou muset být změněny tak, aby vyhovovaly požadavkům – to je to, co odlišuje Serverless od jiných dnes populárních technologií (kontejnery a Platform as a Service).
Každé funkci přiřadíme událost. Událost je spouštěčem akce:
Událost
Akce, kterou funkce provádí
Obrázek produktu byl nahrán do úložiště.
Zkomprimujte obrázek a nahrajte do adresáře
Adresa fyzického úložiště byla v databázi aktualizována
Načtěte nové místo do map
Zákazník platí za zboží
Spusťte zpracování platby
Události mohou být požadavky HTTP, datové proudy dat, fronty zpráv a tak dále. Zdroje událostí jsou změny nebo výskyty dat. Kromě toho lze funkce spouštět časovačem.
Architektura byla propracována a aplikace se téměř stala bez serveru. Dále přejdeme k poskytovateli služeb.
Ze strany poskytovatele
Poskytovatelé cloudových služeb obvykle nabízejí výpočetní techniku bez serveru. Jmenují se jinak: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
Službu budeme používat prostřednictvím konzole poskytovatele nebo osobního účtu. Funkční kód lze stáhnout jedním z následujících způsobů:
- psát kód ve vestavěných editorech přes webovou konzoli,
- stáhněte si archiv s kódem,
- pracovat s veřejnými nebo soukromými git repozitáři.
Zde nastavíme události, které funkci volají. Sady událostí se mohou u různých poskytovatelů lišit.
Poskytovatel vybudoval a zautomatizoval systém Function as a Service (FaaS) na své infrastruktuře:
- Funkční kód skončí v úložišti na straně poskytovatele.
- Když dojde k události, kontejnery s připraveným prostředím se automaticky nasadí na server. Každá instance funkce má svůj vlastní izolovaný kontejner.
- Z úložiště je funkce odeslána do kontejneru, vypočítána a vrátí výsledek.
- Roste počet paralelních akcí – roste počet kontejnerů. Systém se automaticky přizpůsobí. Pokud uživatelé k funkci nemají přístup, bude neaktivní.
- Poskytovatel nastavuje pro kontejnery dobu nečinnosti - pokud se během této doby v kontejneru neobjeví funkce, je zničen.
Tímto způsobem dostaneme Serverless z krabice. Službu budeme platit v průběžném modelu a pouze za ty funkce, které jsou využívány, a to pouze po dobu, kdy byly využívány.
Aby poskytovatelé službu seznámili se službou, nabízejí až 12 měsíců bezplatného testování, ale omezují celkovou dobu výpočtu, počet požadavků za měsíc, finanční prostředky nebo spotřebu energie.
Hlavní výhodou spolupráce s poskytovatelem je možnost nestarat se o infrastrukturu (servery, virtuální stroje, kontejnery). Poskytovatel může implementovat FaaS jak pomocí vlastního vývoje, tak pomocí open-source nástrojů. Promluvme si o nich dále.
Ze strany open source
Open-source komunita již několik let aktivně pracuje na bezserverových nástrojích. Největší hráči na trhu také přispívají k rozvoji platforem bez serveru:
- Google nabízí vývojářům svůj open-source nástroj - . Na jeho vývoji se podílely IBM, RedHat, Pivotal a SAP;
- IBM pracoval na platformě Serverless , který se pak stal projektem nadace Apache;
- Microsoft částečně otevřel kód nástupiště .
Vývoj probíhá také směrem k bezserverovým frameworkům. и nasazené v předem připravených clusterech Kubernetes, funguje s Kubernetes i Docker Swarm. Framework funguje jako jakýsi kontrolér – na požádání připraví běhové prostředí uvnitř clusteru a následně tam spustí funkci.
Rámce ponechávají prostor pro konfiguraci nástroje tak, aby vyhovoval vašim potřebám. Takže v Kubeless může vývojář nakonfigurovat časový limit provádění funkce (výchozí hodnota je 180 sekund). Fission ve snaze vyřešit problém se studeným startem navrhuje ponechat některé kontejnery v chodu po celou dobu (ačkoli to s sebou nese náklady na výpadky zdrojů). A OpenFaaS nabízí sadu spouštěčů pro každý vkus a barvu: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NAT a další.
Pokyny pro začátek naleznete v oficiální dokumentaci rámců. Práce s nimi vyžaduje trochu více dovedností než při práci s poskytovatelem – to je alespoň možnost spustit cluster Kubernetes přes CLI. Maximálně zahrňte další open-source nástroje (například správce front Kafka).
Bez ohledu na to, jak pracujeme s Serverless – prostřednictvím poskytovatele nebo pomocí open-source, získáme řadu výhod a nevýhod přístupu Serverless.
Z pohledu výhod a nevýhod
Serverless rozvíjí myšlenky kontejnerové infrastruktury a přístupu mikroslužeb, ve kterém mohou týmy pracovat ve vícejazyčném režimu, aniž by byly vázány na jednu platformu. Sestavení systému je zjednodušené a chyby se snáze opravují. Architektura mikroservisů umožňuje přidávat nové funkce do systému mnohem rychleji než v případě monolitické aplikace.
Serverless ještě více zkracuje dobu vývoje, umožňuje vývojáři soustředit se pouze na obchodní logiku a kódování aplikace. V důsledku toho se zkracuje doba uvedení vývoje na trh.
Jako bonus získáme automatické škálování pro zatížení, a platíme pouze za použité zdroje a pouze v době, kdy jsou využívány.
Jako každá technologie má i Serverless nevýhody.
Takovou nevýhodou může být například doba studeného startu (v průměru do 1 sekundy u jazyků jako JavaScript, Python, Go, Java, Ruby).
Na jedné straně ve skutečnosti čas studeného startu závisí na mnoha proměnných: jazyce, ve kterém je funkce napsána, počtu knihoven, množství kódu, komunikaci s dalšími zdroji (stejné databáze nebo autentizační servery). Protože vývojář řídí tyto proměnné, může zkrátit dobu spuštění. Ale na druhou stranu vývojář nemůže kontrolovat dobu spuštění kontejneru – vše záleží na poskytovateli.
Studený start se může změnit na teplý start, když funkce znovu použije kontejner spuštěný předchozí událostí. Tato situace nastane ve třech případech:
- pokud klienti často využívají službu a zvyšuje se počet volání do funkce;
- pokud vám poskytovatel, platforma nebo framework umožňuje udržovat některé kontejnery neustále v chodu;
- pokud vývojář spouští funkce na časovači (řekněme každé 3 minuty).
Pro mnoho aplikací není studený start problém. Zde je třeba vycházet z typu a úkolů služby. Sekundové zpoždění startu není vždy kritické pro obchodní aplikaci, ale může se stát kritickým pro lékařské služby. V tomto případě již pravděpodobně nebude vhodný přístup bez serveru.
Další nevýhodou Serverless je krátká životnost funkce (timeout, během kterého musí být funkce provedena).
Pokud však musíte pracovat s dlouhodobými úkoly, můžete použít hybridní architekturu – kombinovat Serverless s jinou technologií.
Ne všechny systémy budou schopny pracovat pomocí schématu Serverless.
Některé aplikace budou stále ukládat data a stav během provádění. Některé architektury zůstanou monolitické a některé prvky budou mít dlouhou životnost. Nicméně (stejně jako cloudové technologie a poté kontejnery) je Serverless technologií s velkou budoucností.
V tomto duchu bych rád plynule přešel k problematice používání bezserverového přístupu.
Ze strany aplikace
Pro rok 2018 procento využití bez serveru . Mezi společnosti, které již technologii implementovaly do svých služeb, jsou takoví tržní giganti jako Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. Zároveň musíte pochopit, že Serverless není všelék, ale nástroj pro řešení určité řady problémů:
- Snižte prostoje zdrojů. Není potřeba neustále udržovat virtuální stroj pro služby, které mají málo volání.
- Zpracovávat data za chodu. Komprimujte obrázky, vystřihujte pozadí, změňte kódování videa, pracujte se senzory IoT, provádějte matematické operace.
- „Slepte“ další služby dohromady. Git úložiště s interními programy, chatovací bot ve Slacku s Jirou a kalendář.
- Vyrovnejte zátěž. Podívejme se zde blíže.
Řekněme, že existuje služba, která přiláká 50 lidí. Pod ním je virtuální stroj se slabým hardwarem. Čas od času se zatížení služby výrazně zvyšuje. Slabý hardware si pak nemůže poradit.
Do systému můžete zahrnout balancer, který rozloží zátěž, řekněme, mezi tři virtuální stroje. V této fázi nemůžeme přesně předvídat zatížení, takže určité množství zdrojů necháváme běžet „v záloze“. A přeplácíme výpadky.
V takové situaci můžeme optimalizovat systém hybridním přístupem: necháme jeden virtuální stroj za load balancerem a vložíme odkaz na Serverless Endpoint s funkcemi. Pokud zatížení překročí práh, balancer spustí instance funkcí, které převezmou část zpracování požadavku.
Serverless tak lze využít tam, kde je potřeba zpracovávat velké množství požadavků ne příliš často, ale intenzivně. V tomto případě je provozování několika funkcí po dobu 15 minut výnosnější než neustálá údržba virtuálního stroje nebo serveru.
Se všemi výhodami bezserverového počítání byste před implementací měli nejprve vyhodnotit aplikační logiku a pochopit, jaké problémy může Serverless v konkrétním případě vyřešit.
Serverless a Selectel
V Selectel už jsme přes náš ovládací panel. Nyní budujeme vlastní platformu FaaS. Chceme, aby vývojáři byli schopni řešit své problémy pomocí Serverless prostřednictvím pohodlného a flexibilního rozhraní.
Pokud máte nápady, jaká by měla být ideální platforma FaaS a jak chcete Serverless využít ve svých projektech, podělte se o ně v komentářích. Při vývoji platformy zohledníme vaše přání.
Materiály použité v článku:
Zdroj: www.habr.com