Desenvolupament d'aplicacions natives al núvol

5 preguntas de exámenes anteriores · 8 min

Elaboración propia: la fuente es de pago y no se reproduce

Alcance decidido por nosotros: el enunciado oficial no acota la materia

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:

1. Codi base únic amb seguiment de versions i múltiples desplegaments.
2. Dependències declarades i aïllades explícitament.
3. Configuració a l'entorn, mai al codi.
4. Serveis de suport (backing services) tractats com a recursos connectables.
5. Construir, alliberar, executar: etapes estrictament separades.
6. Processos d'execució sense estat i sense compartir res.
7. Vinculació de ports: el servei s'exporta pel seu propi port.
8. Concurrència mitjançant el model de processos: escalar afegint processos.
9. Descartabilitat: arrencada ràpida i aturada elegant.
10. Paritat entre desenvolupament i producció: entorns tan semblants com sigui possible.
11. Registres (logs) com a flux d'esdeveniments cap a la sortida estàndard, no com a fitxers gestionats per l'aplicació.
12. Processos d'administració executats com a processos puntuals.

S'hi afegeixen sovint tres factors més, centrats en el desenvolupament:

13. 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.
14. Telemetria: instrumentar l'aplicació des del disseny, no afegir-la a posteriori.
15. 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

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, Bash un llenguatge d'ús general i kubectl nomé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.

Practicar este tema