OSIRIS JSON para Microsoft Azure
Microsoft Azure e uma das direcoes de producer mais importantes para OSIRIS JSON porque hyperscalers sao o lugar em que visibilidade arquitetural fica cara muito rapidamente.
Para arquitetos de solucao, o problema raramente e acesso a dados no abstrato. O Azure ja expoe muitos dados. O problema real e que os dados estao fragmentados entre servicos, assinaturas, grupos de recursos, limites de rede, identidades e construcoes especificas da plataforma que sao dificeis de raciocinar em conjunto em um ponto no tempo. O OSIRIS e util aqui porque transforma essa dispersao em um unico documento portavel de topologia.
Por que Azure importa tanto
Azure nao e apenas um catalogo de servicos. E um ambiente em camadas de containers, redes, computacao, plataformas gerenciadas, controles de seguranca e dependencias entre servicos.
E exatamente por isso que arquitetos de solucao precisam de uma visao aprofundada do hyperscaler.
Sem essa visao, e facil entender recursos individuais e ainda assim perder a arquitetura:
- quais cargas de trabalho pertencem a quais grupos de recursos e assinaturas
- como VNets, sub-redes, gateways, endpoints e security groups moldam a conectividade
- onde servicos de dados realmente se posicionam em relacao as camadas da aplicacao
- quais dependencias cruzam limites de regiao, de servico ou ate mesmo de provider
- quais partes do ambiente sao arquitetura core e quais sao apenas detalhes de implementacao
O portal pode ajudar a navegar pelos servicos. O OSIRIS se destina a algo diferente: um snapshot de topologia normalizado que pode ser validado, revisado, comparado por diff, documentado e reutilizado por ferramentas posteriores.
Azure precisa tanto de detalhe de recurso quanto de contexto estrutural
O modelo OSIRIS ja mapeia uma grande parte da superficie comum do Azure para tipos de recursos portaveis:
- maquinas virtuais para
compute.vm - Azure Functions para
compute.function.serverless - Azure SQL para
application.database - Azure Cache for Redis para
application.cache - VNets e sub-redes para o modelo de rede
- load balancers, gateways, security groups, private endpoints, discos, arquivos e armazenamento para os tipos padrao correspondentes
Isso importa porque um producer de Azure nao deve parar em listar recursos. Ele deve preservar a arquitetura em torno deles.
Para arquitetos de solucao, modelagem de pertencimento e de limites e tao importante quanto os proprios recursos. Grupos de recursos, assinaturas, VNets e outros containers do Azure fazem parte da linguagem de design do hyperscaler. O OSIRIS pode expressar isso usando grupos e metadados de provider sem prender o documento inteiro a uma semantica exclusiva do Azure.
Visibilidade profunda sem perder o significado nativo do Azure
Uma das forcas da abordagem do OSIRIS e que ela nao obriga o Azure a caber em um export de menor denominador comum.
O padrao mantem dados portaveis no modelo core e ainda permite detalhes nativos do Azure por meio de extensoes osiris.azure. Isso significa que um producer de Azure pode preservar coisas como:
- IDs de recursos ARM
- contexto de assinatura e de grupo de recursos
- URLs do portal e referencias nativas da plataforma
- metadados de servico especificos do Azure
- semantica de servicos que importa para consumers conscientes do Azure, mas que nao deveria ser forcada em toda ferramenta generica
Isso e especialmente importante para arquitetos. Eles precisam da visao generica de topologia para raciocinio entre plataformas, mas tambem precisam do contexto nativo do Azure quando estao rastreando limites reais de implementacao dentro do hyperscaler.
A arquitetura do Azure costuma ser mais profunda do que o diagrama sugere
Diagramas de hyperscaler muitas vezes parecem limpos porque resumem o resultado, nao a estrutura subjacente.
Um ambiente real de Azure normalmente contem mais camadas:
- propriedade e agrupamento hierarquicos
- servicos gerenciados pela plataforma com suposicoes de rede ocultas
- dependencias entre servicos que nao sao obvias em um esboco visual
- controles de seguranca e limites de conectividade espalhados por diferentes control planes
- convencoes de nomenclatura e escopo que podem ou nao refletir a arquitetura real
E exatamente ai que o OSIRIS pode ajudar arquitetos de solucao. Um producer para Azure pode capturar o estado da arquitetura em um ponto no tempo de uma forma mais proxima da realidade do que um slide curado manualmente e mais facil de raciocinar do que dezenas de exports brutos de servicos.
Isso tambem importa em designs multi-hyperscaler
O valor do Azure fica ainda mais claro em ambientes multi-cloud ou hibridos.
Os exemplos do OSIRIS ja mostram recursos do Azure participando de topologias de aplicacao cross-cloud, incluindo dependencias entre servicos do Azure e servicos da AWS. Para arquitetos, esse e um caso de uso critico. Voce nao quer apenas saber o que existe no Azure. Voce quer entender como o Azure se encaixa no sistema inteiro.
E ai que a topologia neutra em relacao a vendors mais importa. Um frontend no Azure, uma API na AWS e um banco de dados de volta no Azure ainda devem ser compreensiveis como uma unica arquitetura, e nao como tres inventarios desconectados.
Um producer de Azure ainda precisa obedecer ao contrato de producer
Mesmo para um hyperscaler, as mesmas regras de producer do OSIRIS se aplicam:
- ele e somente leitura e nao deve modificar infraestrutura
- ele nao deve inventar valores desconhecidos
- ele deve gerar saida deterministica para a mesma entrada de origem
- ele deve remover segredos e falhar de forma segura quando dados sensiveis forem detectados
- ele deve preservar identificadores e contexto nativos do Azure sem substituir o modelo core de topologia
- ele deve validar por meio da CLI canonica e do mecanismo de validacao do OSIRIS
E isso que mantem a visao do Azure util para arquitetos ao longo do tempo. Sem determinismo e validacao, ate um export rico se torna apenas mais um dump instavel de dados.
Por que Azure e um producer fundamental para o OSIRIS
Se o OSIRIS leva a serio ajudar equipes a documentar e entender infraestrutura real, o Azure precisa fazer parte dessa historia.
Esse e um dos ambientes em que profundidade arquitetural, proliferacao de servicos e camadas de abstracao tornam a visibilidade mais dificil. E exatamente por isso que um producer de Azure bem projetado importa. Ele da aos arquitetos de solucao uma visao mais profunda e mais fiel do hyperscaler em que estao projetando, revisando e pelo qual sao responsabilizados.