Dissenyeu programari per a un entorn cloud native

Definiu el comportament que necessiteu

Les pràctiques cloud native faciliten un desenvolupament i una operació repetibles en entorns públics, privats o híbrids. CNCF posa l’accent en sistemes que continuïn sent gestionables, observables i resilients mentre canvien. Els contenidors i l’orquestració poden donar suport a aquest enfocament. No acrediten totes aquestes propietats per si sols.

Comenceu amb un servei fictici d’informes. Una eina d’IA crea un endpoint, un procés de treball i una imatge de contenidor. Una demostració produeix el PDF correcte. Abans de producció, l’equip ha de respondre una altra pregunta: què passa quan la plataforma substitueix el procés de treball durant una tasca?

És una qüestió de disseny de l’aplicació i també d’infraestructura. Un reinici pot restaurar un procés i alhora perdre la feina que no havia acabat.

Separeu el procés de l’estat persistent

El prototip conserva les tasques en cua i els informes completats al disc del contenidor. Substituir el contenidor pot eliminar tots dos. Afegir més processos de treball també pot produir respostes diferents segons quin rebi la petició.

El disseny revisat utilitza un magatzem persistent de tasques i un magatzem d’objectes aprovat. Una petició registra una identitat de tasca. Un procés de treball assumeix la tasca, crea el resultat i registra on és. Les comprovacions d’accés continuen aplicant-se quan un usuari descarrega l’informe.

Manteniu els secrets fora de la imatge. Proporcioneu-los a través del sistema de secrets aprovat. Registreu quins canvis de configuració requereixen una versió nova o reiniciar un procés.

Dissenyeu els reintents abans d’afegir processos de treball

Suposeu que el procés desa un PDF i després s’atura abans de confirmar la tasca. La cua torna a lliurar-la. Un segon intent no pot crear un segon càrrec al client ni enviar missatges contradictoris de compleció.

Utilitzeu una operació idempotent quan sigui adequat. Repetir la mateixa petició lògica ha de conservar l’efecte previst. Definiu una identitat estable de petició, registreu el resultat de manera persistent i comproveu què passa a cada punt de fallada. AWS descriu aquesta tècnica a la seva guia de reintents segurs.

Els reintents també necessiten límits. Utilitzeu un temps d’espera màxim, un límit de reintents i un retard que eviti peticions repetides simultànies. Conserveu la feina fallida per inspeccionar-la en lloc de reintentar-la indefinidament.

Feu que es pugui revisar l’estat desitjat

Una configuració declarativa indica el desplegament previst. Un controlador treballa per mantenir aquest estat. Per exemple, un Deployment de Kubernetes gestiona rèpliques de l’aplicació i actualitzacions controlades. L’aplicació encara ha de gestionar correctament la substitució.

Versioneu la configuració d’infraestructura i d’aplicació. Reviseu els canvis mitjançant el procés normal de lliurament. Observeu la compleció real de tasques, el temps que porten en cua, les fallades i els límits de les dependències. Un procés en execució encara pot ser incapaç de produir un informe.

Trieu una plataforma que l’equip pugui operar

Cloud native no exigeix convertir totes les aplicacions en microserveis. Una aplicació modular sobre un entorn d’execució gestionat pot complir els seus requisits. Més serveis introdueixen més interfícies, decisions de desplegament i feina operativa.

Doneu a l’agent de desenvolupament el contracte tècnic real de la plataforma: entorn d’execució admès, mecanisme d’identitat, serveis de dades, regles de desplegament i evidències requerides. Proveu el comportament davant d’interrupcions i substitucions, a més de les peticions satisfactòries. Continueu amb la disponibilitat i els límits de fallada.