Opcions d'impressió

Mida
Compacta · 9 pt Normal · 10,5 pt Gran · 12,5 pt
Els meus apunts
No imprimir-los Incloure'ls a cada paràgraf

El navegador numera les pàgines des del seu propi quadre d'imprimir: activa-ho allà si les vols.

Els requadres grisos només surten si deixes marcada la casella «Gràfics de fons» del quadre d'imprimir.

opos

Desenvolupament d'aplicacions natives al núvol

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:


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:

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


6. Seguretat: els 4C

Model de seguretat natiu al núvol en quatre capes concèntriques: Cloud → Cluster → Container → Code.

Model de seguretat dels 4CQuatre capes concèntriques: el núvol conté el clúster, que conté el contenidor, que conté el codi.CloudClústerContenidorCodi

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


Claus d'examen

Per recordar

Fonts d'aquest tema