En el subcapítol anterior, en parlar del patró Saga, vam mencionar que necessitàvem una manera d’orquestrar processos de diversos passos: dirigir l’ordre, decidir què fer si un pas falla, esperar, reintentar... Quan tens moltes Lambdas (Capítol 14) que han de col·laborar en un flux complex, coordinar-les «a mà» esdevé un caos. Per això existeix AWS Step Functions: un servei que et permet orquestrar fluxos de treball de diversos passos de manera visual, ordenada i fiable. És com tenir un director d’orquestra per a les teves funcions serverless.
El problema: coordinar moltes funcions és un embolic
Imagina un procés de negoci amb diversos passos: validar una comanda, cobrar, reservar estoc, programar enviament, notificar... Cada pas podria ser una Lambda. Si intentes coordinar-les fent que una cridi la següent directament, sorgeixen problemes:
❌ Coordinació "a mà" (Lambda crida Lambda): - Què passa si un pas falla? Com reintento? - Com sé en quin pas va el procés ara mateix? - Com gestiono passos que triguen, esperes, decisions (si això, fes allò)? - El flux queda "amagat" dins el codi, difícil de veure i canviar
Aquesta «coordinació oculta en el codi» és fràgil, difícil de seguir i de modificar. Necessites separar la lògica del flux (l’ordre dels passos, què fer si fallen) de la lògica de cada pas (el que fa cada Lambda).
Què és Step Functions
AWS Step Functions és un servei per orquestrar fluxos de treball (workflows): defineixes una seqüència de passos —amb el seu ordre, decisions, reintents i gestió d’errors— i Step Functions l’executa i la coordina per tu. El flux es defineix de manera visual i declarativa, separat del codi de cada pas.
Step Functions executa un flux així:
[Validar comanda] → És vàlida?
├─ sí → [Cobrar pagament] → [Reservar estoc] → [Enviar] → [Fi]
└─ no → [Rebutjar] → [Fi]
(amb reintents i gestió d’errors a cada pas)Analogia: Step Functions és com el director d’una orquestra. Cada músic (Lambda) sap tocar el seu instrument (fer la seva tasca), però és el director qui marca l’ordre, quan entra cadascú, què fer si algú s’equivoca, i manté tothom coordinat perquè soni una simfonia i no un caos. Sense director, 50 músics tocant alhora sense coordinació serien un desastre. Step Functions dirigeix les teves funcions perquè col·laborin en un flux ordenat.
Una altra manera de veure-ho: és com un diagrama de flux que s’executa de veritat. Dibuixes el procés (aquest pas, després aquest, si passa això fes allò) i Step Functions ho porta a terme.
Què t’ofereix Step Functions
- Flux visual i clar
El flux de treball es veu com un diagrama: d’una ullada entens el procés complet (quins passos hi ha, en quin ordre, quines decisions es prenen). Això fa que el procés sigui fàcil d’entendre i de modificar, en comptes d’estar enterrat en el codi.
- Gestió d’errors i reintents integrada
Step Functions gestiona automàticament què fer quan un pas falla: pot reintentar (amb esperes creixents), saltar a un pas de gestió d’error, o executar compensacions (just el que necessita el patró Saga del subcapítol 28.2!). No has de programar tota aquesta lògica a mà.
- Seguiment de l’estat
Step Functions recorda en quin pas va cada execució i guarda l’historial. Pots veure exactament per on va un procés, quins passos s’han completat i on ha fallat si alguna cosa ha anat malament. Això dona una visibilitat enorme (complementa l’observabilitat del Capítol 24).
- Passos que esperen o triguen
Gestiona amb naturalitat fluxos que triguen (minuts, hores o fins i tot dies) o que han d’esperar alguna cosa (una aprovació humana, una resposta externa). Una cosa molt difícil de fer només amb Lambdas (que tenen un temps màxim d’execució, recorda el subcapítol 14.5).
Step Functions i el patró Saga
Step Functions és l’eina ideal per implementar una Saga per orquestració (subcapítol 28.2): defineixes els passos del procés i, per a cadascun, quina compensació executar si alguna cosa falla més endavant. Step Functions s’encarrega d’executar les compensacions en ordre si un pas falla, mantenint la consistència, tot de manera visual i controlada.
Saga amb Step Functions:
[Cobrar] → [Reservar] → [Enviar] ✗ falla
└─ Step Functions executa compensacions automàticament:
[Alliberar reserva] → [Reemborsar] → estat consistentExemple del món real: una empresa processa sol·licituds de préstec, un procés de molts passos: validar dades, comprovar l’historial creditici (trucada a un servei extern que triga), calcular el risc, esperar l’aprovació d’un humà si l’import és alt, i finalment desemborsar o rebutjar. Ho implementen amb Step Functions: el flux complet es veu com un diagrama clar, els passos que triguen o esperen (com l’aprovació humana, que pot trigar dies) es gestionen sense problema, i si algun pas falla, hi ha reintents i gestió d’errors definits. L’equip pot veure en quin punt està cada sol·licitud en temps real. El que coordinar a mà amb Lambdas hauria estat fràgil i il·legible, amb Step Functions és un procés clar, robust i fàcil de modificar.
Quan utilitzar Step Functions
- Quan tens un procés de diversos passos per coordinar (especialment amb Lambdas).
- Quan necessites gestió d’errors, reintents o compensacions robustes (com en una Saga).
- Quan el flux té decisions («si això, fes allò»), esperes o passos que triguen.
- Quan vols veure i entendre el procés clarament, no amagar-lo en el codi.
💡 Per a una sola tasca simple, una Lambda sola n’hi ha prou. Step Functions brilla quan hi ha un flux de diversos passos per coordinar.
El que has de recordar
- Coordinar moltes funcions fent que una cridi la següent és fràgil i difícil de seguir; convé separar la lògica del flux de la lògica de cada pas.
- AWS Step Functions orquestra fluxos de treball de diversos passos: defineixes l’ordre, decisions, reintents i gestió d’errors de manera visual i declarativa, i ell els executa i coordina. Com el director d’una orquestra (o un diagrama de flux que s’executa).
- T’ofereix: flux visual clar, gestió d’errors i reintents integrada, seguiment de l’estat (en quin pas va cada execució) i suport per a passos que esperen o triguen (fins i tot dies).
- És l’eina ideal per implementar el patró Saga per orquestració (executa les compensacions automàticament si un pas falla).
- Fes-la servir per a processos de diversos passos amb decisions, esperes o gestió d’errors robusta. 💡 Per a una tasca simple, n’hi ha prou amb una Lambda sola.
A l’últim subcapítol del capítol veurem com executar lògica serverless molt a prop dels usuaris, a la vora de la xarxa, amb Lambda@Edge i CloudFront Functions.
Cloud, AWS & Terraform — De zero a expert
Capítol 1 · Què és el cloud computing
- 1.1 El model client-servidor tradicional
- 1.2 Problemes que venia a resoldre el núvol
- 1.3 On-premise vs cloud vs híbrid
- 1.4 Els tres models de servei: IaaS, PaaS, SaaS
- 1.5 Els cinc pilars del cloud (segons NIST)
- 1.6 Avantatges reals: elasticitat, pagament per ús, disponibilitat global
Capítol 2 · El mercat cloud i els grans proveïdors
- 2.1 AWS, Azure i GCP: diferències i quotes de mercat
- 2.2 Per què aprendre AWS primer
- 2.3 Conceptes que són universals entre proveïdors
Capítol 3 · Regions, zones de disponibilitat i edge
- 3.1 Què és una regió AWS i com triar-la
- 3.2 Availability Zones: alta disponibilitat des del disseny
- 3.3 Edge locations i CloudFront
- 3.4 Latència, resiliència i sobirania de dades
Capítol 4 · Càlcul: EC2
- 4.1 Instàncies: tipus, famílies i quan triar cadascuna
- 4.2 AMIs, key pairs i Security Groups
- 4.3 Cicle de vida d'una instància
- 4.4 Elastic IPs i Placement Groups
- 4.5 Savings Plans vs Reserved vs On-Demand vs Spot
Capítol 5 · Emmagatzematge: S3
- 5.1 Buckets, objectes i claus
- 5.2 Classes d'emmagatzematge (Standard, IA, Glacier…)
- 5.3 Versionat i cicle de vida d'objectes
- 5.4 Polítiques de bucket i ACLs
- 5.5 Hosting de llocs web estàtics
Capítol 6 · Xarxes: VPC
- 6.1 Què és una VPC i per què la necessites
- 6.2 Subxarxes públiques i privades
- 6.3 Internet Gateway i NAT Gateway
- 6.4 Route Tables i Network ACLs
- 6.5 VPC Peering i endpoints
Capítol 7 · Identitat i accés: IAM
- 7.1 Usuaris, grups, rols i polítiques
- 7.2 El principi de mínim privilegi
- 7.3 Polítiques basades en identitat vs en recurs
- 7.4 MFA i credencials temporals (STS)
- 7.5 Bones pràctiques de seguretat IAM
Capítol 8 · Bases de dades gestionades
- 8.1 RDS: motors, Multi-AZ i rèpliques de lectura
- 8.2 Aurora i els seus avantatges sobre RDS vanilla
- 8.3 DynamoDB: model clau-valor / documents
- 8.4 ElastiCache per a memòria cau en memòria
- 8.5 Quan utilitzar cada tipus de base de dades
Capítol 9 · Per què Infraestructura com a Codi
- 9.1 Problemes del provisionament manual
- 9.2 IaC declaratiu vs imperatiu
- 9.3 Terraform vs CloudFormation vs Pulumi vs CDK
- 9.4 El cicle plan → apply → destroy
Capítol 10 · HCL: el llenguatge de Terraform
- 10.1 Blocs resource, variable, output, locals
- 10.2 Tipus de dades: string, number, bool, list, map, object
- 10.3 Expressions, referències i funcions built-in
- 10.4 Condicionals i bucles (count, for_each, for)
Capítol 11 · Providers i estat
- 11.1 Com funciona el provider d'AWS
- 11.2 El fitxer terraform.tfstate i la seva importància
- 11.3 State local vs state remot (S3 + DynamoDB)
- 11.4 Comandes essencials: init, plan, apply, destroy, fmt, validate
Capítol 12 · La teva primera infraestructura real amb Terraform
- 12.1 Crear una VPC amb subxarxes des de zero
- 12.2 Posar en marxa una instància EC2 pública
- 12.3 Associar un Security Group i una Elastic IP
- 12.4 Outputs i referències entre recursos
- 12.5 Flux de treball en equip: PR review de plans
Capítol 13 · Balanceig de càrrega i autoescalat
- 13.1 Application Load Balancer vs Network Load Balancer
- 13.2 Target Groups, listeners i regles
- 13.3 Auto Scaling Groups: polítiques i mètriques
- 13.4 Warm pools i lifecycle hooks
Capítol 14 · Serverless amb Lambda
- 14.1 El model d'execució de Lambda
- 14.2 Triggers: API Gateway, S3, DynamoDB Streams, SQS
- 14.3 Gestió de dependències i capes (Layers)
- 14.4 Cold starts i estratègies per reduir-los
- 14.5 Límits i antipatrones
Capítol 15 · Missatgeria i esdeveniments
- 15.1 SQS: cues estàndard vs FIFO, DLQ
- 15.2 SNS: topics, subscripcions, fan-out
- 15.3 EventBridge: event buses i regles
- 15.4 Patrons: pub/sub, desacoblament, saga
Capítol 16 · Lliurament de contingut i DNS
- 16.1 Route 53: tipus de registres i routing policies
- 16.2 CloudFront: distribucions, memòries cau i origins
- 16.3 ACM: certificats SSL/TLS gratuïts
- 16.4 WAF integrat amb CloudFront
Capítol 17 · Contenidors a AWS
- 17.1 Docker: repàs exprés de conceptes clau
- 17.2 ECR: registre privat d'imatges
- 17.3 ECS: task definitions, services, Fargate vs EC2
- 17.4 EKS: quan Kubernetes i quan no
Capítol 18 · Mòduls: reutilització i composició
- 18.1 Anatomia d'un mòdul Terraform
- 18.2 Variables d'entrada, outputs i dependències
- 18.3 Mòduls locals vs mòduls del Terraform Registry
- 18.4 Versionat de mòduls amb Git tags
- 18.5 Disseny de mòduls genèrics vs específics de domini
Capítol 19 · Workspaces i gestió d'entorns
- 19.1 Workspaces de Terraform: casos d'ús i limitacions
- 19.2 Estratègia de directoris per entorn (dev/stg/prod)
- 19.3 Terragrunt: DRY per a configuracions d'entorn
- 19.4 Variables d'entorn i fitxers .tfvars
Capítol 20 · Backends remots i locking
- 20.1 Configurar S3 + DynamoDB com a backend
- 20.2 State locking: evitar corrupció en equip
- 20.3 Migració d'estat entre backends
- 20.4 terraform import: portar recursos existents a l'estat
Capítol 21 · Testing d'infraestructura
- 21.1 Terraform validate i fmt en CI
- 21.2 Checkov i tfsec: anàlisi de seguretat estàtica
- 21.3 Terratest: tests d'integració en Go
- 21.4 Contract testing entre mòduls
Capítol 22 · Terraform en CI/CD
- 22.1 Pipeline bàsic: lint → plan → apply a GitHub Actions
- 22.2 Atlantis: GitOps per a Terraform
- 22.3 Terraform Cloud / HCP Terraform
- 22.4 Drift detection i reconciliació automàtica
Capítol 23 · Seguretat en profunditat
- 23.1 AWS Organizations i Service Control Policies
- 23.2 AWS Config: compliment continu
- 23.3 GuardDuty: detecció d'amenaces
- 23.4 Security Hub: visió centralitzada
- 23.5 KMS: gestió de claus i rotació
- 23.6 Secrets Manager vs Parameter Store
Capítol 24 · Observabilitat: logs, mètriques i traces
- 24.1 CloudWatch Logs, mètriques i alarmes
- 24.2 CloudWatch Dashboards i Contributor Insights
- 24.3 X-Ray: traçat distribuït
- 24.4 OpenTelemetry a AWS
- 24.5 Managed Grafana i Managed Prometheus
Capítol 25 · Optimització de costos
- 25.1 AWS Cost Explorer i pressupostos amb alertes
- 25.2 Trusted Advisor i Compute Optimizer
- 25.3 Rightsizing: com detectar sobredimensionament
- 25.4 Savings Plans vs Reserved Instances: decisió estratègica
- 25.5 FinOps: cultura i processos per controlar la despesa
Capítol 26 · Alta disponibilitat i disaster recovery
- 26.1 RTO i RPO: definir els objectius
- 26.2 Estratègies: backup/restore, pilot light, warm standby, multi-site
- 26.3 Route 53 health checks i failover automàtic
- 26.4 AWS Backup: política centralitzada de còpies
Capítol 27 · Well-Architected Framework d'AWS
- 27.1 Els sis pilars: excel·lència operacional, seguretat, fiabilitat, eficiència de rendiment, optimització de costos, sostenibilitat
- 27.2 Well-Architected Tool: revisions formals
- 27.3 Com aplicar el framework en decisions de disseny
Capítol 28 · Arquitectures serverless a escala
- 28.1 Event-driven architecture amb Lambda + EventBridge
- 28.2 Saga pattern per a transaccions distribuïdes
- 28.3 Step Functions: orquestració de workflows complexos
- 28.4 Lambda@Edge i CloudFront Functions
Capítol 29 · Plataformes de dades a AWS
- 29.1 Data Lake amb S3, Glue i Athena
- 29.2 Kinesis Data Streams i Firehose per a streaming
- 29.3 Redshift: data warehousing a escala
- 29.4 Lake Formation: govern del dada
Capítol 30 · Multi-compte i landing zones
- 30.1 Per què separar workloads en comptes diferents
- 30.2 AWS Control Tower i Account Factory
- 30.3 Gestió centralitzada de logs i seguretat
- 30.4 Terraform a escala multi-compte amb mòduls compartits
Capítol 31 · Platform Engineering i Internal Developer Platform
- 31.1 Golden paths i abstraccions sobre Terraform
- 31.2 Service Catalog d'AWS
- 31.3 Backstage com a portal de desenvolupadors
- 31.4 Mòduls Terraform com a producte intern
Capítol 32 · Certificacions AWS rellevants
- 32.1 Cloud Practitioner: val la pena?
- 32.2 Solutions Architect Associate → Professional
- 32.3 DevOps Engineer Professional
- 32.4 Specialty: Security, Database, Networking
- 32.5 HashiCorp Terraform Associate
Capítol 33 · Projectes per consolidar el que s'ha après
- 33.1 Projecte 1: blog serverless (S3 + CloudFront + Lambda + DynamoDB)
- 33.2 Projecte 2: API REST amb ECS Fargate + RDS + ALB
- 33.3 Projecte 3: plataforma de dades amb Glue + Athena + Redshift
- 33.4 Projecte 4: landing zone multi-compte amb Terraform i Control Tower
