Définir l’infrastructure au-delà du prototype

Partir du système généré

Prenons une plateforme de prototypage fictive. Elle crée un conteneur web, une base PostgreSQL managée et une URL publique. Le processus fonctionne correctement avec des données d’exemple. Ce résultat est utile : les personnes peuvent évaluer la fonctionnalité avant de financer une implémentation plus large.

L’entreprise souhaite maintenant stocker des contrats confidentiels et utiliser son fournisseur d’identité des salariés. Le système requis a changé. Un déploiement de conteneur réussi ne garantit ni les autorisations, ni un traitement des données approuvé, ni la capacité de reprise, ni la responsabilité du service.

Les plateformes de développement offrent des capacités différentes. Examinez le service et sa configuration réels. Ne supposez pas que tous les outils de prototypage ont les mêmes limites, ni qu’un nom de cloud connu satisfait les règles de l’entreprise.

Poser sept questions de production

Les réponses peuvent s’appuyer sur des services d’entreprise existants. Vous n’avez pas besoin de construire un nouveau système d’identité ou de supervision pour chaque application. Utilisez les capacités approuvées et consignez les lacunes restantes.

AWS Well-Architected examine ensemble l’exploitation, la sécurité, la fiabilité, les performances, les coûts et la durabilité. Cela rappelle utilement qu’un déploiement fonctionnel n’est qu’une partie de l’évaluation d’architecture. Lire le référentiel.

Définir les limites entre environnements

Identifiez les ressources de développement, de test et de production. Définissez quelles identités peuvent franchir ces limites. Ne copiez pas de données de production dans un environnement de prévisualisation pratique sans procédure de traitement approuvée.

Examinez les connexions sortantes autant que les accès entrants. Une base privée peut malgré tout alimenter un service public de journalisation par l’intermédiaire de l’application. Les appels au modèle de l’agent de développement constituent un autre flux à évaluer séparément.

Consignez qui possède le compte cloud, le DNS, le certificat, les clés de chiffrement et la relation de facturation. Un projet dépendant du compte personnel d’un salarié qui part pose un problème de responsabilité, même si le code de l’application est disponible.

Tester la répartition des responsabilités

Un fournisseur de base de données managée peut exploiter le service sous-jacent pendant que votre organisation contrôle les utilisateurs, les accès aux données, les changements de schéma et les paramètres de conservation. La répartition exacte dépend du service et du contrat. Demandez-la explicitement.

Pour l’application de contrats, réalisez un exercice fictif de restauration. Mesurez le temps réel de reprise et identifiez la perte de données possible. Comparez le résultat à l’exigence métier. Une case « sauvegardes activées » ne constitue pas la même preuve.

Testez aussi le départ d’un salarié. Retirez un salarié fictif de la source d’identité et vérifiez le changement d’accès prévu. Incluez les sessions actives, les rôles d’administration et les identités d’automatisation dans la conception.

Relier l’infrastructure au système de livraison

Les définitions d’infrastructure, la configuration des environnements, les pipelines et le code applicatif nécessitent des changements coordonnés. Un agent doit planifier en fonction de l’environnement cible réel. Sinon, il peut générer un déploiement incompatible avec les exigences de réseau, d’identité ou de responsabilité.

C’est le point de rencontre entre le platform engineering et la software factory. La plateforme fournit des capacités prises en charge et des limites. Le système de livraison doit les utiliser, produire des preuves et préserver un transfert clair vers l’exploitation. Poursuivez avec le platform engineering.