Una aplicació cloud-native no és simplement una aplicació que s'executa al núvol: és una aplicació dissenyada per aprofitar el núvol, és a dir, pensada des del principi per escalar horitzontalment, tolerar fallades, desplegar-se de forma freqüent i automatitzada, i executar-se en entorns dinàmics (contenidors, orquestradors, plataformes gestionades). Per aconseguir-ho, la comunitat ha consolidat una sèrie de patrons i principis provats que eviten reinventar la roda i els errors típics. Aquesta lliçó recull els més importants: la metodologia dels 12 factors, els patrons de contenidors sidecar i ambassador, el patró de migració strangler fig, l'autoescalat i la configuració externalitzada. Dominar-los et permet dissenyar sistemes resilients, portables i operables, que són just les qualitats que el núvol premia.

1. La metodologia dels 12 factors (resum).
2. Patró Sidecar.
3. Patró Ambassador.
4. Patró Strangler Fig (estrangulador).
5. Autoescalat (horitzontal i vertical).
6. Configuració externalitzada.
7. Errors comuns i consells.
8. Exercicis i solucions.

The Twelve-Factor App és un conjunt de bones pràctiques per construir aplicacions SaaS portables i escalables. Aquí un resum agrupat:

Els tres que més impacte tenen en arquitectura cloud-native: (3) configuració a l'entorn (ho veurem en detall), (6) processos sense estat (permet escalar i reemplaçar instàncies lliurement) i (9) descartabilitat (les instàncies han de poder morir i néixer sense drama, base de la resiliència i l'autoescalat).

El patró sidecar (literalment, el "sidecar" d'una motocicleta) consisteix a desplegar un contenidor auxiliar al costat del contenidor principal de l'aplicació, al mateix Pod, compartint cicle de vida, xarxa i volums. El sidecar afegeix funcionalitat transversal (logging, proxy, seguretat, sincronització) sense modificar l'aplicació principal.

Explicació: el Pod té dos contenidors. aplicacio escriu els seus logs a /var/log/app. El sidecar log-shipper (Fluent Bit) llegeix d'aquest mateix volum compartit (emptyDir) i els envia a un sistema central. L'aplicació no sap res de com s'exporten els seus logs: aquesta responsabilitat transversal viu al sidecar. És la base de les service meshes com Istio, on un sidecar proxy gestiona tota la comunicació de xarxa.

El patró ambassador (ambaixador) és un tipus especial de sidecar que actua com a proxy de sortida: l'aplicació parla amb l'ambaixador com si fos el servei remot, i l'ambaixador s'encarrega dels detalls de la connexió externa (reintents, circuit breaker, xifratge TLS, sharding, monitoratge). Així, l'aplicació se simplifica i la lògica de xarxa es centralitza.

Explicació del diagrama: l'aplicació es connecta sempre a localhost (a l'ambaixador), ignorant on és realment el servei remot. L'ambaixador resol la connexió real, afegeix reintents, xifratge i enrutament. Diferència clau amb el sidecar genèric: el sidecar sol afegir funcions que acompanyen l'app (logging, mètriques); l'ambassador s'especialitza a gestionar les connexions sortints cap a serveis externs.

El patró strangler fig (figuera estranguladora, per la planta que envolta i reemplaça l'arbre que la sosté) és l'estratègia recomanada per migrar un sistema monolític heretat a microserveis de forma incremental, sense reescriure-ho tot de cop (cosa que seria arriscadíssima). La idea: col·loques un proxy/enrutador davant del monòlit i vas redirigint funcionalitats, una a una, cap a nous serveis, fins que el monòlit queda buit i es retira.

Explicació: el router rep tot el trànsit. La funcionalitat de "pagaments" ja s'ha extret a un microservei nou, així que el router envia /pagaments al microservei i tota la resta segueix anant al monòlit. Amb el temps, més rutes migren cap al costat nou fins a buidar el monòlit. Avantatge: migres amb risc controlat, podent revertir cada pas, i lliures valor de forma contínua en lloc d'en una arriscada migració "big bang".

L'autoescalat ajusta automàticament la capacitat segons la demanda. Hi ha dues dimensions:

A Kubernetes, el Horizontal Pod Autoscaler (HPA) ajusta el nombre de Pods segons mètriques:

Explicació: l'HPA vigila el Deployment lamevaapp-deployment. Manté entre 2 i 10 rèpliques i el seu objectiu és que l'ús mitjà de CPU voregi el 70%. Si la CPU puja per sobre, crea més Pods; si baixa, els redueix (sense baixar de 2). Perquè això funcioni, l'aplicació ha de ser sense estat (factor 6 i 9 dels 12 factors): qualsevol rèplica ha de poder atendre qualsevol petició.

El factor 3 dels 12 factors diu: la configuració no va al codi. Les credencials, URLs i paràmetres que canvien entre entorns (desenvolupament, proves, producció) s'han d'injectar des de fora, normalment com a variables d'entorn o fitxers muntats. Així, la mateixa imatge immutable es promociona entre entorns canviant només la configuració, i no hi ha secrets hardcodejats al repositori.

A Kubernetes això es fa amb ConfigMap (configuració no sensible) i Secret (dades sensibles):

Explicació: el ConfigMap guarda paràmetres no sensibles (LOG_LEVEL, feature flags). Al Deployment, envFrom.configMapRef injecta totes les seves claus com a variables d'entorn del contenidor. La contrasenya de base de dades s'obté d'un Secret mitjançant secretKeyRef, de manera que no apareix en text pla al manifest de desplegament. La imatge lamevaapp:1.0 no canvia entre entorns; només canvien el ConfigMap i el Secret. Recorda que els Secret de Kubernetes estan només codificats en base64 per defecte: per a dades veritablement sensibles, convé un gestor de secrets dedicat i validar l'enfocament amb l'equip de seguretat.

• Guardar estat a la instància. Sessions o fitxers en memòria local trenquen l'escalat horitzontal: fes servir emmagatzematge extern (BD, memòria cau, emmagatzematge d'objectes). És el factor 6.
• Configuració hardcodejada o secrets al repositori. Externalitza sempre la configuració. Un secret pujat a Git és un incident de seguretat.
• Migració big bang. Reescriure un monòlit de zero sol acabar malament. Fes servir el patró strangler per migrar de forma incremental i reversible.
• Autoescalar una app amb estat. Si l'app no és stateless, afegir rèpliques no resol la càrrega i pot corrompre dades.
• Abusar de sidecars. Cada sidecar consumeix recursos al Pod; afegeix-los quan aportin valor transversal clar, no per moda.
• No dissenyar per a la descartabilitat. Implementa aturada elegant (atendre el SIGTERM, tancar connexions) perquè l'escalat i els desplegaments no tallin peticions a mitges.

1. Per què el principi "processos sense estat" (factor 6) és un requisit previ perquè l'autoescalat horitzontal funcioni bé?
2. El teu equip ha de modernitzar un gran monòlit d'assegurances sense poder aturar el servei. Descriu com aplicaries el patró strangler fig en els primers passos.
3. Diferencia amb un exemple el patró sidecar del patró ambassador.

1. Perquè en escalar horitzontalment el trànsit es reparteix entre moltes rèpliques intercanviables, i qualsevol petició pot caure en qualsevol rèplica. Si una rèplica guardés estat local (la sessió de l'usuari, dades en memòria), les peticions següents del mateix usuari podrien anar a una altra rèplica que no té aquest estat, provocant errors. Amb processos sense estat, totes les rèpliques són equivalents i es poden afegir, treure o reemplaçar lliurement.
2. Passos inicials: (1) col·locar un router/façana davant del monòlit que rebi tot el trànsit sense canviar el comportament; (2) triar una funcionalitat acotada i de baix risc (per exemple, consulta d'un catàleg) i extreure-la a un nou servei; (3) configurar el router perquè aquesta ruta vagi al servei nou i la resta segueixi al monòlit; (4) verificar, mesurar i, si tot va bé, repetir amb la funcionalitat següent. Cada pas és reversible.
3. Sidecar: contenidor auxiliar que acompanya l'app aportant una funció transversal; exemple, un log-shipper que recull i envia els logs de l'aplicació. Ambassador: sidecar especialitzat que actua de proxy de sortida cap a serveis externs; exemple, un proxy al qual l'app es connecta per localhost i que gestiona reintents i TLS contra una base de dades remota.

Has recorregut els patrons que defineixen una arquitectura cloud-native: la disciplina dels 12 factors (sense estat, configuració externa, descartabilitat), els sidecars i ambassadors per afegir capacitats sense tocar l'app, el strangler fig per migrar monòlits amb seguretat, l'autoescalat per adaptar-se a la demanda i la configuració externalitzada amb ConfigMaps i Secrets. Tots comparteixen un objectiu: aplicacions resilients, portables i operables. A l'última lliçó del mòdul veurem com crear i gestionar tota aquesta infraestructura de forma reproduïble i versionada amb la Infraestructura com a Codi (IaC).