OSIRIS JSON pour Microsoft Azure
Microsoft Azure est l’une des directions producer les plus importantes pour OSIRIS JSON parce que les hyperscalers sont les endroits ou la visibilite architecturale devient vite couteuse.
Pour les solution architects, le probleme est rarement l’acces abstrait aux donnees. Azure expose deja beaucoup de donnees. Le vrai probleme est que les donnees sont fragmentees entre services, abonnements, groupes de ressources, frontieres reseau, identites et constructions specifiques a la plateforme qu’il est difficile de raisonner ensemble a un moment donne. OSIRIS est utile ici parce qu’il transforme cette dispersion en un document de topologie portable unique.
Pourquoi Azure compte autant
Azure n’est pas seulement un catalogue de services. C’est un environnement en couches de conteneurs, de reseaux, de calcul, de plateformes gerees, de controles de securite et de dependances inter-services.
C’est exactement pourquoi les solution architects ont besoin d’une vue approfondie de l’hyperscaler.
Sans cette vue, il est facile de comprendre des ressources individuelles tout en passant a cote de l’architecture:
- quelles charges de travail appartiennent a quels groupes de ressources et abonnements
- comment les VNets, sous-reseaux, gateways, endpoints et security groups faconnent la connectivite
- ou se situent reellement les services de donnees par rapport aux couches applicatives
- quelles dependances traversent des frontieres de region, de service ou meme de provider
- quelles parties du patrimoine constituent l’architecture core et lesquelles ne sont qu’un detail d’implementation
Le portail peut aider a naviguer entre les services. OSIRIS vise quelque chose de different: un snapshot de topologie normalise qui peut etre valide, revise, diff, documente et reutilise par des outils en aval.
Azure a besoin a la fois du detail de ressource et du contexte structurel
Le modele OSIRIS mappe deja une grande partie de la surface courante d’Azure vers des types de ressources portables:
- les machines virtuelles vers
compute.vm - Azure Functions vers
compute.function.serverless - Azure SQL vers
application.database - Azure Cache for Redis vers
application.cache - les VNets et sous-reseaux vers le modele reseau
- les load balancers, gateways, security groups, private endpoints, disques, fichiers et le stockage vers les types standard correspondants
Cela compte parce qu’un producer Azure ne doit pas s’arreter a lister des ressources. Il doit preserver l’architecture autour d’elles.
Pour les solution architects, la modelisation de l’appartenance et des frontieres est aussi importante que les ressources elles-memes. Les groupes de ressources, les abonnements, les VNets et les autres conteneurs Azure font partie du langage de conception de l’hyperscaler. OSIRIS peut les exprimer a l’aide de groupes et de metadonnees de provider sans enfermer le document entier dans une semantique reservee a Azure.
Une visibilite profonde sans perdre le sens natif d’Azure
L’une des forces de l’approche OSIRIS est qu’elle ne force pas Azure dans un export au plus petit denominateur commun.
Le standard conserve les donnees portables dans le modele core tout en autorisant les details natifs d’Azure via les extensions osiris.azure. Cela signifie qu’un producer Azure peut preserver des elements comme:
- les IDs de ressources ARM
- le contexte d’abonnement et de groupe de ressources
- les URL du portail et les references natives a la plateforme
- les metadonnees de service specifiques a Azure
- la semantique des services qui compte pour les consumers conscients d’Azure mais qui ne doit pas etre forcee dans chaque outil generique
Cela est particulierement important pour les architectes. Ils ont besoin de la vue de topologie generique pour le raisonnement inter-plateformes, mais ils ont aussi besoin du contexte natif Azure lorsqu’ils retracent les frontieres d’implementation reelles a l’interieur de l’hyperscaler.
L’architecture Azure est souvent plus profonde que ne le suggere le diagramme
Les diagrammes hyperscaler paraissent souvent propres parce qu’ils resumment le resultat, pas la structure sous-jacente.
Un environnement Azure reel contient generalement davantage de couches:
- une propriete et un regroupement hierarchiques
- des services geres par la plateforme avec des hypotheses reseau cachees
- des dependances service a service qui ne sont pas evidentes a partir d’une esquisse visuelle
- des controles de securite et des frontieres de connectivite repartis entre differents control planes
- des conventions de nommage et de scope qui peuvent ou non refleter l’architecture reelle
C’est exactement la qu’OSIRIS peut aider les solution architects. Un producer pour Azure peut capturer l’etat de l’architecture a un instant donne sous une forme plus proche de la realite qu’une slide curatee manuellement et plus facile a raisonner que des dizaines d’exports de services bruts.
Cela compte aussi dans les architectures multi-hyperscaler
La valeur d’Azure devient encore plus claire dans les patrimoines multi-cloud ou hybrides.
Les exemples OSIRIS montrent deja des ressources Azure participant a des topologies applicatives inter-cloud, y compris des dependances entre services Azure et services AWS. Pour les architectes, c’est un cas d’usage critique. Vous ne voulez pas seulement savoir ce qui existe dans Azure. Vous voulez comprendre comment Azure s’insere dans l’ensemble du systeme.
C’est la que la topologie neutre vis-a-vis des vendors compte le plus. Un frontend dans Azure, une API dans AWS et une base de donnees de retour dans Azure doivent encore pouvoir etre compris comme une seule architecture, pas comme trois inventaires deconnectes.
Un producer Azure doit toujours respecter le contrat producer
Meme pour un hyperscaler, les memes regles producer OSIRIS s’appliquent:
- il est en lecture seule et ne doit pas modifier l’infrastructure
- il ne doit pas inventer de valeurs inconnues
- il doit generer une sortie deterministe pour une meme entree source
- il doit supprimer les secrets et echouer de maniere sure lorsque des donnees sensibles sont detectees
- il doit preserver les identifiants et le contexte natifs d’Azure sans remplacer le modele de topologie core
- il doit valider via la CLI et le moteur de validation canoniques d’OSIRIS
C’est ce qui maintient la vue Azure utile pour les architectes dans le temps. Sans determinisme et sans validation, meme un export riche ne devient qu’un autre dump instable de donnees.
Pourquoi Azure est un producer fondateur pour OSIRIS
Si OSIRIS veut serieusement aider les equipes a documenter et a comprendre l’infrastructure reelle, Azure doit faire partie de cette histoire.
C’est l’un des environnements ou la profondeur architecturale, la proliferation des services et les couches d’abstraction rendent la visibilite la plus difficile. C’est precisement pour cela qu’un producer Azure bien concu compte. Il donne aux solution architects une vue plus profonde et plus fidele de l’hyperscaler sur lequel ils concoivent, qu’ils revoient et dont ils doivent repondre.