Definiu la infraestructura més enllà d'un prototip

Comenceu pel sistema generat

Considereu una plataforma fictícia de prototips. Crea un contenidor web, una base de dades PostgreSQL gestionada i un URL públic. El flux de treball funciona correctament amb registres d’exemple. És un resultat útil: les persones poden avaluar la funcionalitat abans de finançar una implementació més gran.

Ara l’empresa vol emmagatzemar contractes confidencials i utilitzar el seu proveïdor d’identitat d’empleats. El sistema requerit ha canviat. Desplegar un contenidor amb èxit no acredita l’autorització, el tractament de dades aprovat, la capacitat de recuperació ni la responsabilitat del servei.

Les plataformes de desenvolupament ofereixen capacitats diferents. Inspeccioneu el servei i la configuració reals. No suposeu que totes les eines de prototipatge tenen els mateixos límits ni que un nom de núvol conegut satisfà la política de l’empresa.

Feu set preguntes de producció

Les respostes poden utilitzar serveis empresarials existents. No cal crear un sistema d’identitat ni una plataforma de monitoratge nous per a cada aplicació. Connecteu-la a les capacitats aprovades i registreu les mancances que queden.

AWS Well-Architected considera conjuntament l’operació, la seguretat, la fiabilitat, el rendiment, el cost i la sostenibilitat. Recorda que un desplegament que funciona és només una part d’una avaluació d’arquitectura. Llegiu el marc.

Definiu els límits entre entorns

Identifiqueu els recursos de desenvolupament, proves i producció. Definiu quines identitats poden travessar aquests límits. No copieu registres de producció a un entorn de previsualització per comoditat sense un procés de tractament aprovat.

Inspeccioneu tant les connexions sortints com l’accés entrant. Una base de dades privada encara pot enviar dades a un servei públic de registres d’activitat a través de l’aplicació. Les crides al model de l’agent de programació són un altre flux que cal avaluar per separat.

Registreu qui és responsable del compte de núvol, el DNS, el certificat, les claus de xifratge i la relació de facturació. Un projecte que depèn del compte personal d’un empleat que marxa té un problema de responsabilitat, encara que el codi de l’aplicació estigui disponible.

Proveu el repartiment de responsabilitats

Un proveïdor de base de dades gestionada pot operar el servei subjacent mentre la vostra organització controla els usuaris, l’accés a les dades, els canvis d’esquema i la configuració de conservació. El repartiment exacte depèn del servei i del contracte. Demaneu-lo explícitament.

Per a l’aplicació de contractes, feu un exercici fictici de restauració. Mesureu el temps real de recuperació i identifiqueu la possible pèrdua de dades. Compareu el resultat amb el requisit de negoci. Una casella amb l’etiqueta «còpies de seguretat activades» no és la mateixa evidència.

Proveu també la retirada d’accés. Elimineu un empleat fictici de la font d’identitat i verifiqueu el canvi d’accés previst. Incloeu en el disseny les sessions actives, els rols d’administració i les identitats d’automatització.

Connecteu la infraestructura amb el sistema de lliurament

Les definicions d’infraestructura, la configuració d’entorns, els pipelines i el codi de l’aplicació necessiten canvis coordinats. Un agent ha de planificar segons l’entorn de destinació real. Altrament, pot generar un desplegament que entri en conflicte amb els requisits de xarxa, identitat o responsabilitat.

Aquí és on es troben l’enginyeria de plataformes i una fàbrica de programari. La plataforma proporciona capacitats amb suport i límits. El sistema de lliurament els ha d’utilitzar, produir evidències i conservar un traspàs clar a operacions. Continueu amb l’enginyeria de plataformes.