Aj keď bezserverové technológie v posledných rokoch rýchlo získavajú popularitu, stále je s nimi spojených mnoho omylov a obáv. Závislosť od dodávateľa, nástroje, správa nákladov, studené štarty, monitoring a životný cyklus vývoja — tieto témy sa aktívne diskutujú, keď sa hovorí o bezserverových technológiách. V tomto článku sa pozrieme na niektoré z uvedených tém a podelíme sa o rady a odkazy na užitočné zdroje informácií, ktoré pomôžu nováčikom vytvoriť silné, flexibilné a cenovo efektívne bezserverové aplikácie.
Omyl o bezserverových technológiách
Mnohí si myslia, že bezserverové a bezserverové spracovanie údajov (, FaaS) sú takmer to isté. To znamená, že rozdiely nie sú príliš veľké a zaviesť novinku má zmysel. Aj keď AWS Lambda bola jednou z "hviezd" rozkvetu bezserverových technológií a jedným z najpopulárnejších prvkov bezserverovej architektúry, táto architektúra predstavuje niečo viac než len FaaS.
Hlavný princíp bezserverových technológií spočíva v tom, že sa nemusíte starať o správu a škálovanie infraštruktúry, platíte iba za to, čo používate. Pod tieto kritériá patrí množstvo služieb — AWS DynamoDB, S3, SNS alebo SQS, Graphcool, Auth0, Now, Netlify, Firebase a mnoho ďalších. Všeobecne platí, že bezserverovosť znamená využívanie všetkých možností cloud computingu bez nutnosti správy infraštruktúry a jej optimalizácie na účely škálovania. Taktiež to znamená, že bezpečnosť na úrovni infraštruktúry už nie je vašou starosťou, čo je obrovskou výhodou, vzhľadom na zložitosti dodržiavania bezpečnostných štandardov. Nakoniec nemusíte nakupovať infraštruktúru, ktorá vám je poskytovaná na užívanie.
Bezserverovosť sa dá považovať za "stav mysle": určitú mentálnosť pri navrhovaní riešení. Vyhnite sa prístupom, ktoré vyžadujú údržbu akejkoľvek infraštruktúry. Pri bezserverovom prístupe trávime čas riešením úloh, ktoré priamo ovplyvňujú projekt a prinášajú výhody pre našich používateľov: vytvárame robustnú obchodnú logiku, rozvíjame používateľské rozhrania a vyvíjame adaptabilné a spoľahlivé API.
Napríklad, ak je možné vyhnúť sa správe a údržbe platformy pre vyhľadávanie vo voľnom texte, presne tak aj urobíme. Tento prístup k zostavovaniu aplikácií môže výrazne urýchliť uvedenie produktu na trh, pretože už nemusíte myslieť na správu zložitej infraštruktúry. Zbavte sa povinností a nákladov na správu infraštruktúry a sústreďte sa na vytváranie aplikácií a služieb, ktoré vaši zákazníci potrebujú. Patrick Debois nazval tento prístup , tento pojem je prijatý v bezserverovej komunite. Funkcie by sa mali považovať za spojovací článok pre služby vo forme nasaditeľných modulov (namiesto nasadenia celej knižnice alebo webovej aplikácie). To zabezpečuje neuveriteľnú granularitu riadenia nasadenia a zmien v aplikácii. Ak nemôžete takto nasadzovať funkcie, môže to naznačovať, že funkcie vykonávajú príliš veľa úloh a mali by byť refaktorizované.
Niektorých znepokojuje závislosť od dodávateľa pri vývoji cloudových aplikácií. To isté platí aj pre bezserverové technológie, a ťažko povedať, že to je výsledkom mylných predstáv. Podľa našich skúseností je vytváranie bezserverových aplikácií na AWS v kombinácii s možnosťami AWS Lambda spájať iné služby AWS — to všetko do značnej miery formuje výhody bezserverových architektúr. Je to dobrý príklad synergie, kde výsledok spojenia je väčší ako iba súčet jeho častí. Pritom, aby ste sa vyhli závislosti od dodávateľa, môžete naraziť na ešte väčšie problémy. Pri práci s kontajnermi je ľahšie spravovať svoju úroveň abstrakcie medzi cloudovými poskytovateľmi. No keď príde na bezserverové riešenia, úsilie sa nevráti, najmä ak od začiatku zohľadníte ekonomickú efektívnosť. Určite zistite, ako dodávatelia zabezpečujú poskytovanie služieb. Niektoré špecializované služby závisia od integračných bodov s inými dodávateľmi a zvyčajne poskytujú možnosť pripojenia typu plug-and-play. Je jednoduchšie zabezpečiť volanie Lambda z koncového bodu API brány, ako proxy požiadavku do nejakého kontajnera alebo inštancie EC2. Graphcool zabezpečuje jednoduchú konfiguráciu pomocou Auth0, čo je jednoduchšie, než používať externé prostriedky na autentizáciu.
Výber správneho dodávateľa pre vašu bezserverovú aplikáciu je rozhodnutím architektonickej úrovne. Pri vytváraní aplikácie nepredpokladáte, že sa niekedy vrátite k správe serverov. Výber cloudového dodávateľa nie je odlišný od rozhodovania sa o používaní kontajnerov alebo databáz, alebo dokonca programovacieho jazyka.
Premyslite si:
- Aké služby potrebujete a prečo.
- Aké služby poskytujú cloudoví poskytovatelia a ako ich môžete kombinovať pomocou vybraného FaaS riešenia.
- Aké programovacie jazyky sú podporované (s dynamicky alebo staticky typovanými, kompilovanými alebo interpretovanými, aké sú benchmarky, aký je výkon pri studenom štarte, aká je open source ekosystém a podobne).
- Aké sú vaše požiadavky na bezpečnosť (SLA, 2FA, OAuth, HTTPS, SSL a pod.).
- Ako spravovať váš CI/CD a cykly vývoja softvéru.
- Na aké výhody z riešení typu infrastructure-as-code môžete využiť.
Ak rozširujete existujúcu aplikáciu a postupne pridávate bezserverové funkcie, môže to trochu obmedziť dostupné možnosti. Avšak takmer všetky bezserverové technológie poskytujú nejaké API (cez REST alebo správy), ktoré umožňujú vytvárať rozšírenia nezávisle od jadra aplikácie a s jednoduchou integráciou. Hľadajte služby s prehľadnými API, dobrou dokumentáciou a silnou komunitou a určite nesklamete. Jednoduchosť integrácie môže byť často kľúčovým ukazovateľom a pravdepodobne to je jeden z hlavných dôvodov úspechu AWS od vydania Lambda v roku 2015.
Kedy je bezserverovosť užitočná
Bezserverové technológie sa dajú aplikovať prakticky všade. Avšak ich výhody sa neobmedzujú len na spôsoby aplikácie. Práh vstupu do cloud computingu je dnes tak nízky práve vďaka bezserverovým technológiám. Ak majú vývojári nápad, ale nevedia, ako spravovať cloudovú infraštruktúru a optimalizovať náklady, nemusia hľadať nejakého inžiniera na to. Ak startup chce vybudovať platformu, ale obáva sa, že náklady môžu uniknúť spod kontroly, ľahko sa môže obrátiť na bezserverové riešenia.
Vďaka úsporám nákladov a jednoduchej škálovateľnosti sú bezserverové riešenia rovnako aplikovateľné pre interné systémy, ako aj pre externé, až po webovú aplikáciu s miliónmi používateľov. Účty sú skôr v centoch ako v eurách. Prenájom najjednoduchšej verzie AWS EC2 (t1.micro) na mesiac vás vyjde na 15 €, aj keď s ňou nič nerobíte (kto by si niekedy nezabudol vypnúť?!). Pre porovnanie, aby ste dosiahli takú úroveň výdavkov za rovnaké časové obdobie, musíte spustiť Lambda s veľkosťou 512 MB na 1 sekundu približne 3 milióny krát. A ak túto funkciu nepoužívate, nič neplatíte.
Keďže bezserverová technológia závisí prevažne od udalostí, je možné pomerne ľahko pridať do starých systémov bezserverovú infraštruktúru. Napríklad pomocou AWS S3, Lambda a Kinesis môžete vytvoriť analytickú službu pre starý maloobchodný systém, ktorý bude schopný prijímať dáta cez API.
Väčšina serverless platforiem podporuje rôzne jazyky. Najčastejšie sú to Python, JavaScript, C#, Java a Go. Zvyčajne nie sú v žiadnom z jazykov obmedzenia na používanie knižníc, takže môžete aplikovať svoje obľúbené open source knižnice. Odporúča sa však nehromadiť závislosti, aby sa vaše funkcie vykonávali optimálne a neznižovali výhody obrovskej škálovateľnosti vašich serverless aplikácií. Čím viac balíkov je potrebné načítať do kontajnera, tým dlhšie bude trvať studený štart.
Studený štart je, keď je najprv potrebné inicializovať kontajner, prostredie vykonávania a spracovateľa chýb, skôr než ich začnete používať. Z tohto dôvodu môže oneskorenie vykonávania funkcií dosiahnuť 3 sekundy, čo nie je najlepšia voľba pre netrpezlivých používateľov. Studené štarty sa však vyskytujú pri prvom prístupe po niekoľkých minútach nečinnosti funkcie. Mnohí preto považujú toto za drobné nepríjemnosti, ktorým sa dá vyhnúť pravidelným pingovaním funkcie, aby sa udržala v pohotovostnom režime. Alebo tento aspekt úplne ignorujú.
Aj keď AWS vydal, SQL databázy nie sú ideálne na takúto aplikáciu, pretože pri transakciách závisia od pripojení, ktoré sa môžu rýchlo stať užším miestom pri vysokom prenosovom zaťažení na AWS Lambda. Áno, vývojári neustále zlepšujú Serverless Aurora a mali by ste si s ňou skúsiť experimentovať, avšak dnes sú pre serverless systémy oveľa vhodnejšie NoSQL riešenia ako. Napriek tomu je nepochybné, že sa táto situácia veľmi skoro zmení.
Nástroje tiež ukladajú množstvo obmedzení, najmä v oblasti lokálneho testovania. Hoci existujú riešenia ako Docker-Lambda, DynamoDB Local a LocalStack, tieto si však vyžadujú značnú prácu a úsilie pri konfigurácii. Napriek tomu sa všetky tieto projekty aktívne vyvíjajú, takže je to len otázka času, kedy nástroje dosiahnu požadovanú úroveň.
Vplyv serverless technológií na vývojový cyklus
Keďže vaša infraštruktúra predstavuje len konfiguráciu, môžete definovať a nasadiť kód pomocou skriptov, ako napríklad shell skriptov. Alebo môžete použiť riešenia triedy configuration-as-code ako . Aj keď tento servis nenabízajú konfiguráciu pre všetky oblasti, umožňuje definovať konkrétne zdroje na použitie ako Lambda funkcie. To znamená, že tam, kde vás CloudFormation sklamá, môžete napísať vlastný zdroj (Lambda funkcia), ktorý túto medzeru vyplní. Týmto spôsobom môžete robiť čokoľvek, dokonca konfigurovať závislosti mimo vášho AWS prostredia.
Keďže ide len o konfiguráciu, môžete parameterizovať vaše nasadzovacie skripty pre konkrétne prostredia, regióny a používateľov, najmä ak používate riešenia typu infrastructure-as-code ako CloudFormation. Napríklad môžete nasadiť kópiu infraštruktúry pre každú vetvu v repozitári, aby ste ich mohli plne izolovane testovať počas vývoja. To radikálne urýchľuje získavanie spätnej väzby od vývojárov, keď chcú pochopiť, či ich kód správne funguje v živom prostredí. Manažérom sa už netreba obávať nákladov na nasadenie mnohých prostredí, pretože platí sa len za skutočné využitie.
DevOps sa stáva menej stresujúcim, pretože potrebujú len zabezpečiť, aby mali vývojári správnu konfiguráciu. Už nie je potrebné spravovať inštancie, vyrovnávače záťaže alebo bezpečnostné skupiny. Preto je čoraz častejšie používaný termín NoOps, hoci stále je dôležité vedieť konfigurovať infraštruktúru, najmä pokiaľ ide o konfiguračné IAM a optimalizáciu cloudových zdrojov.
Existujú veľmi mocné nástroje na monitoring a vizualizáciu ako Epsagon, Thundra, Dashbird a IOPipe. Umožňujú sledovať aktuálny stav serverless aplikácií, poskytujú záznamy a trasovanie, registrujú metriky výkonnosti a úzke miesta architektúry, vykonávajú analýzy a predpovedanie nákladov a mnohé ďalšie. Nielenže poskytujú DevOps inžinierom, vývojárom a architektom komplexný prehľad o výkone aplikácií, ale aj umožňujú manažérom sledovať situáciu v reálnom čase, s presnými sekundovými nákladmi na zdroje a predpovedaním nákladov. Organizovať takúto infraštruktúru s riadenou obsluhou je oveľa ťažšie.
Navrhovanie serverless aplikácií je omnoho jednoduchšie, pretože nemusíte nasadzovať webové servery, spravovať virtuálne stroje alebo kontajnery, opravovať servery, operačné systémy, internetové brány a podobne. Abstrakcia od všetkých týchto povinností umožňuje serverless architektúre zamerať sa na hlavné - na uspokojenie potrieb podnikania a zákazníkov.
Aj keď nástroje mohli byť lepšie (neustále sa zlepšujú), vývojári sa môžu sústrediť na implementáciu biznis logiky a najlepšie rozloženie zložitosti aplikácie medzi rôznymi službami v rámci architektúry. Správa serverless aplikácií prebieha na základe udalostí a je abstrahovaná cloudovým poskytovateľom (napríklad SQS, S3 udalosti alebo DynamoDB prúdy). Preto stačí, ak vývojári napíšu biznis logiku na reagovanie na určité udalosti, a nemusia sa obávať, ako najlepšie spravovať databázy a správy, alebo ako optimálne pracovať s dátami v konkrétnych hardvérových úložiskách.
Kód môžete spúšťať a ladením lokálne, ako pri akomkoľvek procese vývoja. Modulárne testovanie zostáva rovnaké. Možnosť nasadiť celú infraštruktúru aplikácie pomocou prispôsobenej konfigurácie stacku umožňuje vývojárom rýchlo získať dôležitú spätnú väzbu, bez toho, aby museli premýšľať o nákladoch na testovanie alebo o vplyve na drahé spravované prostredia.
Nástroje a metodiky na budovanie serverless aplikácií
Neexistuje konkrétny spôsob výstavby serverless aplikácií. Rovnako tak ani súbor služieb pre túto úlohu. Vodcom medzi silnými serverless riešeniami je dnes AWS, avšak dbajte aj na , a . Ak používate AWS, odporúča sa ako prístup k budovaniu aplikácií (SAM), najmä pri používaní C#, pretože vo Visual Studio je vynikajúci nástroj. SAM CLI môže robiť to isté, čo aj Visual Studio, takže nič nestratíte, ak prejdete na iné IDE alebo textový editor. Samozrejme, SAM funguje aj s inými jazykmi.
Ak píšete v iných jazykoch, Serverless Framework je vynikajúci open source nástroj, ktorý umožňuje konfigurovať čokoľvek pomocou veľmi silných konfiguračných YAML súborov. Serverless Framework tiež podporuje rôzne cloudové služby, preto ho odporúčame tým, ktorí hľadajú multicloudové riešenie. Má obrovské spoločenstvo, ktoré vytvorilo množstvo pluginov pre akékoľvek potreby.
Na lokálne testovanie sú ideálne open source nástroje Docker-Lambda, Serverless Local, DynamoDB Local a LocalStack. Serverless technológie sú zatiaľ v počiatočnej fáze vývoja, rovnako ako nástroje pre ne, takže pri nastavovaní zložitých testovacích scenárov sa budete musieť poriadne zapotiť. Avšak jednoducho nasadiť stack v prostredí a testovať tam sa ukazuje byť neuveriteľne lacné. A nemusíte robiť presnú lokálnu kópiu cloudových prostredí.
Na zmenšenie veľkostí nasadených balíkov a urýchlenie načítania používajte AWS Lambda Layers.
Na konkrétne úlohy používajte správne programovacie jazyky. Rôzne jazyky majú svoje výhody a nevýhody. Existuje množstvo benchmarkov, ale JavaScript, Python a C# (.NET Core 2.1+) sú lídrami z pohľadu výkonu AWS Lambda. Nedávno sa v AWS Lambda objavil Runtime API, ktorý umožňuje uviesť požadovaný jazyk a prostredie na vykonávanie, takže experimentujte.
Udržiavajte malé veľkosti balíkov na nasadenie. Čím sú menšie, tým rýchlejšie sa načítajú. Vyhnite sa používaniu veľkých knižníc, najmä ak používate len niekoľko funkcií. Ak programujete v JavaScripte, používajte nástroje na zostavovanie ako Webpack, aby ste optimalizovali zostavenie a zahrnuli len to, čo skutočne potrebujete. V .NET Core 3.0 sú QuickJit a Tiered Compilation, ktoré zlepšujú výkon a veľmi pomáhajú pri studených spusteniach.
Závislosť serverless funkcií na udalostiach môže spočiatku sťažovať koordináciu obchodnej logiky. V tejto súvislosti môžu byť neuveriteľne užitočné fronty správ a konečné automaty. Lambda funkcie môžu vyvolávať jedna druhú, ale robte to len v prípade, že neočakávate odpoveď ("vystrelil a zabudol") — nechcete platiť za čakanie na dokončenie inej funkcie. Fronty správ sú užitočné na oddelenie častí obchodnej logiky, riadenie úzkych miest aplikácií a spracovanie transakcií (pomocou FIFO frontov). Funkcie AWS Lambda môžu byť priradené k SQS frontom ako fronty "visiacich" správ, ktoré sledujú zlyhané správy na následnú analýzu. Funkcie AWS Step Functions (konečné automaty) sú veľmi užitočné na riadenie zložitých procesov, ktoré si vyžadujú vytváranie reťazcov funkcií. Namiesto toho, aby Lambda funkcia vyvolávala inú funkciu, Step funkcie môžu koordinovať prechody stavov, prenášať dáta medzi funkciami a riadiť globálny stav funkcií. To umožňuje definovať podmienky opätovných pokusov alebo čo robiť pri výskyte konkrétnej chyby — za určitých okolností veľmi mocný nástroj.
Záver
V posledných rokoch sa serverless technológie vyvíjajú nevídanými rýchlosťami. S touto zmenou paradigmy sú spojené určité nepochopenia. Vďaka abstrahovaniu infraštruktúry a riadeniu škálovania serverless riešenia ponúkajú značné výhody: od zjednodušenia vývoja a DevOps procesov až po výrazné zníženie prevádzkových nákladov.
A hoci serverless prístup nie je bez nedostatkov, existujú spoľahlivé metódy a návrhové vzory, pomocou ktorých je možné vytvoriť odolné serverless aplikácie alebo integrovať serverless prvky do existujúcich architektúr.
Zdroj: habr.com
