I když bezserverové technologie v posledních letech rychle získávají na popularitě, stále s nimi souvisí řada mylných představ a obav. Závislost na dodavateli, nástroje, řízení nákladů, studený start, monitoring a životní cyklus vývoje — to všechno jsou témata, o kterých se aktivně diskutuje, když se hovoří o bezserverových technologiích. V tomto článku prozkoumáme některá z těchto témat a také se podělíme o tipy a odkazy na užitečné informační zdroje, díky nimž si nováčci mohou vytvořit výkonné, flexibilní a ekonomické bezserverové aplikace.
Mylné představy o bezserverových technologiích
Mnozí se domnívají, že bezserverovost a "on-premises" zpracování dat (, FaaS) jsou téměř jedno a totéž. To znamená, že rozdíl není příliš velký a vyplatí se novinku zavést. Ačkoli AWS Lambda byla jednou z „hvězd“ rozkvětu bezserverových technologií a jedním z nejpopulárnějších prvků bezserverové architektury, představuje tato architektura něco víc než jen FaaS.
Hlavním principem bezserverových technologií je, že se nemusíte starat o řízení a škálování infrastruktury, platíte pouze za to, co používáte. Pod tyto kritéria spadá řada služeb — AWS DynamoDB, S3, SNS nebo SQS, Graphcool, Auth0, Now, Netlify, Firebase a mnoho dalších. Obecně platí, že bezserverovost předpokládá využívání všech možností cloudového computingu bez nutnosti správy infrastruktury a její optimalizace pro škálování. To také znamená, že zabezpečení na úrovni infrastruktury už není vaším problémem, což je obrovská výhoda, vzhledem k obtížnosti a složitosti dodržování bezpečnostních standardů. Nakonec není třeba kupovat infrastrukturu, která je vám poskytována do užívání.
Bezserverovost můžeme považovat za „stavu mysli“: určitou mentalitu při navrhování řešení. Vyhněte se přístupům, které vyžadují údržbu jakékoli infrastruktury. Při bezserverovém přístupu trávíme čas řešením úkolů, které přímo ovlivňují projekt a přinášejí prospěch našim uživatelům: budujeme odolnou obchodní logiku, rozvíjíme uživatelské rozhraní a vyvíjíme adaptivní a spolehlivé API.
Například, pokud můžeme vyhnout se správě a údržbě platformy pro svobodné textové vyhledávání, uděláme to. Tento přístup k sestavování aplikací může výrazně urychlit uvedení produktu na trh, neboť se již nemusíte starat o správu složité infrastruktury. zbavte se povinností a nákladů na správu infrastruktury a zaměřte se na vytváření aplikací a služeb, které vaši klienti potřebují. Patrick Debois tento přístup nazval , tento termín byl přijat v bezserverové komunitě. Funkce by měly být považovány za spojovací prvek pro služby ve formě nasazovaných modulů (místo nasazení celé knihovny nebo webové aplikace). To zajišťuje neuvěřitelnou granularitu správy nasazení a změn v aplikaci. Pokud nemůžete tímto způsobem nasazovat funkce, může to znamenat, že funkce vykonávají příliš mnoho úkolů a měly by být refaktorizovány.
Některé uživatele znepokojuje závislost na dodavateli při vývoji cloudových aplikací. Totéž platí i pro serverless technologie, a pravděpodobně to není důsledkem klamné představy. Z našich zkušeností vytváření serverless aplikací na AWS v kombinaci s schopností AWS Lambda integrovat další AWS služby — to vše částečně formuje výhody serverless architektur. Je to dobrý příklad synergie, kdy výsledek spojení je větší než jen součet jednotlivých částí. Snažíte-li se vyhnout závislosti na dodavateli, můžete čelit ještě větším problémům. Při práci s kontejnery je snazší řídit si vlastní úroveň abstrakce mezi cloudovými poskytovateli. Ale když se jedná o serverless řešení, úsilí se nevyplatí, zejména pokud se hned na začátku zohlední ekonomická efektivita. Určitě zjistěte, jak dodavatelé zajišťují poskytování služeb. Některé specializované služby závisí na integračních bodech s jinými dodavateli a mohou umožnit připojení stylem plug-and-play. Snáze je zajištěno volání Lambda z koncové API brány než procházet požadavek do nějakého kontejneru nebo instance EC2. Graphcool poskytuje jednoduchou konfiguraci pomocí Auth0, což je jednodušší než použít externí autentizační nástroje.
Výběr správného dodavatele pro vaši serverless aplikaci je rozhodnutí architektonické úrovně. Při vytváření aplikace neočekáváte, že se jednou vrátíte k řízení serverů. Výběr cloudového dodavatele se neliší od rozhodování o používání kontejnerů, databází nebo dokonce programovacích jazyků.
Zvažte:
- Jaké služby potřebujete a proč.
- Jaké služby poskytují cloudoví poskytovatelé a jak je můžete propojit s vybraným FaaS řešením.
- Jaké programovací jazyky jsou podporovány (s dynamickým nebo statickým typováním, kompilované nebo interpretované, jaké jsou benchmarky, jaká je výkonnost při studeném startu, jaká je open source ekosystém atd.).
- Jaké máte požadavky na bezpečnost (SLA, 2FA, OAuth, HTTPS, SSL atd.).
- Jak spravovat váš CI/CD a cykly vývoje softwaru.
- Jaké výhody můžete čerpat z řešení typu infrastructure-as-code.
Pokud rozšiřujete existující aplikaci a postupně přidáváte bezserverové funkce, může to poněkud omezit dostupné možnosti. Většina bezserverových technologií však poskytuje nějaká API (přes REST nebo zprávové fronty), která umožňují vytvářet rozšíření nezávisle na jádru aplikace s jednoduchou integrací. Hledejte služby s jasnými API, dobrou dokumentací a silnou komunitou, a nešlápnete vedle. Jednoduchost integrace může často být klíčovou metrikou a pravděpodobně je to jeden z hlavních důvodů úspěchu AWS od doby, kdy v roce 2015 byla uvedena Lambda.
Kdy je bezserverovost užitečná
Bezserverové technologie lze používat prakticky všude. Jejich přednosti však nejsou omezeny pouze na způsoby aplikace. Průnikové náklady do cloudového výpočetního prostředí jsou dnes tak nízké právě díky bezserverovým technologiím. Pokud mají vývojáři nápad, ale nevědí, jak spravovat cloudovou infrastrukturu a optimalizovat náklady, nemusí hledat žádného inženýra pro tuto úlohu. Pokud chce startup vytvořit platformu, ale obává se, že náklady mohou vymknout kontrole, může se snadno obrátit na bezserverová řešení.
Díky úsporám nákladů a jednoduchosti škálování jsou bezserverová řešení stejně použitelná pro interní systémy jako pro externí, až po webovou aplikaci s miliony uživatelů. Účty se spíše měří v eurech než v desetnících. Pronájem nejjednoduššího vzoru AWS EC2 (t1.micro) na měsíc vás vyjde na 15 EUR, i když s ním nic neděláte (kdo někdy nezapomněl vypnout?!). Pro srovnání, abyste dosáhli stejného úrovně nákladů za stejné období, musíte spustit Lambda o velikosti 512 MB na 1 sekundu přibližně 3 milionykrát. A pokud tuto funkci nepoužíváte, neplatíte nic.
Jelikož bezserverová technologie závisí především na událostech, lze bezserverovou infrastrukturu relativně snadno přidat do starých systémů. Například pomocí AWS S3, Lambda a Kinesis můžete vytvořit analytickou službu pro starý maloobchodní systém, který bude schopný přijímat data přes API.
Většina bezserverových platforem podporuje různé jazyky. Nejčastěji se jedná o Python, JavaScript, C#, Java a Go. Obvykle neexistují žádná omezení ohledně používání knihoven ve všech jazycích, což znamená, že si můžete použít své oblíbené open source knihovny. Je však žádoucí nepřehánět to se závislostmi, aby vaše funkce pracovaly optimálně a neubíraly výhody ohromné škálovatelnosti vašich bezserverových aplikací. Čím více balíčků je třeba načíst do kontejneru, tím déle trvá studené spuštění.
Studené spuštění nastává, když je potřeba nejprve inicializovat kontejner, provozní prostředí a zpracovatele chyb, než je možné je použít. Z tohoto důvodu může zpoždění vykonání funkcí dosáhnout až 3 sekund, což není ideální pro netrpělivé uživatele. Nicméně studená spuštění se vyskytují při prvním přístupu po několika minutách nečinnosti funkce. Mnozí to považují za nevýznamné nepohodlí, které lze obcházet pravidelným pingováním funkce, aby zůstala v pohotovostním režimu. Nebo tento aspekt vůbec ignorují.
Ačkoli AWS vydala, SQL databáze však pro takové použití nejsou ideální, protože při vykonávání transakcí závisí na připojeních, která se mohou rychle stát úzkým hrdlem při vysoké návštěvnosti na AWS Lambda. Ano, vývojáři neustále vylepšují Serverless Aurora a určitě byste měli experimentovat s ní, nicméně dnes jsou pro bezserverové systémy mnohem lepší NoSQL řešení jako. Nicméně tato situace se určitě brzy změní.
Nástroje také ukládají mnoho omezení, zejména v oblasti místního testování. Ačkoliv existují řešení jako Docker-Lambda, DynamoDB Local a LocalStack, vyžadují pečlivou práci a značné množství konfigurace. Však všechny tyto projekty se aktivně vyvíjejí, takže je to jen otázka času, kdy nástroje dosáhnou požadované úrovně.
Vliv bezserverových technologií na vývojový cyklus
Jelikož vaše infrastruktura představuje pouze konfiguraci, můžete nasadit a rozšířit kód pomocí skriptů, například shell skriptů. Nebo můžete využít řešení typu configuration-as-code, jako je Ačkoli tato služba nenabízí konfiguraci pro všechny oblasti, umožňuje určovat konkrétní zdroje pro použití jako funkce Lambda. To znamená, že tam, kde vás CloudFormation zklame, můžete napsat svůj vlastní zdroj (Lambda funkci), která tuto mezeru vyplní. Tímto způsobem můžete udělat cokoliv, dokonce nakonfigurovat závislosti mimo vaše AWS prostředí.
Jelikož jde pouze o konfiguraci, můžete parametrizovat své nasazovací skripty pro konkrétní prostředí, regiony a uživatele, zejména pokud používáte řešení typu infrastructure-as-code, jako je CloudFormation. Například můžete nasadit kopii infrastruktury pro každou větev v repozitáři, abyste je mohli zcela izolovaně testovat během vývoje. To radikálně zrychluje získávání zpětné vazby od vývojářů, kteří chtějí zjistit, zda jejich kód funguje správně v živém prostředí. Vedoucí pracovníci se nemusí obávat nákladů na nasazení mnoha prostředí, protože se platí pouze za skutečné použití.
DevOps mají méně starostí, protože musejí pouze zajistit, že vývojáři mají správnou konfiguraci. Už není potřeba spravovat instance, vyrovnávače zátěže nebo bezpečnostní skupiny. Proto se stále častěji používá termín NoOps, přičemž je však stále důležité umět konfigurovat infrastrukturu, zejména pokud jde o konfiguraci IAM a optimalizaci cloudových zdrojů.
Existují velmi silné nástroje pro monitorování a vizualizaci, jako jsou Epsagon, Thundra, Dashbird a IOPipe. Tyto nástroje umožňují sledovat aktuální stav serverless aplikací, poskytují protokoly a stopování, zaznamenávají metriky výkonu a úzká místa architektury, provádějí analýzu a predikci nákladů a mnohem více. Nejenže poskytují DevOps inženýrům, vývojářům a architektům komplexní přehled o fungování aplikací, ale také umožňují vedoucím pracovníkům sledovat situaci v reálném čase, s přesnými náklady na zdroje a predikcí nákladů. Organizace takového s řízenou infrastrukturou je mnohem obtížnější.
Navrhování bezserverových aplikací je značně jednodušší, protože není třeba nasazovat webové servery, spravovat virtuální stroje nebo kontejnery, patchovat servery, operační systémy, internetové brány atd. Abstrakce od všech těchto povinností umožňuje bezserverové architektuře soustředit se na to hlavní — na uspokojení potřeb podnikání a zákazníků.
I když nástroje by mohly být lepší (každým dnem se zlepšují), vývojáři se mohou soustředit na implementaci obchodní logiky a optimální rozdělení složitosti aplikace do různých služeb v rámci architektury. Správa bezserverových aplikací probíhá na základě událostí a je abstrahována cloudovým poskytovatelem (např. SQS, S3 události nebo DynamoDB proužky). Vývojáři tedy musí pouze napsat obchodní logiku pro reakci na určité události a nemusí se obávat, jak nejlépe implementovat databáze a fronty zpráv, nebo jak organizovat optimální práci s daty v konkrétních hardwarových úložištích.
Kód lze provádět a ladit lokálně, stejně jako při jakémkoli procesu vývoje. Modální testování zůstává stejné. Možnost nasazení celé infrastruktury aplikace pomocí přizpůsobené konfigurace stacku umožňuje vývojářům rychle získat důležitou zpětnou vazbu, aniž by museli přemýšlet o nákladech na testování nebo o dopadu na nákladná spravovaná prostředí.
Nástroje a metodiky pro sestavení bezserverových aplikací
Neexistuje konkrétní způsob, jak sestavit bezserverové aplikace. Stejně tak neexistuje univerzální sada služeb pro tuto tasku. Dnes je lídrem mezi silnými bezserverovými řešeními AWS, ale věnujte pozornost také , a . Pokud používáte AWS, doporučuji jako přístup k sestavení aplikací (SAM), zejména při použití C#, protože ve Visual Studiu je skvělý nástroj. SAM CLI může dělat to samé, co Visual Studio, takže nic neztratíte, pokud přejdete na jiný IDE nebo textový editor. Samozřejmě, že SAM funguje i s jinými jazyky.
Pokud píšete v jiných jazycích, Serverless Framework je vynikající open source nástroj, který umožňuje nakonfigurovat cokoliv pomocí velmi silných konfiguračních YAML souborů. Serverless Framework také podporuje různé cloudové služby, proto jej doporučujeme těm, kteří hledají vícecloudové řešení. Má ohromnou komunitu, která vytvořila spoustu pluginů pro různé potřeby.
Pro lokální testování se dobře hodí open source nástroje Docker-Lambda, Serverless Local, DynamoDB Local a LocalStack. Besservrové technologie jsou stále v rané fázi vývoje, stejně jako nástroje pro ně, takže při nastavování složitějších testovacích scénářů se budete muset trochu snažit. Nicméně je neuvěřitelně levné jednoduše nasadit stack v prostředí a testovat tam. A není potřeba vytvářet přesnou lokální kopii cloudových prostředí.
Pro snížení velikosti nasazovaných balíčků a zrychlení načítání používejte AWS Lambda Layers.
Používejte správné programovací jazyky pro konkrétní úkoly. Různé jazyky mají své výhody a nevýhody. Existuje mnoho benchmarků, ale JavaScript, Python a C# (.NET Core 2.1+) jsou lídry z hlediska výkonu AWS Lambda. Nedávno se v AWS Lambda objevil Runtime API, který umožňuje specifikovat požadovaný jazyk a prostředí runtime, takže experimentujte.
Udržujte malé velikosti balíčků pro nasazení. Čím menší jsou, tím rychleji se načítají. Vyhněte se používání velkých knihoven, zejména pokud používáte jen pár funkcí. Pokud programujete v JavaScriptu, používejte nástroje pro sestavení jako Webpack, abyste optimalizovali sestavení a zahrnuli pouze to, co skutečně potřebujete. V .NET Core 3.0 jsou QuickJit a Tiered Compilation, které zlepšují výkon a výrazně pomáhají při studených spuštěních.
Závislost bezserverových funkcí na událostech může zpočátku ztížit koordinaci obchodní logiky. V této souvislosti mohou být velmi užitečné zprávové fronty a konečné automaty. Funkce Lambda si mohou vzájemně volat, ale dělejte to pouze v případě, že nečekáte na odpověď („spusťte a zapomeňte“) — přece nechcete platit za čekání na dokončení jiné funkce. Zprávové fronty jsou užitečné pro oddělení částí obchodní logiky, řízení úzkých míst aplikací a zpracování transakcí (pomocí FIFO front). Funkce AWS Lambda mohou být přiřazeny k frontám SQS jako fronty „uvízlých“ zpráv, které sledují neúspěšné zprávy pro následnou analýzu. Funkce AWS Step Functions (konečné automaty) jsou velmi užitečné pro řízení složitých procesů, které vyžadují vytváření řetězců funkcí. Místo toho, aby funkce Lambda volala jinou funkci, mohou Step Functions koordinovat přechody stavů, předávat data mezi funkcemi a řídit globální stav funkcí. To umožňuje definovat podmínky pro opakování pokusů nebo co dělat v případě konkrétní chyby — v určitých podmínkách velmi mocný nástroj.
Závěr
V posledních letech se bezserverové technologie vyvíjejí nebývalým tempem. S touto změnou paradigmatu souvisejí určité mylné představy. Díky abstrahování infrastruktury a řízení škálování nabízejí bezserverová řešení značné výhody: od zjednodušení vývoje a procesů DevOps až po výrazné snížení provozních nákladů.
A i když bezserverový přístup není bez nedostatků, existují spolehlivé metodiky a vzory návrhu, pomocí kterých je možné vytvářet odolné bezserverové aplikace nebo integrovat bezserverové prvky do existujících architektur.
Zdroj: habr.com
