470 lines
25 KiB
Markdown
470 lines
25 KiB
Markdown
# ☁️ Cloud architektura
|
|
|
|
## Poskytovatelé
|
|
|
|
- **AWS** — největší tržní podíl, nejširší portfolio
|
|
- **Azure** — silná integrace s Microsoft ekosystémem
|
|
- **GCP** — Kubernetes (GKE), data & ML, síťová konektivita
|
|
|
|
## Modely nasazení
|
|
|
|
| Model | Popis |
|
|
|-------|-------|
|
|
| Public cloud | Sdílená infrastruktura poskytovatele |
|
|
| Private cloud | Vyhrazená infrastruktura (on-prem nebo hosted) |
|
|
| Hybrid cloud | Propojení public + private |
|
|
| Multi-cloud | Více veřejných poskytovatelů |
|
|
|
|
## Multi-cloud strategie
|
|
|
|
### Důvody pro multi-cloud
|
|
- **Vendor lock-in prevence** — diverzifikace rizika
|
|
- **Regulatorní požadavky** — data residency v konkrétních regionech
|
|
- **Best-of-breed** — každý provider má silné stránky (AWS networking, Azure enterprise, GCP data/ML)
|
|
- **Akviziční scénáře** — merge & acquisition sjednocení
|
|
|
|
### Multi-cloud connectivity
|
|
|
|
| Metoda | Latence | Propustnost | Náklady |
|
|
|--------|---------|-------------|---------|
|
|
| Site-to-Site VPN | Střední | Omezená | Nízké |
|
|
| Private interconnect (Direct Connect / ExpressRoute / Dedicated Interconnect) | Nízká | Vysoká | Vysoké |
|
|
| Cloud-to-cloud VPN | Střední | Střední | Střední |
|
|
| SD-WAN | Nízká | Vysoká | Střední |
|
|
|
|
### Výzvy
|
|
- **Síťová komplexita** — rozdílné VPC/VNet koncepty, security modely
|
|
- **IAM federace** — jednotné identity napříč cloudy (SSO, SAML, OIDC)
|
|
- **Data gravitace** — pohyb dat mezi cloudy je drahý a pomalý
|
|
- **Monitoring** — jeden pane of glass napříč cloudy (Grafana, Datadog)
|
|
|
|
### Cloud Adoption Frameworks (CAF)
|
|
|
|
Každý hlavní poskytovatel má vlastní Cloud Adoption Framework pro strukturovaný přístup k adopci cloudu:
|
|
|
|
| Poskytovatel | Rámec | Zaměření |
|
|
|-------------|-------|----------|
|
|
| AWS | AWS CAF | 6 perspektiv: Business, People, Governance, Platform, Security, Operations |
|
|
| Azure | Microsoft CAF | 8 metodik: Strategy, Plan, Ready, Migrate, Innovate, Govern, Manage, Secure |
|
|
| GCP | Google CAF | 4 pilíře: Learn, Scale, Modernize, Operate |
|
|
|
|
Multi-Cloud Administration Guide (Mulder, 2024) doporučuje kombinovat CAF rámce napříč poskytovateli pro jednotné governanční modely, zejména v oblastech:
|
|
- **Interoperabilita** — standardizace API a IaC napříč cloudy (Terraform, Pulumi)
|
|
- **Data governance** — jednotná politika pro data residency a životní cyklus dat
|
|
- **Compliance automation** — automatizované audity napříč cloudy (AWS Config, Azure Policy, GCP Org Policies)
|
|
- **Access management** — federace identit a centralizované RBAC
|
|
|
|
## Migrační strategie — 6 Rs
|
|
|
|
| Strategie | Popis | Náročnost | Typický scénář |
|
|
|-----------|-------|-----------|----------------|
|
|
| **Rehost** (Lift & Shift) | Přesun VM/as-is bez změn | Nízká | Rychlá migrace, datacentrum exit, minimální riziko |
|
|
| **Replatform** (Lift & Reshape) | Migrace s drobnými úpravami (např. RDS místo self-managed DB) | Střední | Optimalizace bez přepisování aplikace |
|
|
| **Refactor** (Re-architect) | Přepis aplikace na cloud-native (microservices, serverless) | Vysoká | Maximalizace cloudu, dlouhodobá strategie |
|
|
| **Repurchase** | Přechod na SaaS (např. Salesforce, Workday) | Nízká | Aplikace je zastaralá, existuje SaaS alternativa |
|
|
| **Retire** | Vypnutí nepotřebných aplikací | Nízká | Aplikace již není používaná, decommission |
|
|
| **Retain** | Ponechání on-prem | Žádná | Regulatorní důvody, příliš vysoké riziko migrace |
|
|
|
|
### Decision framework pro 6 Rs
|
|
|
|
```
|
|
Start: Je aplikace potřebná?
|
|
├── Ne → Retire
|
|
└── Ano → Existuje SaaS alternativa?
|
|
├── Ano → Repurchase
|
|
└── Ne → Vyplatí se refactoring?
|
|
├── Ano → Refactor
|
|
└── Ne → Stačí změna platformy?
|
|
├── Ano → Replatform
|
|
└── Ne → Rehost
|
|
```
|
|
|
|
## Well-Architected Framework (AWS)
|
|
|
|
1. **Operational Excellence** — automace, monitoring, dokumentace
|
|
2. **Security** — IAM, encryption, compliance
|
|
3. **Reliability** — recovery, škálování, záložní plány
|
|
4. **Performance Efficiency** — right-sizing, výběr správných služeb
|
|
5. **Cost Optimization** — FinOps, reserved instances, spot instances
|
|
6. **Sustainability** (od 2022) — carbon footprint, energy efficiency
|
|
|
|
Obdoby: Azure Well-Architected Framework, GCP Architecture Framework
|
|
|
|
### Klíčové otázky z Well-Architected Review (~60 otázek)
|
|
|
|
**Operational Excellence (12 otázek)**
|
|
- Jak jsou změny řízeny a automatizovány?
|
|
- Jak jsou operace dokumentovány a sdíleny v týmu?
|
|
- Jak jsou očekávané a neočekávané události reflektovány v operacích?
|
|
- Jaké runbooky existují pro běžné provozní scénáře?
|
|
- Jak probíhá incident management a postmortem proces?
|
|
|
|
**Security (12 otázek)**
|
|
- Jak je implementováno identity & access management?
|
|
- Jak jsou chráněna data v klidu a při přenosu?
|
|
- Jak je zajištěna detekce bezpečnostních incidentů?
|
|
- Jaké jsou postupy pro patch management a vulnerability remediation?
|
|
- Jak jsou řízeny infrastrukturní kredenciály a secrets?
|
|
|
|
**Reliability (12 otázek)**
|
|
- Jak je zajištěna dostupnost služby při výpadku komponenty?
|
|
- Jak je implementováno backup a disaster recovery?
|
|
- Jak service limity (quotas, throttling) ovlivňují spolehlivost?
|
|
- Jak probíhá automatické škálování při změně zátěže?
|
|
- Jaké jsou SLI/SLO metriky a jak jsou monitorovány?
|
|
|
|
**Performance Efficiency (12 otázek)**
|
|
- Jak je vybrán správný typ a velikost compute/ storage?
|
|
- Jak je optimalizována databázová vrstva (indexy, dotazy, caching)?
|
|
- Jak je monitoring využit k identifikaci úzkých hrdel?
|
|
- Jak je implementováno škálování (vertikální vs horizontální)?
|
|
|
|
**Cost Optimization (12 otázek)**
|
|
- Jak jsou náklady alokovány na týmy/projekty (chargeback/showback)?
|
|
- Jaké nástroje se používají pro analýzu nákladů?
|
|
- Jak jsou identifikovány a eliminovány nevyužité zdroje?
|
|
- Jak je optimalizováno licencování (BYOL, hybrid benefit)?
|
|
|
|
## Klíčové komponenty
|
|
|
|
### Výpočetní vrstva
|
|
|
|
- **VM / instance** — EC2, Azure VMs, GCE
|
|
- **Container orchestrace** — EKS, AKS, GKE
|
|
- **Serverless** — Lambda, Azure Functions, Cloud Functions
|
|
- **PaaS** — App Engine, Elastic Beanstalk, Azure App Service
|
|
|
|
### Compute comparison matrix (AWS EC2)
|
|
|
|
| Rodina | Typ | vCPU:Memory | Use case | Příklady cen (on-demand, us-east-1) |
|
|
|--------|-----|-------------|----------|--------------------------------------|
|
|
| **General purpose** | M7g, m7i | 1:4 | Web servery, microservices, dev/test | m7i.large ~$0.088/h |
|
|
| **Compute optimized** | C7g, c7i | 1:2 | HPC, batch processing, CI/CD, gaming | c7i.large ~$0.078/h |
|
|
| **Memory optimized** | R7g, r7i, x2idn | 1:8 až 1:32 | In-memory DB (Redis), SAP HANA, real-time analytics | r7i.large ~$0.118/h |
|
|
| **Storage optimized** | I4i, im4gn | 1:4 + NVMe | Transactional DB, data warehousing, Kafka | i4i.large ~$0.138/h |
|
|
| **GPU / ML** | P5, g5, trn1 | GPU attach | AI training (P5), inference (g5), ML (trn1) | g5.xlarge ~$1.006/h |
|
|
|
|
Viz [GPU.md](GPU.md) pro detail GPU modelů a konfigurací.
|
|
|
|
### Úložiště
|
|
|
|
- **Object storage** — S3, Blob Storage, Cloud Storage
|
|
- **Block storage** — EBS, managed disks, persistent disks
|
|
- **File storage** — EFS, Azure Files, Filestore
|
|
- **CDN** — CloudFront, Azure CDN, Cloud CDN
|
|
|
|
### S3 Storage Classes
|
|
|
|
| Třída | Dostupnost | Retrieval time | Cena / GB / měsíc | Use case |
|
|
|-------|-----------|----------------|-------------------|----------|
|
|
| **S3 Standard** | 99.99 % | milisekundy | ~$0.023 | Aktivní data, častý přístup |
|
|
| **S3 Intelligent-Tiering** | 99.9 % | milisekundy | ~$0.023 + monitoring fee | Neznámý / proměnlivý přístup |
|
|
| **S3 Standard-IA** | 99.9 % | milisekundy | ~$0.0125 | Méně častý přístup, ale rychlý |
|
|
| **S3 One Zone-IA** | 99.5 % | milisekundy | ~$0.01 | Znovu vytvořitelná data |
|
|
| **S3 Glacier Instant** | 99.9 % | milisekundy | ~$0.004 | Archiv s občasným přístupem |
|
|
| **S3 Glacier Flexible** | 99.99 % | 1-5 min (expedite) / 3-5 h (standard) | ~$0.0036 | Dlouhodobý archiv |
|
|
| **S3 Glacier Deep Archive** | 99.99 % | 12 h (standard) / 48 h (bulk) | ~$0.00099 | Nejlevnější, compliance archívy |
|
|
|
|
## Multi-AZ a Multi-Region architektura
|
|
|
|
```
|
|
Region ┌──────────────────────────────┐
|
|
│ AZ-1 AZ-2 AZ-3 │
|
|
│ ┌───┐ ┌───┐ ┌───┐ │
|
|
│ │APP│──────│APP│──────│APP│ │
|
|
│ └─┬─┘ └─┬─┘ └─┬─┘ │
|
|
│ │ │ │ │
|
|
│ ┌─▼──────────▼──────────▼─┐ │
|
|
│ │ Load Balancer │ │
|
|
│ └────────────┬────────────┘ │
|
|
│ │ │
|
|
│ ┌────────────▼────────────┐ │
|
|
│ │ Database (Primary) │ │
|
|
│ │ + Read Replica │ │
|
|
│ └─────────────────────────┘ │
|
|
└──────────────────────────────┘
|
|
```
|
|
|
|
## Disaster Recovery strategie
|
|
|
|
### DR strategie na AWS (od nejméně po nejvíce připravené)
|
|
|
|
| Strategie | RTO | RPO | Náklady | Popis |
|
|
|-----------|-----|-----|---------|-------|
|
|
| **Backup & Restore** | hodiny | 24 h | Nízké | Pravidelné zálohy dat do S3/Glacier, obnova v DR regionu |
|
|
| **Pilot Light** | desítky minut | minuty | Střední | Minimální běžící kopie (DB, core služby), škálování při failover |
|
|
| **Warm Standby** | minuty | sekundy | Vysoké | Běží zmenšená kopie produkce, škálování při failover |
|
|
| **Active-Active (Multi-Region)** | sekundy | < 1 s | Velmi vysoké | Plně aktivní ve více regionech, traffic routing (Route53, Global Accelerator) |
|
|
|
|
Klíčové knihy k tématu:
|
|
- **Engineering Resilient Systems on AWS** (Schwarz, Moran, Bachmeier, 2024) — praktické laby pro resilience vzory: back off and retry, multi-Region failover, circuit breaker, chaos engineering pomocí AWS Fault Injection Simulator
|
|
- **Building Resilient Architectures on AWS** (2025) — data security, backup strategie, automace recovery plánů
|
|
|
|
### Chaos Engineering
|
|
|
|
Cílené vnášení poruch do systému pro ověření odolnosti:
|
|
- **AWS Fault Injection Simulator (FIS)** — spravované fault injection pro EC2, ECS, EKS, RDS
|
|
- **Nástroje**: Chaos Mesh (Kubernetes), Gremlin, Litmus
|
|
- **Postup**: definice hypotézy → provedení experimentu → měření dopadu → zlepšení systému
|
|
- **Bezpečnost**: experimenty v izolovaném prostředí, safety controls, automatic rollback
|
|
|
|
## Cloud design patterns
|
|
|
|
### Strangler Fig
|
|
Postupné nahrazování částí monolitické aplikace microservices.
|
|
- Legacy funkcionalita se postupně přesměrovává na nové služby
|
|
- Strangler Fig proxy (route hlavičky, feature flagy) řídí přesun trafficu
|
|
- Výhoda: průběžné dodávání hodnoty bez big-bang přepisu
|
|
|
|
### Circuit Breaker
|
|
Zabránění kaskádovým selháním při výpadku závislé služby.
|
|
- Tři stavy: **Closed** (normální provoz), **Open** (requesty okamžitě failují), **Half-Open** (testovací request po timeoutu)
|
|
- Parametry: failure threshold, timeout (reset timeout), half-open max requests
|
|
- Implementace: resilience4j, Hystrix (legacy), Istio (envoy), AWS App Mesh
|
|
|
|
### Saga
|
|
Distribuovaná transakce napříč microservices — řada lokálních transakcí s kompenzačními akcemi.
|
|
- **Choreography** — každá služba publikuje událost, další služba reaguje (Kafka, EventBridge)
|
|
- **Orchestration** — centrální orchestrátor řídí kroky (Step Functions, Temporal, Camunda)
|
|
|
|
### CQRS (Command Query Responsibility Segregation)
|
|
Oddělení zápisových (Command) a čtecích (Query) modelů.
|
|
- Command model: optimalizovaný pro zápis (normalizovaný, transactionální)
|
|
- Query model: optimalizovaný pro čtení (denormalizovaný, read-optimized views)
|
|
- Eventual consistency mezi modely (event bus propaguje změny)
|
|
- Use case: reporting, audit logy, high-throughput systémy
|
|
|
|
### Event Sourcing
|
|
Ukládání stavu jako sekvence událostí (eventů), ne aktuálního stavu.
|
|
- Každá změna je append-only event v event store
|
|
- Současný stav = fold všech událostí
|
|
- Výhody: audit trail, time travel, CQRS kompatibilita
|
|
- Implementace: EventStoreDB, Kafka (log), DynamoDB + CDC
|
|
|
|
### Další cloudové patterny (Wilder — Cloud Architecture Patterns)
|
|
|
|
| Pattern | Kategorie | Popis |
|
|
|---------|-----------|-------|
|
|
| **Horizontally Scaling Compute** | Škálovatelnost | Přidávání/odebírání instancí dle zátěže, elasticita |
|
|
| **Queue-Centric Workflow** | Škálovatelnost | Decoupling komponent přes fronty (SQS, RabbitMQ), zpracování asynchronně |
|
|
| **Auto-Scaling** | Škálovatelnost | Automatické škálování na základě metrik (CPU, memory, request count) |
|
|
| **MapReduce** | Big Data | Distribuované zpracování dat (Hadoop, EMR, BigQuery) |
|
|
| **Database Sharding** | Big Data | Horizontální partition dat napříč databázemi |
|
|
| **Busy Signal** | Failure Handling | Graceful degradace při přetížení (HTTP 503, throttling, backpressure) |
|
|
| **Node Failure** | Failure Handling | Detekce a automatické zotavení z výpadku výpočetního uzlu |
|
|
| **Colocation** | Distribuovaní uživatelé | Umístění compute blízko datům pro snížení latence |
|
|
| **Valet Key** | Distribuovaní uživatelé | Delegovaný přístup ke storage (SAS tokeny, S3 presigned URLs) |
|
|
| **Multi-Site Deployment** | Distribuovaní uživatelé | Aktivní nasazení ve více geografických lokalitách |
|
|
|
|
## Evolutionary Architecture
|
|
|
|
Definice (Ford, Parsons, Kua, 2022): *Evoluční architektura podporuje řízenou, inkrementální změnu napříč více dimenzemi.*
|
|
|
|
### Fitness Functions
|
|
|
|
Automatizované kontroly architektonických charakteristik — obdoba testů pro architekturu:
|
|
|
|
| Typ | Popis | Příklad |
|
|
|-----|-------|---------|
|
|
| **Atomic** | Kontroluje jednu metriku | Cyclomatic complexity < 10 |
|
|
| **Holistic** | Kontroluje celkový systém | Latence end-to-end < 200 ms |
|
|
| **Triggered** | Spouštěná událostí (CI/CD commit, deployment) | Ověření API kontraktu |
|
|
| **Continous** | Běží nepřetržitě v produkci | Monitoring dependency freshness |
|
|
| **Static** | Analýza kódu bez běhu | SonarQube, ESLint |
|
|
| **Dynamic** | Analýza za běhu | Load testy, chaos experimenty |
|
|
|
|
### Principy evoluční architektury
|
|
|
|
1. **Inkrementální změna** — malé, bezpečné změny díky CI/CD, deployment pipelines, zralému DevOps
|
|
2. **Fitness funkce** — automatizovaná ochrana architektonických charakteristik (škálovatelnost, performance, bezpečnost)
|
|
3. **Správa couplingů** — vědomá práce s propojením komponent (affinity, volatility, cykly)
|
|
4. **Evoluční data** — databázové migrace jako first-class občan (evoluční schemata, expand-contract pattern)
|
|
|
|
### Antipatterny
|
|
- **Big Design Up Front (BDUF)** — snaha navrhnout vše předem, ignoruje změny
|
|
- **No Design at All** — absence architektonického myšlení, čistě emergentní design
|
|
- **Premature Standardization** — zavedení standardů dříve, než je známe domény
|
|
|
|
## Hybrid cloud konektivita
|
|
|
|
Viz také: [NETWORKING.md](NETWORKING.md) — síťová architektura (VPN, BGP, VPC design).
|
|
|
|
- **Site-to-Site VPN** — IPSec tunel přes internet
|
|
- **Direct Connect / ExpressRoute / Dedicated Interconnect** — privátní fyzické propojení
|
|
- **Cloud VPN / Transit Gateway** — hub-and-spoke topologie
|
|
|
|
## Cost optimization detail
|
|
|
|
### Savings Plans vs Reserved Instances
|
|
|
|
| Vlastnost | Compute Savings Plan | EC2 Instance Savings Plan | Reserved Instances |
|
|
|-----------|---------------------|---------------------------|-------------------|
|
|
| Flexibilita | Instance family, region, OS | Instance family + region | Specifická instance |
|
|
| Termín | 1 nebo 3 roky | 1 nebo 3 roky | 1 nebo 3 roky |
|
|
| Sleva (typicky) | ~30-50 % | ~40-60 % | ~40-60 % |
|
|
| Změna instance | Ano (libovolná) | Ano (v rámci rodiny) | Ne |
|
|
| Změna regionu | Ano | Ne | Ne |
|
|
| Payment options | All Upfront / Partial / No Upfront | All Upfront / Partial / No Upfront | All Upfront / Partial / No Upfront |
|
|
|
|
### Spot instance best practices
|
|
|
|
- **Diverzifikace** — používejte mix instance typů (spot fleet) pro vyšší dostupnost
|
|
- **Graceful handling** — aplikace musí zvládnout termination notice (2 minuty varování)
|
|
- **Checkpointing** — pravidelné ukládání stavu pro restart po spot přerušení
|
|
- **Spot block** (AWS) — ochrana na 1-6 h (omezená dostupnost)
|
|
- **Použití**: batch processing, CI/CD runners, stateless microservices, ML training
|
|
- **Vyhnout se**: stateful workloads, databáze (bez speciálního designu)
|
|
|
|
## Organizace a governance
|
|
|
|
### AWS Organizations
|
|
|
|
```
|
|
Root OU
|
|
├── Security OU
|
|
│ ├── Audit Account (CloudTrail, Config)
|
|
│ └── Security Tooling Account (GuardDuty, Security Hub)
|
|
├── Infrastructure OU
|
|
│ ├── Network Account (Transit Gateway, VPN)
|
|
│ ├── Shared Services Account (AD, SSO)
|
|
│ └── Log Archive Account
|
|
├── Workloads OU
|
|
│ ├── Dev OU → jednotlivé dev accounts
|
|
│ ├── Staging OU → staging accounts
|
|
│ └── Prod OU → production accounts
|
|
└── Sandbox OU → izolované experimentální účty
|
|
```
|
|
|
|
- **SCP** (Service Control Policies) — whitelist/blacklist služeb na OU úrovni
|
|
- **Tag policies** — enforcement tagování napříč účty
|
|
- **AI services opt-out** — kontrola použití dat v AWS AI službách
|
|
|
|
### Azure Management Groups
|
|
|
|
```
|
|
Tenant Root Group
|
|
├── Platform MG
|
|
│ ├── Connectivity (hub VNet, ExpressRoute)
|
|
│ ├── Management (Log Analytics, Automation)
|
|
│ └── Identity (AD DS, PIM)
|
|
├── Application MG
|
|
│ ├── DEV (dev subscriptions)
|
|
│ ├── TEST (test subscriptions)
|
|
│ └── PROD (production subscriptions)
|
|
└── Sandbox MG
|
|
```
|
|
|
|
- **Azure Policy** — built-in a custom policies (podobné SCP)
|
|
- **Management Group hierarchy** — až 6 úrovní hloubky
|
|
- **Subscription limits** — max 10 000 subscriptions na tenant
|
|
|
|
### GCP Projects
|
|
|
|
```
|
|
Organization Node
|
|
├── Folder: Platform
|
|
│ ├── Project: Shared Networking (VPC, Cloud NAT, VPN)
|
|
│ ├── Project: Security (Cloud KMS, Secret Manager, Chronicle)
|
|
│ └── Project: Monitoring (Cloud Monitoring, Logging)
|
|
├── Folder: Workloads
|
|
│ ├── Folder: Dev
|
|
│ │ └── Project: [aplikace]-dev
|
|
│ ├── Folder: Staging
|
|
│ │ └── Project: [aplikace]-staging
|
|
│ └── Folder: Prod
|
|
│ └── Project: [aplikace]-prod
|
|
└── Folder: Sandbox
|
|
└── Project: [user]-sandbox
|
|
```
|
|
|
|
- **Organization policies** — constrainty na úrovni organizace/folderu
|
|
- **Resource Manager** — hierarchie: Organization → Folder → Project → Resources
|
|
- **Project limits** — max 30 projektů (lze navýšit), resources per project 10k
|
|
|
|
## 12-Factor App metodologie
|
|
|
|
Metodologie pro building cloud-native aplikací (Heroku, 2011), rozšířená knihou **Multi-Cloud Handbook for Developers** (Natarajan, Jacob, 2024).
|
|
|
|
| # | Faktor | Popis | Cloudová implementace |
|
|
|---|--------|-------|----------------------|
|
|
| 1 | **Codebase** | Jeden repozitář, mnoho deploymentů | Git + CI/CD pipeline |
|
|
| 2 | **Dependencies** | Explicitní deklarace závislostí | package.json, requirements.txt, Docker image |
|
|
| 3 | **Config** | Konfigurace v proměnných prostředí | Secrets Manager, Parameter Store, env vars |
|
|
| 4 | **Backing services** | Závislé služby jako připojené zdroje | RDS, S3, Redis — připojení přes connection string |
|
|
| 5 | **Build, release, run** | Striktní oddělení fází sestavení | CI/CD pipeline (GitHub Actions, GitLab CI) |
|
|
| 6 | **Processes** | Aplikace jako bezstavové procesy | Horizontální škálování, session v Redis |
|
|
| 7 | **Port binding** | Služba exportuje port, není vložena do serveru | Express, FastAPI, Spring Boot na vlastním portu |
|
|
| 8 | **Concurrency** | Škálování pomocí procesního modelu | Horizontal Pod Autoscaler (K8s), EC2 Auto Scaling |
|
|
| 9 | **Disposability** | Rychlý start a graceful shutdown | Health checks, SIGTERM handling, preStop hooks |
|
|
| 10 | **Dev/Prod parity** | Co nejmenší rozdíl mezi prostředími | Docker, IaC (Terraform), stejné backing services |
|
|
| 11 | **Logs** | Logy jako event streamy | stdout/stderr → CloudWatch, ELK, Datadog |
|
|
| 12 | **Admin processes** | Administrativní úlohy jako one-off procesy | DB migrace, data backfill — spuštěno v izolaci |
|
|
|
|
### Rozšíření pro multi-cloud (Multi-Cloud Handbook for Developers)
|
|
- **API-first design** — konzistentní API rozhraní napříč cloudy (REST, gRPC)
|
|
- **Domain-Driven Design (DDD)** — ohraničené kontexty mapované na cloudové služby
|
|
- **Service Mesh** — Istio, Linkerd pro observabilitu, traffic management a security napříč cloudy
|
|
- **GitOps** — declarativní deployment s ArgoCD/Flux napříč Kubernetes clustery v různých cloudech
|
|
|
|
## Azure Cloud Native Architecture (mapová příručka)
|
|
|
|
Na základě **The Azure Cloud Native Architecture Mapbook (2nd ed.)** (Eyskens, 2025) — 40+ architektonických map napříč doménami:
|
|
|
|
### Domény architektonických map
|
|
|
|
| Doména | Klíčové služby Azure | Architektonické vzory |
|
|
|--------|---------------------|----------------------|
|
|
| **Infrastructure** | VNet, Azure Firewall, ExpressRoute, VPN Gateway | Hub-and-spoke, Virtual WAN, Private Link |
|
|
| **Applications** | App Service, API Management, Service Bus, Functions | Event-driven, Strangler Fig, Backend for Frontend |
|
|
| **Data** | Cosmos DB, SQL Database, Synapse, Data Lake | CQRS, Event Sourcing, Polyglot Persistence |
|
|
| **Container Orchestrators** | AKS, Azure Container Apps, ACA | Sidecar, Ambassador, Adapter (service mesh) |
|
|
| **AI** | Azure OpenAI, Cognitive Services, ML Studio | RAG, model fine-tuning, MLOps |
|
|
| **Security** | Entra ID, Defender for Cloud, Key Vault, Sentinel | Zero Trust, Defense in depth, JIT Access |
|
|
|
|
### Využití Cloud Adoption Framework na Azure
|
|
- **Strategy** — business case, katalog aplikací, racionalizace portfolia
|
|
- **Plan** — landing zone design, governance baseline, subscription taxonomy
|
|
- **Ready** — implementace landing zones (ALZ), Azure Policy, Networking, Identity
|
|
- **Migrate** — assessment (Azure Migrate), rehost/replatform, test a cutover
|
|
- **Govern** — cost management, policy enforcement, compliance monitoring
|
|
|
|
## Srovnání cloudových poskytovatelů
|
|
|
|
Na základě **Cloud Computing: AWS, Azure, Google Cloud** (Sario, 2025):
|
|
|
|
| Oblast | AWS | Azure | GCP |
|
|
|--------|-----|-------|-----|
|
|
| **Compute** | EC2, Lambda, ECS/EKS | VMs, Functions, AKS | GCE, Cloud Functions, GKE |
|
|
| **Storage** | S3, EBS, EFS | Blob, Disk, Files | Cloud Storage, Persistent Disk, Filestore |
|
|
| **Databáze relační** | RDS (MySQL, PG, SQL Server, Oracle, MariaDB) | SQL Database, MySQL/PostgreSQL | Cloud SQL (MySQL, PG, SQL Server) |
|
|
| **Databáze NoSQL** | DynamoDB, ElastiCache | Cosmos DB, Redis Cache | Firestore, Bigtable, Memorystore |
|
|
| **Message queue** | SQS, SNS | Service Bus, Queue Storage | Pub/Sub, Tasks |
|
|
| **Observabilita** | CloudWatch, X-Ray | Monitor, Application Insights | Cloud Monitoring, Cloud Trace |
|
|
| **AI/ML** | SageMaker, Bedrock | Azure ML, OpenAI | Vertex AI, AutoML |
|
|
| **Cena (compute)** | On-demand, Reserved, Spot, Savings Plan | Pay-as-you-go, Reserved, Spot | On-demand, Committed Use, Spot |
|
|
|
|
## Best practices
|
|
|
|
- Používejte **infrastructure as code** (Terraform, Pulumi, CDK)
|
|
- Designujte pro **failure** — každá komponenta může spadnout
|
|
- Implementujte **defense in depth** — security na každé vrstvě
|
|
- Monitorujte **náklady** — taggování, budget alerts, anomaly detection
|
|
- Používejte **managed services** kde to dává smysl (méně operací)
|
|
- **Least privilege** pro všechny IAM role a politiky
|
|
|
|
## Zdroje
|
|
|
|
Odkazy, knihy a standardy: [sources/cloud/sources.md](sources/cloud/sources.md)
|
|
- **Cost tagging** — assign tags pro chargeback/showback (Environment, Team, Cost Center, Application)
|
|
- **Automated compliance** — AWS Config, Azure Policy, GCP Org Policies pro guardrails
|
|
- **Multi-account strategie** — AWS Control Tower, Azure Landing Zones, GCP Resource Hierarchy
|
|
|
|
### Doporučená literatura
|
|
|
|
| Kniha | Autoři | ISBN | Popis |
|
|
|-------|--------|------|-------|
|
|
| The AI Cloud Infrastructure Blueprint | Thummarakoti, Vududala, Madupati, Kaushik | 978-1-041-16642-9 | End-to-end průvodce návrhem, deploymentem a správou AI systémů na cloudových platformách. Pokrývá public/private/hybrid/multi-cloud modely pro AI, infrastrukturu pro ML trénování a inferenci, MLOps. Cílová skupina: architekti, data scientists, DevOps. |
|
|
| AWS for Solutions Architects (3rd ed.) | Shrivastava, Srivastav, Thakur | 978-1-83664-193-3 | Praktický průvodce AWS architekturou — compute (EC2, Lambda), storage (S3, EBS), databáze (RDS, DynamoDB), networking, security, Well-Architected Framework, migrace, cost optimization. Vhodné pro přípravu na AWS Solutions Architect certifikaci. |
|
|
|
|
*Poslední revize: 2026-06-03*
|