AWS služby, které si dnes ukážeme, mají mnoho různých možností použití, nicméně já se zaměřím pouze na jejich vlastnosti důležité z pohledu Serverless architektury a dám vám tipy jak a proč dané služby využívat ve vašich serverlessových aplikacích.

AWS Lambda

je základním stavebním kamenem Serverless aplikací.

Jedná se o blok zdrojového kódu - takzvané lambda funkce - který když je spuštěn, tak je vám účtována pouze částka vypočítaná na základě počtu milisekund běhu vaší aplikace. Důležitá vlastnost lambda funkcí je to, že pokud vaši aplikaci nikdo nepoužívá, tak vám není nic účtováno.

Díky lambda funkcím můžete modifikovat výchozí chování Serverless služeb tak, aby dané služby splňovaly konkrétní požadavky vašeho zadání - např. Custom Message Trigger v Amazon Cognito - pomocí kterého si můžete modifikovat obsah a vzhled verifikačního emailu zaslaného vašemu uživateli službou Amazon Cognito.

Napojení lambda funkce na AWS službu se nazývá "trigger".

Amazon API Gateway

slouží k tvorbě REST nebo Websocket API poháněného lambda funkcemi.

HTTP endpoint je v dnešní době asi ten nejjednodušší způsob, jak zpřístupnit libovolnou funkcionality okolnímu světu a to stejné platí i v případě Lambdy a API Gateway.

API Gateway je právě tou "branou", která umožňuje okolnímu světu spouštět vaše lambda funkce. To znamená, že vstup do funkce tvoří veškeré parametry HTTP requestu od hlaviček přes tělo až po querystring a výstupy z funkce jsou response parametry jako HTTP status code, tělo odpovědi, hlavičky atd.

Praktickou ukázku práce s API Gateway naleznete v následujícím díle této série.

Amazon DynamoDB

je NoSQL sloupcově orientovaná databáze, která je plně serverless - což znamená, že dokáže škálovat až na nulu.

Ze pohledu serverlessu můžeme DynamoDB popsat dvěma způsoby:

  1. Vysoce výkonná a škálovatelná databáze, optimalizovaná pro velký provoz, původně vyvinutá pro potřeby Amazonu a následně důkladně otestovaná ostatními firmami jako jsou AirBnb, Lyft, Samsung a další.
  2. Serverlessová databáze, která dokáže škálovat až na nulu a má pay-per-use pricing, takže ji lze využít na různé mikroservices a minimalizovat tak náklady na datové uložiště. Dále je databáze ovládaná přes AWS SDK, což je důvod k tomu, že správa přístupu k ní je řízená pomocí AWS IAM, což výrazně přispívá ke zvýšení celkového zabezpečení databáze.

DynamoDB se na první pohled může jevit jako značně primitivní databáze, kterou ale právě díky tomu lze využívat mnoha způsoby, což snadno může vést k jejímu nesprávnému používání, které se pak podepíše buď na provozních nákladech nebo na výkonnosti aplikace.

Pro více informacích, o správných návrhových vzorech a řešeních různých obecných problémů, doporučuji knihu The DynamoDB Book.

Amazon S3

neboli Simple Storage Service, je cloudové uložiště souborů.

S3 je vysoce škálovatelné a vysoce přístupné úložiště - takzvaný object storage - které má vzhledem ke své obecné povaze mnoho využití - od dlouhodobého skladování velkého množství dat kvůli následné datové analýze až po skladování náhledových obrázků, které jsou po několika minutách smazány.  

Ve světě serverlessových aplikací S3 slouží jako dlouhodobé uložiště ve kterém přetrvávají soubory bez ohledu na to, zda je lambda funkce spuštěná nebo ne.

Např. když si chcete předat soubor mezi dvěmi lambda funkcemi, tak jeden z častých návrhových vzorů je v lambda funkci "A" nahrát obrázek do S3 a následně lambda funkci "B" předat pouze cestu k danému souboru, který si pak lambda funkce "B" stáhne z S3 k dalšímu zpracování.

S3 také nabízí triggery, které umožňují reagovat např. na nahrání nového souboru, což se může hodit třeba pro zpracovávání dokumentů v různých background jobech atp.

Další významné serverlessové využití S3 je hosting statických webů.
Server-side rendering asi znáte - javascriptová frontendová aplikace se při každém požadavku vyrenderuje na serveru a ke klientovy se odešle výsledné HTML.
Něco podobného je tzv. "statický export", což je vyrenderování aplikace do HTML pouze jednou a to při nasazování aplikace. Následně se vygenerované soubory nahrají na S3, která se pak stará o jejich distribuci pomocí svého statického webhostingu. Statický export nabízejí všechny dnešní mainstreamové frameworky jako je Next.js, Gatsby a další.

S3 patří do úzké skupiny nejstarších služeb na AWS, které byly spuštěny již v roce 2006.

Amazon CloudWatch

je monitorovací mozek vaší serverlssové aplikace a celkové infrastruktury.

CloudWatch lze rozdělit na 4 hlavní části:

  • Monitoring - sledování a analyzování libovolných metrik jak z AWS, tak z vaší aplikace. Např. počet spuštění nebo počet chyb dané lambda funkce v čase.
  • Alerting - nastavování upozornení pro případy, kdy daná metrika přesáhne vámi definovanou hranici.
  • Logs - sledování logů lambda funkcí a vyhledávání v nich.
  • Events - nastavování časovačů (cron) pro pravidelné spouštění lambda funkcí.

Amazon SNS

neboli Simple Notification Service, je message broker typu Pub/Sub, který replikuje a rozesílá zprávy všem konzumentům daného topicu.

SNS je vhodné pro případy, kdy je potřeba, aby na jednu událost reagovalo více nezávislých lambda funkcí.

Příklad využití: nová objednávka v eshopu - jeden konzument zapíše objednávku do databáze, další konzument vyšle požadavek do skladu a poslední konzument uloží objednávku do big data uložiště pro pozdější analýzu. Všem konzumentům přijde paralelně stejný vstup.

Ve většině případů je dnes lepší nahradit Amazon SNS novou službou Amazon Event Bridge, která je více propracovanější a je navržená na míru Serverless aplikacím.

Amazon SQS

neboli Simple Queue Service, je message broker typu fronta, který uchovává zprávy od producentů a konzumenti je zpracovávají s ohledem na dostupnou kapacitu.

Důvod proč používat SQS je to, že žádná příchozí zpráva nepřijde nazmar. Pokud vaše API dělá složité operace, tak při vyšším zatížení přestane zvládat a buď začne padat, nebo začne odmítat nová spojení, což v obou případech znamená to, že přijdete o část vstupních zpráv a tedy například o nové objednávky.

Kdežto pokud by API pouze předávalo zprávy do SQS, ze kterého by byly získávány jiným nezávislým systémem, tak by se tak rychle API nezahltilo a tudíž by nedošlo ke ztrátě žádné zprávy. Jedné co by se v případě větší zátěže dělo, by bylo to, že by trvalo delší dobu, než by byla nová zpráva zpracována.

Hlavní rozdíl mezi SNS a SQS je to, že v případě SNS jsou všichni konzumenti informování o nové zprávě, kdežto u SQS každou zprávu zpracovává pouze jeden konzument.

Amazon EventBridge

poskytuje sběrnicí pomocí které mohou jednotlivé části aplikace mezi sebou komunikovat.

Jednou z hlavních vlastností serverless computingu je event-driven architektura a právě EventBus vytváří prostor pro vzájemnou komunikaci nezávislých lambda funkcí uvniř aplikace.

Jakmile veškeré události v aplikaci budou přenášeny přes EventBus, tak se díky tomu rapidně zjednoduší komplikovanost vývoje aplikace, jelikož pro přidání nové funkcionality bude stačit pouze vědět, jak se daná událost jmenuje, a pak už na ni jen napojit onu novou lambda funkci a je hotovo.  

Jako vždy, je i u EventBusu si potřeba dávat si pozor, jaké množství dat/požadavků přes něj přenášíte, protože by se vám to mohlo časem vymstít 💸. O polovinu levnější alternativa je již zmiňované Amazon SNS a pro opravdu velké zátěže se vyplatí použít Amazon Kinesis.

Amazon CloudFront

je CDN pro vaše aplikace na AWS.

Na první pohled se CloudFront jeví jako klasická CDN, nicméně je to významný nástroj pro serverlessové aplikace. Například, jak jsem výše zmiňoval, řekněme, že si budete hostovat statický frontend v S3 bucketu a vystavíte ho pomocí statického hostingu. Nicméně asi nechcete, aby vaše aplikace běžela na nějaké amazoní subdoméně a ještě k tomu bez SSL, že?

To lze vyřešit pomocí CloudFrontu:

  • vytvoříte si SSL certifikát zdarma od Amazonu pro vaši doménu v Amazon Certificate Manageru
  • vytvoříte CloudFront distribuci pro vaši doménu a jako origin přidáte static hosting URL vašeho S3 webu
  • přidáte DNS záznamy do vaší domény podle instrukcí v CloudFront dokumentaci

Ve výsledku tím získáte to, že:

  • přístup k vaší aplikaci bude zabezpečen přes SSL 🔐
  • vaše aplikace bude dostupná na doméně dle vašeho výběru
  • vaše aplikace se bude načítat mnohem rychleji díky tomu, že bude servírována z CDN
  • 🎉 🚀

CloudFront je kámoš, který mnohdy umí zachránit krk.

Amazon Cognito

je služba zajišťující autentizaci vašich uživatelů.

Postará se o celý bezpečnostní cyklus vaší uživatelské báze. Od registrace, přes potvrzování verifikačního emailu, až po přihlašování či dvoufázové ověření. Pro představu nejznámější konkurencí Cognita je např. služba Auth0.

Chování cognita si můžete značně modifikovat pomocí výše zmíněných lambda triggerů. Cognito stejně jako Auth0 nabízí přihlašování přes Google, Facebook, Apple, Amazon, či vlastní SAML/OIDC poskytovatele.

Vždy je lepší tak citlivou věc jako je autentizace outsourcovat, protože každé malé pochybení může vytvořit obrovskou díru ve vaší aplikaci nebo dokonce potopit celou firmu.

AWS CloudFormation

cloud provisioning platforma založená na Infrastructure-as-Code.

Infrastructure-as-Code je dle mého jeden ze základních stavebních kamenů serverlessu a moderního cloudu obecně. Minimalizuje riziko fatálních chyb, ztransparentňuje celou infrastrukturu a celkově zefektivňuje práci s ní. AWS nabízí svoji vlastní službu CloudFormation, nicméně na IaC lze použít i cloudově nezávislé nástroje, jako je např. Terraform či Pulumi a další.

CloudFormation je motorem Serverless Frameworku pro AWS a je pomocí něj zajištěný veškerý deployment infrastruktury aplikace.

AWS Cost Explorer

je služba sdružující finanční statistiky o využívání cloudu.

Častým problémem při růstu firmy jejichž celá infrastruktura je založená na serverlessu může být to, že se začnou projevovat špatná architektonická rozhodnutí z dob dávno minulých. Např. to, když tým použije službu jako je Amazon SQS bez toho, aniž by si spočítal, kolik je to bude stát do budoucna a jak se budou vyvíjet náklady na SQS s tím, jak firma poroste. Ze začátku sice SQS stojí třeba maximálně jednotky dolarů, nicméně když firma stokrát vyroste, tak náklady na SQS tisíckrát vyrostou. V ten okamžik si tým v Cost Exploreru prohlédle strukturu nákladů a začne vymýšlet, jak to optimalizovat. Nakonec to třeba vyřeší tak, že SQS nahradí službou Amazon Kinesis.

Serverless pricing je dobrý sluha, ale špatný pán.

AWS AppSync

slouží k tvorbě GraphQL API poháněného lambda funkcemi a dalšími cloudovými službami.

AppSync je reakcí AWS na již staro-nový trend v oblasti APIs. Principiálně funguje stejně jako API Gateway, až na ten rozdíl, že v něm můžete místo REST API provozovat GraphQL API.

Nabízí ať už klasickou integraci s AWS Lambda, tak např. i integraci s DynamoDB či RDS, kdy si nadefinujete jakým způsobem se má GraohQL query přeložit do databázového dotazu.

Narozdíl od API Gateway vždy vyžaduje určitou formu autentizace, což znamená, že každé API musí být zabezpečeno alespoň jednou z možností:

  • API klíč
  • IAM token
  • OpenID Connect token
  • Cognito User Pool token

Nelze tudíž mít otevřené API, které bude moct být voláno kdykoliv kýmkoliv.

AWS Step Functions

je služba zajišťující řízení komplexních větvených procesů skládajících se z většího počtu kroků.

StepFunctions je v podstatě serverlessovou odpovědí AWS na poptávku po řešení dlouhodo běžících procesů.

Hlavní důvody pro používání StepFunctions jsou:

  • AWS Lambda má omezenou maximální délku exekuce na 15 minut, což v případě dlouho běžících procesů je krátká doba.
  • Není doporučené v lambdě čekat na asynchronní procesy, protože to je v přímém rozporu ze základní myšlenkou event-driven architektury a v praxi je to vyhazování peněz z okna.
  • V případě, že máte velmi složitý a rozvětvený proces, tak vám StepFunctions usnadňují přehledně daný proces sledovat a díky tomu i rychle zjistit, kde je problém nebo jaká rozhodnutí byla provedena během exekuce a validovat, zda byla správná.

V Purple Technology pro nás byly Step Functions hlavním impulsem k adopci Serverlessu.

Závěr

Toto byla ukázka jen hrstky služeb a špička ledovce jejich možností použití. Doufám, že vám dala základní představu o tom, co vše za cloudové komponenty můžete využívat ve své serverlessové aplikaci.

V následujících dílech této série si ukážeme na konkrétních příkladech, jak s těmito službami pracovat v praxi.

V případě jakýchkoliv otázek mě neváhejte kontaktovat na Twitteru @FilipPyrek.

With ❤️ made in Brno.