Desenvolupament d'aplicacions natives al núvol
Elaboració pròpia: la font és de pagament i no es reprodueix
Abast decidit per nosaltres: l'enunciat oficial no acota la matèria
Enunciat oficial. Desenvolupament d'aplicacions natives al núvol.
1. Definició
Cloud native (definició de la CNCF, Cloud Native Computing Foundation): les tècniques natives al núvol permeten a les organitzacions construir i executar aplicacions escalables en entorns moderns i dinàmics com ara núvols públics, privats i híbrids. Exemples d'aquest enfocament són els contenidors, les malles de serveis, els microserveis, la infraestructura immutable i les API declaratives. Aquestes tècniques permeten sistemes desacoblats que són resilients, gestionables i observables. Combinades amb una automatització robusta, permeten als enginyers fer canvis d'alt impacte de manera freqüent i predictible amb un esforç mínim.
Natiu al núvol ≠ al núvol. Traslladar una aplicació monolítica a una màquina virtual d'un proveïdor (lift and shift) és estar al núvol, però no és natiu al núvol: no n'aprofita l'elasticitat ni els serveis gestionats.
Característica essencial d'una aplicació nativa al núvol: està dissenyada per ser escalable elàsticament i resilient, amb components desacoblats i sense estat, desplegats en contenidors i gestionats de manera automatitzada i declarativa. Els seus trets:
- Modularitat: microserveis o components desacoblats.
- Sense estat (stateless): l'estat viu fora del procés (base de dades, cau, magatzem d'objectes), de manera que qualsevol instància pot atendre qualsevol petició i es pot destruir i recrear lliurement.
- Empaquetament en contenidors i execució orquestrada.
- Escalat horitzontal automàtic segons la demanda.
- Resiliència dissenyada: assumeix que els components fallaran.
- Automatització completa del desplegament i de l'operació.
- Observabilitat integrada des del disseny.
- API declaratives i infraestructura com a codi.
2. Els dotze factors
Metodologia The Twelve-Factor App (Heroku), la referència per construir aplicacions natives al núvol:
- Codi base únic amb seguiment de versions i múltiples desplegaments.
- Dependències declarades i aïllades explícitament.
- Configuració a l'entorn, mai al codi.
- Serveis de suport (backing services) tractats com a recursos connectables.
- Construir, alliberar, executar: etapes estrictament separades.
- Processos d'execució sense estat i sense compartir res.
- Vinculació de ports: el servei s'exporta pel seu propi port.
- Concurrència mitjançant el model de processos: escalar afegint processos.
- Descartabilitat: arrencada ràpida i aturada elegant.
- Paritat entre desenvolupament i producció: entorns tan semblants com sigui possible.
- Registres (logs) com a flux d'esdeveniments cap a la sortida estàndard, no com a fitxers gestionats per l'aplicació.
- Processos d'administració executats com a processos puntuals.
S'hi afegeixen sovint tres factors més, centrats en el desenvolupament:
- API primer: es dissenya i es documenta el contracte de l'API (OpenAPI) abans d'implementar-la, de manera que altres equips o serveis consumidors poden desenvolupar-hi en paral·lel contra un contracte estable.
- Telemetria: instrumentar l'aplicació des del disseny, no afegir-la a posteriori.
- Autenticació i autorització: cada servei verifica identitat i permisos explícitament, sense assumir que la xarxa interna ja és de confiança.
3. Els pilars tecnològics
3.1 Contenidors i orquestració
Docker/OCI (Open Container Initiative) per empaquetar i Kubernetes per orquestrar → tema 41.
3.2 Microserveis
Descomposició en serveis petits, autònoms i desplegables per separat → tema 48.
3.3 Infraestructura immutable i infraestructura com a codi
Infraestructura immutable: els components no es modifiquen un cop desplegats; per canviar-los es construeix una instància nova a partir de la imatge actualitzada i es reemplaça l'antiga. Elimina la deriva de configuració, fa els desplegaments reproduïbles, simplifica el retorn i millora la seguretat.
IaC: la infraestructura es declara en fitxers versionats (Terraform/OpenTofu, Pulumi, Crossplane). Aquest és el concepte d'infraestructura que s'implementa habitualment en una aplicació natiu-núvol i que s'ha preguntat a l'examen.
3.4 Automatització i CI/CD
Pipeline complet fins a producció, amb GitOps com a model dominant → tema 41.
3.5 Serverless i FaaS
FaaS (Function as a Service): el proveïdor executa funcions en resposta a esdeveniments; no hi ha servidors a gestionar, l'escalat és automàtic —fins a zero— i es paga per execució i temps de còmput. AWS (Amazon Web Services) Lambda, Azure Functions, Google Cloud Functions, Knative, OpenFaaS.
Limitacions: arrencada en fred (cold start), límits de temps d'execució i de memòria, dificultat de depuració, i bloqueig de proveïdor elevat.
3.6 Malla de serveis (service mesh)
Capa d'infraestructura que gestiona la comunicació entre serveis: encaminament, balanceig, reintents, tallacircuits, mTLS, autorització i telemetria, sense tocar el codi de l'aplicació. Istio, Linkerd, Consul Connect.
3.7 Observabilitat
Mètriques, registres i traces amb OpenTelemetry → tema 23.
4. Patrons de disseny natius al núvol
| Patró | Funció |
|---|---|
| Tallacircuits (circuit breaker) | atura les crides a un servei que falla per evitar l'efecte dominó, i reintenta passat un temps |
| Reintent amb retrocés exponencial i jitter | reintenta amb esperes creixents i aleatoritzades |
| Mampara (bulkhead) | aïlla recursos perquè la fallida d'un component no consumeixi tots els recursos |
| Limitació de ritme (rate limiting) i contrapressió | protegeix davant sobrecàrrega |
| Degradació elegant | el servei continua amb funcionalitat reduïda en lloc de caure |
| Sidecar | funcionalitat transversal en un contenidor adjunt |
| Cau distribuïda | Redis, Memcached |
| Cua de missatges i esdeveniments | desacoblament temporal: Kafka, RabbitMQ, SQS (Simple Queue Service) |
| Prova de salut (health check) | liveness i readiness per a l'orquestrador |
| Escalat automàtic | horitzontal segons mètriques |
| Enginyeria del caos | injectar fallides deliberadament per validar la resiliència |
Persistència: poliglota —cada servei tria el magatzem que li convé—, base de dades per servei, i patrons per a la consistència distribuïda: saga, transactional outbox, CQRS (Command Query Responsibility Segregation) i event sourcing → tema 48.
5. Beneficis i costos
Beneficis: elasticitat i pagament per ús, resiliència, velocitat de lliurament, escalabilitat independent per component, aprofitament de serveis gestionats (bases de dades, cues, IA (intel·ligència artificial)) i portabilitat si es fa sobre estàndards oberts.
Costos i riscos:
- Complexitat operativa molt superior: cal maduresa en observabilitat, automatització i seguretat.
- Cost econòmic descontrolat si no hi ha FinOps → tema 27.
- Bloqueig de proveïdor quan s'usen serveis propietaris; es mitiga amb Kubernetes, OpenTelemetry i estàndards oberts.
- Superfície d'atac més gran: més components, més xarxa, més secrets.
- No sempre val la pena: per a una aplicació petita i estable, un monòlit ben fet és millor.
6. Seguretat: els 4C
Model de seguretat natiu al núvol en quatre capes concèntriques: Cloud → Cluster → Container → Code.
- Núvol: configuració segura del compte, xarxes, IAM (Identity and Access Management), xifratge en repòs.
- Clúster: RBAC (Role-Based Access Control), NetworkPolicies, admissió de polítiques, actualització.
- Contenidor: imatges mínimes, sense root, escaneig i signatura, secrets fora de la imatge.
- Codi: SAST (Static Application Security Testing), SCA (Software Composition Analysis), gestió de dependències, TLS (Transport Layer Security), validació d'entrada.
Zero Trust (NIST SP (Special Publication) 800-207): no es confia en cap component per la seva ubicació de xarxa; cada petició s'autentica i s'autoritza. A l'entorn natiu al núvol es materialitza en mTLS entre serveis i identitats de càrrega de treball: SPIFFE (Secure Production Identity Framework For Everyone) i SPIRE (SPIFFE Runtime Environment).
7. Al sector públic
- Portabilitat i reversibilitat com a requisit contractual (LCSP i Mesura de digitalització oberta): Kubernetes i els estàndards oberts són la millor defensa contra el bloqueig.
- Sobirania de les dades i ubicació del tractament → tema 60.
- ENS: la categorització del sistema determina les mesures; l'ús de serveis de núvol exigeix el compliment del perfil de compliment específic per a serveis al núvol del CCN (Centre Criptològic Nacional) i la conformitat del proveïdor.
- Protecció de dades: transferències internacionals, encarregat del tractament i contracte de l'RGPD, art. 28.
- FinOps i el pas de CAPEX (Capital Expenditure, despesa d'inversió) a OPEX (Operating Expenditure, despesa operativa), amb l'impacte pressupostari del canvi de capítol → tema 27.
Claus d'examen
- La característica essencial que més es pregunta és l'escalat i la recuperació automàtics: davant quatre opcions, les altres tres neguen sempre algun tret cloud native (servidor físic, no escala, només Windows) (TS-TIC 2025 específic, p. 50; TS-TIC 2025 pràctica, s3-p8).
- El paradigma arquitectònic típic són els microserveis, mai el monolític ni el client-servidor tradicional (TS-TIC 2025 pràctica, s3-p9).
- Infraestructura immutable = es reemplacen els servidors, no es modifiquen. El parany és colar-hi «es modifiquen manualment» com a distractor (TS-TIC 2025 pràctica, s3-p10).
- IaC és el concepte que fa idèntics i automatitzats els entorns de desenvolupament, proves i producció; ni el serverless ni un patró de comunicació com l'EDA (Event-Driven Architecture) ho són (TS-TIC 2025 pràctica, s3-p6).
- Ansible és l'eina de referència per a «desplegament i configuració de tota mena d'infraestructura a partir de codi»:
YAMLés un format,Bashun llenguatge d'ús general ikubectlnomés val per a Kubernetes (TS-TIC 2023 pràctica, s4-p2).
Per recordar
- Natiu al núvol ≠ al núvol: el lift and shift no ho és.
- Característiques essencials: desacoblament, sense estat, contenidors, escalat elàstic automàtic, resiliència, automatització i observabilitat.
- Dotze factors: configuració a l'entorn, processos sense estat, logs com a flux, separació build/release/run, descartabilitat.
- Infraestructura immutable: no es modifica, es reemplaça; elimina la deriva de configuració. Es declara amb IaC.
- Serverless/FaaS: escala fins a zero, es paga per execució; problemes d'arrencada en fred i bloqueig de proveïdor.
- Patrons de resiliència: tallacircuits, reintent amb retrocés, mampara, degradació elegant, limitació de ritme.
- Seguretat 4C: Cloud, Cluster, Container, Code, amb Zero Trust i mTLS.
- El paradigma arquitectònic habitual de les aplicacions natives al núvol són els microserveis.
Fonts d'aquest tema
- NIST SP 800-207, Zero Trust Architecture — https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf
- Llei 9/2017, de contractes del sector públic — https://www.boe.es/buscar/act.php?id=BOE-A-2017-12902
- Mesura de govern per a la digitalització oberta: programari lliure i desenvolupament àgil de serveis — https://ajuntament.barcelona.cat/digital/sites/default/files/2023-10/le_mesuradegovern_v2.pdf
- RD 311/2022, pel qual es regula l'Esquema Nacional de Seguretat — https://www.boe.es/buscar/act.php?id=BOE-A-2022-7191
- Reglament (UE) 2016/679, general de protecció de dades — https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX:32016R0679