Druhy Architektur v AWS

Evoluce Architektur:

Provozování aplikací v cloudu má spoustu výhod. Abychom jich mohli co nejlépe využít, upouštíme od klasických monolitických aplikací a rozdělujeme aplikace do menších, od sebe oddělených částí.

 

Častý způsob, jak můžeme aplikaci v AWS rozdělit je užitím 3 – Tier Architektury. 3 – Tier Architektura rozděluje aplikaci na 3 vrstvy, kde každá vrstva plní svůj účel. 3 – Tier Architekturu lze implementovat jako klasický Monolit nebo jako Mikroslužby, které se používají čím dál častěji.

3 – Tier Architektura

3 – Tier je nejběžnější druh Architektury v AWS. Skládá se z prezentační, aplikační a datové vrstvy.

• Jednotlivé vrstvy lze škálovat jednotlivě
• Zvýšená integrita dat a zabezpečení
• Flexibilní ke změnám

Ačkoliv se výsledná podoba může lišit podle služeb které aplikace obsahuje, základ bývá velmi podobný. Následující diagram zobrazuje 3 – Tier aplikaci s EC2 a ELB:

3 – Tier aplikaci lze také implementovat například pomocí Kubernetes:

Základ je velmi podobný i v případě 3 – Tier aplikace pomocí Serverless:

Monolitická Architektura

V Monolitické Architektuře všechny procesy běží jako jediná služba. Využívá se v menších aplikacích kvůli její jednoduchosti. Nedokáže však plně využít potenciálu cloudu a má spoustu nevýhod:

• Nelze škálovat jednotlivé komponenty => $$$
• Jediný bod selhání
• Aplikace není flexibilní ke změnám:

•  Při každé změně se musí postavit celá znovu
•  Jakákoli změna ovlivní celou aplikaci => složitá inovace

Diagram níže zobrazuje vzorovou monolitickou aplikaci:

Mikroslužby

Mikroslužby jsou druh architektury, která se skládá z nezávislých služeb. Každá služba obsahuje jinou část celkového kódu a plní jiný účel. Skvěle se hodí pro provozování v cloudu.

• Služby lze nezávisle škálovat
• Selhání jedné služby neovlivní celou aplikaci
• Snadná inovace

• Znovu postavena musí být pouze služba, která podléhá změnám

Na diagramu níže lze vidět ukázkovou Architekturu Mikroslužeb se Serverless a EC2:

Synchronnost architektur

Synchronnost ovlivňuje, jak spolu jednotlivé části aplikace komunikují. Aplikace mohou komunikovat synchronně nebo asynchronně.

Synchronní Architektura

V Synchronní Architektuře služby, které odesílají data příjemcům čekají na odpověď.

• Všechny služby škálují společně -> vyšší náklady
• Během implementování změn je aplikace mimo provoz
• Vhodnější pro operace v reálném čase

Ukázková 3 – Tier Synchronní Architektura Mikroslužeb:

Asynchronní Architektura

V Asynchronní Architektuře služby, které odesílají data příjemcům nečekají na odpověď. Asynchronnosti lze docílit například užitím služby AWS SQS.

• Služby škálují nezávisle -> úspora nákladů

· Během implementování změn může aplikace zůstat v provozu

Vzorová 3 – Tier Asynchronní Architektura Mikroslužeb:

Event-Driven-Architektura (EDA)

EDA je další druh Asynchronní Architektury, kde spolu různé části aplikace komunikují odesíláním a příjímáním událostí. Na rozdíl od klasické asynchronní aplikace s AWS SQS, kde si příjemce získává data sám, v EDA příjemce reaguje na události.

• Sdílí vlastnosti asynchronní aplikace

Jakmile odesílatel zprávu odešle, už se nestará o to, jestli je zpracována ani nepotřebuje potvrzení o tom, jestli příjemce zprávu obdržel

V AWS existují 2 druhy událostí:

• S3 Event (Pouze pro S3)
• EventBridge (Pro všechny ostatní služby)

Následující diagram zobrazuje vzorové užití S3 Události, která volá AWS Lambda funkci:

1. Služba S3 pomocí události reaguje na změnu stavu (např. vložení obrázku)
2. S3 Událost spustí oddělenou Lambda funkci
3. Lambda funkce obrázek zpracuje

 

Shrnutí:

V tomto článku jsme se podívali na některé druhy architektur, se kterými se můžeme v AWS setkat. Rozdělení aplikací na více částí nám umožňuje využít plného potenciálu cloudu a zvýšit spokojenost uživatelů. Základem většiny architektur v AWS je 3 – Tier Architektura, ke které můžeme přidávat další přizpůsobitelné architektury.