OSIRIS JSON per a Microsoft Azure
Microsoft Azure es una de les direccions de producer mes importants per a OSIRIS JSON perque els hyperscalers son el lloc on la visibilitat arquitectonica s’encareix molt rapidament.
Per als arquitectes de solucions, el problema rarament es l’acces abstracte a les dades. Azure ja exposa moltes dades. El problema real es que les dades estan fragmentades entre serveis, subscripcions, grups de recursos, limits de xarxa, identitats i construccions especifiques de la plataforma que resulten dificils de raonar plegades en un punt del temps. OSIRIS es util aqui perque converteix aquesta dispersio en un unic document portable de topologia.
Per que Azure importa tant
Azure no es nomes un cataleg de serveis. Es un entorn en capes de contenidors, xarxes, computacio, plataformes gestionades, controls de seguretat i dependencies entre serveis.
Aixo es exactament pel que els arquitectes de solucions necessiten una vista profunda de l’hyperscaler.
Sense aquesta vista, es facil entendre recursos individuals i tot i aixi perdre l’arquitectura:
- quines carregues de treball pertanyen a quins grups de recursos i subscripcions
- com VNets, subxarxes, gateways, endpoints i security groups modelen la connectivitat
- on se situen realment els serveis de dades en relacio amb les capes d’aplicacio
- quines dependencies creuen limits de regio, de servei o fins i tot de provider
- quines parts de l’entorn son arquitectura core i quines son nomes detall d’implementacio
El portal pot ajudar a navegar serveis. OSIRIS apunta a una cosa diferent: un snapshot de topologia normalitzat que es pugui validar, revisar, comparar per diff, documentar i reutilitzar mitjancant eines aigues avall.
Azure necessita tant detall de recurs com context estructural
El model d’OSIRIS ja mapeja una gran part de la superficie comuna d’Azure a tipus de recursos portables:
- maquines virtuals a
compute.vm - Azure Functions a
compute.function.serverless - Azure SQL a
application.database - Azure Cache for Redis a
application.cache - VNets i subxarxes al model de xarxa
- load balancers, gateways, security groups, private endpoints, discs, fitxers i emmagatzematge als tipus estandard corresponents
Aixo importa perque un producer d’Azure no s’hauria d’aturar a llistar recursos. Hauria de preservar l’arquitectura al voltant d’aquests.
Per als arquitectes de solucions, el modelatge de pertinenca i de limits es tan important com els mateixos recursos. Els grups de recursos, les subscripcions, les VNets i altres contenidors d’Azure formen part del llenguatge de disseny de l’hyperscaler. OSIRIS pot expressar-los fent servir grups i metadades de provider sense bloquejar tot el document en una semantica exclusiva d’Azure.
Visibilitat profunda sense perdre el significat natiu d’Azure
Una de les fortaleses de l’enfocament d’OSIRIS es que no obliga Azure a una exportacio de minim comu denominador.
L’estandard mante les dades portables en el model core i tot i aixi permet detall natiu d’Azure mitjancant extensions osiris.azure. Aixo significa que un producer d’Azure pot preservar coses com:
- ID de recursos ARM
- context de subscripcio i de grup de recursos
- URL del portal i referencies natives de la plataforma
- metadades de servei especifiques d’Azure
- semantica de servei que importa a consumers conscients d’Azure pero que no s’hauria de forcar en totes les eines generiques
Aixo es especialment important per als arquitectes. Necessiten la vista generica de topologia per raonar entre plataformes, pero tambe necessiten el context natiu d’Azure quan estan rastrejant limits reals d’implementacio dins de l’hyperscaler.
L’arquitectura d’Azure sol ser mes profunda del que suggereix el diagrama
Els diagrames d’hyperscaler solen semblar nets perque resumeixen el resultat, no l’estructura subjacent.
Un entorn real d’Azure sol contenir mes capes:
- propietat i agrupacio jerarquiques
- serveis gestionats per la plataforma amb suposicions de xarxa ocultes
- dependencies entre serveis que no resulten obvies a partir d’un esbos visual
- controls de seguretat i limits de connectivitat repartits entre diferents control planes
- convencions de noms i d’abast que poden o no reflectir l’arquitectura real
Aixo es exactament on OSIRIS pot ajudar els arquitectes de solucions. Un producer per a Azure pot capturar l’estat de l’arquitectura en un punt del temps d’una manera mes propera a la realitat que una slide curada manualment i mes facil de raonar que desenes d’exports bruts de serveis.
Aixo tambe importa en dissenys multi-hyperscaler
El valor d’Azure es torna encara mes clar en entorns multi-cloud o hibrids.
Els exemples d’OSIRIS ja mostren recursos d’Azure participant en topologies d’aplicacio inter-cloud, incloent-hi dependencies entre serveis d’Azure i serveis d’AWS. Per als arquitectes, aquest es un cas d’us critic. No vols nomes saber que existeix a Azure. Vols entendre com encaixa Azure en tot el sistema.
Aqui es on la topologia neutral respecte del vendor importa mes. Un frontend a Azure, una API a AWS i una base de dades de tornada a Azure haurien de continuar sent comprensibles com una unica arquitectura, i no com tres inventaris desconnectats.
Un producer d’Azure encara ha d’obeir el contracte de producer
Fins i tot per a un hyperscaler, s’apliquen les mateixes regles de producer d’OSIRIS:
- es de nomes lectura i no ha de mutar infraestructura
- no ha d’inventar valors desconeguts
- ha de generar una sortida determinista per a la mateixa entrada d’origen
- ha d’eliminar secrets i fallar de manera segura quan es detectin dades sensibles
- ha de preservar els identificadors i el context natius d’Azure sense substituir el model core de topologia
- ha de validar a traves de la CLI canonica d’OSIRIS i del motor de validacio
Aixo es el que mante util la vista d’Azure per als arquitectes amb el pas del temps. Sense determinisme ni validacio, fins i tot un export ric es converteix en un altre dump inestable de dades.
Per que Azure es un producer fundacional per a OSIRIS
Si OSIRIS va de debo amb ajudar els equips a documentar i entendre infraestructura real, Azure ha de formar part d’aquesta historia.
Es un dels entorns on la profunditat arquitectonica, la proliferacio de serveis i les capes d’abstraccio fan que la visibilitat sigui mes dificil. Precisament per aixo importa un producer d’Azure ben dissenyat. Dona als arquitectes de solucions una vista mes profunda i mes fidel de l’hyperscaler sobre el qual estan dissenyant, revisant i del qual se’ls fa responsables.