En els subcapítols anteriors vam veure els golden paths i el Service Catalog: formes d’oferir infraestructura preparada als desenvolupadors. Però a mesura que una empresa creix, els desenvolupadors s’enfronten a un altre problema: dispersió. Hi ha moltes eines, molts serveis, molta documentació... repartits per tot arreu. On trobo la informació del meu servei? Com en creo un de nou seguint les normes? On és la documentació? Per unificar tot això en un sol lloc existeix Backstage: un portal del desenvolupador que s’ha convertit en l’estàndard de la indústria per construir Internal Developer Platforms.
El problema: el desenvolupador perdut entre mil eines
En una empresa gran amb molts serveis i eines, un desenvolupador (especialment un de nou) se sent perdut:
"Vull treballar en el meu servei, però... on és la seva documentació? (en una wiki? en el codi?) on veig si funciona bé? (en quin dashboard?) com creo un servei nou bé? (a qui pregunto?) quins serveis existeixen ja? (hi ha alguna cosa que pugui reutilitzar?) on són els golden paths? (com els faig servir?)" → informació dispersa en desenes de llocs = confusió i lentitud
Tota aquesta dispersió fa que els desenvolupadors perdin temps buscant, dupliquin feina (perquè no saben què existeix ja) i triguin molt a ser productius. Necessites un únic lloc que ho reuneixi tot. Això és Backstage.
Què és Backstage
Backstage és una plataforma de codi obert (creada originalment per Spotify) per construir un portal del desenvolupador: un únic lloc on els desenvolupadors troben tot el que necessiten per treballar —els seus serveis, la seva documentació, les seves eines, els seus golden paths— de manera unificada i ordenada.
┌─────────────── Backstage (portal del desenvolupador) ───────────────┐ │ 📋 Catàleg de serveis → quins serveis existeixen i de qui són │ │ 📚 Documentació → tota la doc en un lloc │ │ 🚀 Golden paths / plantilles → crear coses noves bé, fàcil │ │ 📊 Enllaços a dashboards → veure l’estat de cada servei │ │ 🔧 Eines integrades → tot accessible des d’aquí │ └─────────────────────────────────────────────────────────────────────┘
Analogia: Backstage és com el portal d’intranet únic i ben organitzat d’una empresa, però per a desenvolupadors. En lloc d’haver de recordar deu adreces diferents, buscar en wikis disperses i preguntar als companys «on és això?», entres en un sol portal i des d’aquí accedeixes ordenadament a tot: els teus projectes, la documentació, les eines, les guies per fer coses noves. És la «finestreta única» del desenvolupador, que posa ordre en el caos d’eines.
Què ofereix Backstage
- Catàleg de programari (què existeix i qui ho manté)
Backstage ofereix un catàleg de tots els serveis, aplicacions i components de l’empresa: què existeix, qui és responsable de cada cosa, com es relacionen. Això resol el «què hi ha ja?» i evita reinventar el que un altre equip ja ha construït. D’una ullada, veus el mapa del programari de l’organització.
- Plantilles per crear coses noves (els golden paths)
Backstage permet oferir plantilles (software templates) que implementen els golden paths (subcapítol 31.1): «vols crear un servei nou? Fes servir aquesta plantilla i obtindràs un amb tota l’estructura, la infraestructura (Terraform), els pipelines i les bones pràctiques ja muntats». És la manera d’oferir els camins daurats de manera accessible, des del portal.
Desenvolupador a Backstage: "crear servei nou" → tria una plantilla (golden path) → omple unes dades → obté un servei nou amb estructura, infra, CI/CD i bones pràctiques a punt
- Documentació centralitzada
Backstage reuneix la documentació de tots els serveis en un sol lloc (sovint al costat del propi codi), així que trobar-la és fàcil. S’ha acabat buscar en wikis disperses i desactualitzades.
- Integració d’eines
Backstage s’integra amb les eines que l’empresa ja fa servir (CI/CD, monitorització, cloud, el propi Service Catalog del subcapítol 31.2...), mostrant-ho tot de manera unificada. És extensible mitjançant plugins, així que cada empresa l’adapta a les seves eines.
Backstage com a cara de la Internal Developer Platform
Aquí s’uneix tot el capítol. Recorda els conceptes:
- Platform Engineering (subcapítol 31.1): construir una plataforma interna per als desenvolupadors.
- A aquesta plataforma se l’anomena Internal Developer Platform (IDP): el conjunt d’eines, golden paths i serveis que l’equip de plataforma ofereix als desenvolupadors.
- Backstage és, molt sovint, la cara visible (el portal) d’aquesta IDP: el lloc per on els desenvolupadors accedeixen a tot el que la plataforma ofereix.
Internal Developer Platform (IDP): tota la "maquinària" de plataforma ├── golden paths (31.1) ├── Service Catalog / productes aprovats (31.2) ├── mòduls Terraform, pipelines, eines... │ └── Backstage = el PORTAL per on els desenvolupadors accedeixen a tot
Backstage no substitueix les altres peces; les unifica en una experiència coherent per al desenvolupador.
Exemple del món real: una empresa amb 200 desenvolupadors i centenars de serveis tenia un caos: informació dispersa, gent que no sabia què existia ni com crear serveis bé. Implanten Backstage com a portal del desenvolupador. Ara, un desenvolupador nou entra a Backstage i veu: el catàleg de tots els serveis (i de qui és cadascun), la documentació de cadascun, i plantilles (golden paths) per crear un servei nou amb tota la infraestructura i bones pràctiques muntades en minuts. El que abans li portava setmanes a un nouvingut —entendre el panorama i poder contribuir— ara li porta dies. I es deixa de duplicar feina, perquè tothom veu què existeix ja. Backstage va convertir el caos d’eines en una experiència ordenada i productiva.
El que has de recordar
- En empreses grans, els desenvolupadors es perden entre mil eines, serveis i documentació dispersos, perdent temps i duplicant feina. Necessiten un únic lloc que ho reuneixi tot.
- Backstage és una plataforma open source (creada per Spotify) per construir un portal del desenvolupador: un únic lloc amb els serveis, la documentació, les eines i els golden paths, de manera unificada. Com el portal d’intranet únic (la «finestreta única») del desenvolupador.
- Ofereix: un catàleg de programari (què existeix i qui ho manté), plantilles que implementen els golden paths (crear coses noves bé, fàcil), documentació centralitzada i integració amb les eines existents (extensible amb plugins).
- Sol ser la cara visible (el portal) de la Internal Developer Platform (IDP): el lloc per on els desenvolupadors accedeixen a tota la plataforma (golden paths, Service Catalog, mòduls...). No substitueix aquestes peces; les unifica.
A l’últim subcapítol del capítol (i de la Part VII) tancarem la idea amb una visió clau: tractar els mòduls de Terraform com un producte intern, amb la mentalitat de producte que sosté tot el Platform Engineering.
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
