Trop de systèmes mélangent ces éléments. Un compte de service, un rôle cloud, une limite d’autorisations et une décision d’autorisation d’application deviennent un seul et même désordre. Cela fonctionne, mais seulement à un seul endroit. Une bonne architecture de sortie rend l’identité compréhensible en dehors du fournisseur. Qui est l’utilisateur ? Quelle est la charge de travail ? A quoi peut-il accéder ? Où est définie cette politique ? Ces règles peuvent-elles être représentées ailleurs sans procéder à une ingénierie inverse de l’ensemble de l’application ? Si la réponse est non, le système n’est pas portable.
Les données sont le vrai piège
Le calcul est généralement plus facile à déplacer que les données. Les données présentent des problèmes de gravité, de gouvernance, de coût et de format. Les entreprises adorent les bases de données gérées, les magasins d’objets, les plateformes d’analyse et les services de données d’IA, car ils suppriment la charge opérationnelle. C’est bien. Le problème commence lorsque les organisations cessent de réfléchir à la manière dont les données pourraient être extraites, transformées, validées et réhydratées ailleurs.
L’architecture de sortie du cloud nécessite une réflexion claire sur les formats de données, les métadonnées, le traçage, le chiffrement, la conservation et la réplication. Si la seule forme utilisable de vos données réside dans un service spécifique au fournisseur, vous rencontrez un problème de portabilité. Cela ne signifie pas que chaque base de données doit être open source ou autogérée. C’est un autre extrême et généralement mauvais. Cela signifie que les architectes doivent comprendre le chemin de sortie avant de choisir le service.
