Definiți infrastructura de dincolo de prototip

Începeți cu sistemul generat

Luați în considerare o platformă fictivă de prototipare. Creează un container web, o bază de date PostgreSQL gestionată și un URL public. Fluxul de lucru rulează corect cu înregistrări de exemplu. Este un rezultat util: oamenii pot evalua funcționalitatea înainte de a finanța o implementare mai amplă.

Acum compania dorește să stocheze contracte confidențiale și să folosească furnizorul de identitate al angajaților. Sistemul necesar s-a schimbat. Instalarea reușită a unui container nu dovedește autorizarea, prelucrarea aprobată a datelor, posibilitatea de recuperare sau asumarea responsabilității pentru serviciu.

Platformele de dezvoltare oferă capabilități diferite. Inspectați serviciul și configurația efective. Nu presupuneți că toate instrumentele de prototipare au aceleași limite sau că un nume cloud familiar satisface politica companiei.

Puneți șapte întrebări pentru producție

Răspunsurile pot folosi servicii enterprise existente. Nu trebuie să construiți un sistem nou de identitate sau o platformă nouă de monitorizare pentru fiecare aplicație. Conectați-vă la capabilitățile aprobate și consemnați lipsurile rămase.

AWS Well-Architected tratează împreună operarea, securitatea, fiabilitatea, performanța, costul și sustenabilitatea. Este un reper util: o instalare funcțională este doar o parte a evaluării arhitecturii. Citiți cadrul.

Definiți limitele dintre medii

Identificați resursele de dezvoltare, testare și producție. Definiți ce identități pot traversa aceste limite. Nu copiați înregistrări din producție într-un mediu comod de previzualizare fără un proces aprobat de prelucrare.

Inspectați conexiunile de ieșire, nu doar accesul de intrare. O bază de date privată poate totuși alimenta un serviciu public de logare prin aplicație. Apelurile agentului de programare către model sunt un alt flux de evaluat separat.

Consemnați cine deține contul cloud, DNS-ul, certificatul, cheile de criptare și relația de facturare. Un proiect care depinde de contul personal al unui angajat care pleacă are o problemă de responsabilitate, chiar dacă este disponibil codul aplicației.

Testați împărțirea responsabilităților

Furnizorul unei baze de date gestionate poate opera serviciul de bază, în timp ce organizația controlează utilizatorii, accesul la date, schimbările de schemă și setările de păstrare. Împărțirea exactă depinde de serviciu și contract. Cereți-o explicit.

Pentru aplicația de contracte, executați un exercițiu fictiv de restaurare. Măsurați timpul real de recuperare și identificați posibila pierdere de date. Comparați rezultatul cu cerința afacerii. O bifă etichetată „copii de siguranță activate” nu este aceeași dovadă.

Testați și retragerea accesului la plecarea din organizație. Eliminați un angajat fictiv din sursa identității și verificați schimbarea intenționată a accesului. Includeți în proiectare sesiunile active, rolurile de administrator și identitățile automatizărilor.

Conectați infrastructura la sistemul de livrare

Definițiile infrastructurii, configurația mediilor, pipeline-urile și codul aplicației necesită modificări coordonate. Un agent trebuie să planifice în funcție de mediul țintă real. Altfel, poate genera o instalare care contrazice cerințele de rețea, identitate sau responsabilitate.

Aici se întâlnesc platform engineering și fabrica de software. Platforma oferă capabilități susținute și limite. Sistemul de livrare trebuie să le folosească, să producă dovezi și să păstreze o predare operațională clară. Continuați cu platform engineering.