Construir aplicações portáteis com aplicações adaptativas

A portabilidade é um requisito de aquisição e operacional para aplicações modernas. As equipas devem desenhar aplicações que sejam reversíveis e possam ser portadas para diferentes alvos, incluindo clouds soberanas, infraestruturas on-premises e ambientes de edge intermitentemente ligados. As seguintes condições impulsionam a necessidade de portabilidade:

• Residência de dados e regras de soberania
• Mandatos de conformidade específicos por setor
• Ambientes de conectividade intermitente
• Requisitos de continuidade do negócio

Kubernetes compatível com Arc, Radius e padrões de IA de periferia criam uma base prática para um modelo de arquitetura que possa satisfazer os requisitos de portabilidade. Este modelo de arquitetura é a solução para aplicações adaptativas .

As aplicações adaptativas separam a intenção da aplicação da implementação específica do ambiente. Os programadores descrevem as cargas de trabalho e as capacidades necessárias uma vez, e os operadores de plataforma vinculam esses recursos portáteis a receitas de serviços locais, políticas, identidade, rede, observabilidade e infraestrutura adequada a cada ambiente. Este artigo descreve a solução de aplicações adaptativas e mostra como portfólios de capacidades, protocolos abertos e fluxos de trabalho de implementação baseados em Radius permitem que as aplicações se mantenham consistentes, governáveis e operacionais onde quer que corram.

Architecture

Uma aplicação modelada com Raio é composta por um conjunto de recursos. Pode categorizar estes recursos em componentes de aplicação e recursos ao nível da plataforma que suportam a aplicação. A coleção destes recursos ao nível da plataforma é chamada de portfólio de capacidades.

Um recurso Radius define uma interface abstrata para uma capacidade ao nível da plataforma. Quando implementa um recurso Radius para um ambiente alvo, uma receita específica para o alvo pode mapear esse tipo de recurso para uma implementação concreta e específica da plataforma. Projetas o portefólio de capacidades em diferentes ambientes-alvo através das receitas correspondentes.

Esta arquitetura fornece à aplicação as capacidades necessárias sem exigir que o código da aplicação seja reescrito para cada plataforma específica.

Descarregue um ficheiro Visio desta arquitetura.

A arquitetura permite a portabilidade através de duas camadas de abstração complementares.

• Em primeiro lugar, o Radius fornece uma abstração do modelo de aplicação que separa os requisitos da aplicação das implementações específicas da plataforma. Os tipos abstratos de recursos representam recursos como bases de dados, caches ou sistemas de mensagens que podem mapear para diferentes implementações através de receitas específicas do ambiente. Esta abordagem permite implementar a mesma definição de aplicação em múltiplos ambientes sem modificar artefactos de implementação.

• Em segundo lugar, as aplicações podem adotar uma abstração de modelo de programação. As aplicações podem interagir com dependências através de normas e protocolos amplamente adotados, ou através de uma camada opcional de abstração baseada em sidecar, como o Dapr. Estas abordagens reduzem o acoplamento de aplicações a APIs de serviço específicas da plataforma e melhoram a portabilidade entre ambientes.

Estas abstrações proporcionam uma experiência apelativa de "escrever uma vez, executar em muitos ambientes", mas também introduzem concessões. Para se manterem portáteis, as aplicações podem precisar de limitar o uso direto de funcionalidades e otimizações específicas da plataforma que não estão disponíveis em todos os ambientes-alvo. Quando utiliza um sidecar ou uma abstração de programação comum para obter portabilidade, deve aceitar as restrições impostas por essa camada de abstração.

As equipas devem comprometer-se a validar o comportamento das aplicações entre os alvos de implementação suportados, o que aumenta a complexidade dos testes e operacional. Veja a portabilidade como uma escolha arquitetónica intencional que sacrifica uma integração mais profunda da plataforma em favor da flexibilidade de implementação, redução do lock-in e maior consistência em ambientes heterogéneos.

Workflow

O fluxo de trabalho a seguir corresponde ao diagrama anterior. O fluxo de trabalho descreve uma aplicação de exemplo que contém componentes típicos como front-end, back end, agente de IA, corretor de mensagens e fornecedor de identidade OpenID Connect (OIDC).

1. Um programador de aplicações utiliza uma definição de aplicação Radius para descrever a carga de trabalho uma única vez.

   A definição da aplicação consiste numa lista de recursos, como um recurso Applications.Core/containers que descreve o front-end e o back-end de uma aplicação contentorizada. O padrão de aplicações adaptativas também define algumas extensões de tipos de recursos que abstraem capacidades comuns da plataforma para desacoplar a aplicação de qualquer plataforma em particular.

   Em vez de definir novas abstrações de planos de dados, as aplicações adaptativas utilizam componentes open-source amplamente adotados e protocolos abertos, como OIDC para autenticação e Message Queuing Telemetry Transport (MQTT) para mensagens. Esta abordagem impede que a aplicação seja limitada por uma interface abstrata e permite-lhe utilizar diretamente todas as capacidades dos protocolos correspondentes.

   Tipo de recurso	Purpose
   Radius.Resources/agentGuardrails	Políticas de governação específicas para agentes
   Radius.Resources/aiModels	Modelos de IA que suportam inferências de IA
   Radius.Resources/governance	Políticas de governação empresarial
   Radius.Resources/mqttBrokers	Brokers de mensagens baseados no MQTT
   Radius.Resources/workloadIdentities	Identidades de carga de trabalho usadas para identificar uma carga de trabalho ou agente dentro de uma aplicação

2. O programador pode criar ou atualizar o código da aplicação utilizando uma API portátil.

   Ao nível do modelo de programação, uma aplicação pode adotar ainda tecnologias sidecar como o Dapr, que fornece APIs independentes da plataforma para tarefas comuns como publicação/submissão, gestão de estados e segredos. Radius tem suporte nativo para sidecars do Dapr.

   Os serviços brownfield que já utilizam SDKs do Azure podem continuar a funcionar nos alvos se estiverem disponíveis os endpoints Azure necessários, fluxos de identidade e conectividade de rede. Os serviços que utilizam protocolos comuns podem continuar a funcionar onde são fornecidas implementações compatíveis. Para uma portabilidade mais ampla, novos serviços podem adotar APIs Dapr para ajudar as aplicações a adaptar-se a mais variações de plataforma.

3. Um operador de plataforma cria um portefólio de capacidades para cada alvo.

   O operador escolhe uma das seis carteiras predefinidas: min, core, ent, min-ai, core-ai, ou ent-ai, com base na pegada ambiental e nas necessidades de conformidade. O operador instala o portefólio através de um gráfico de Helm. A tabela seguinte mostra se os portfólios predefinidos suportam vários protocolos.

   Portefólio	Identidade (OIDC)	Malha de serviços (Istio)	Observabilidade (OTel)	Governação (OPA)	IA no cluster (Kaito)	Guardrail de agente
   min	✓	✗	✗	✗	✗	✗
   core	✓	✓	✓	✗	✗	✗
   ent	✓	✓	✓	✓	✗	✗
   min-ai	✓	✗	✗	✗	✓	✗
   core-ai	✓	✓	✓	✗	✓	✓
   ent-ai	✓	✓	✓	✓	✓	✓

   As aplicações adaptativas também fornecem uma ferramenta de linha de comandos para facilitar passos de configuração da infraestrutura para além da instalação do Helm e disponibilizar a informação da infraestrutura para implementação de aplicações.

4. O Radius associa a aplicação a receitas específicas do ambiente.

   Quando rad deploy é executada contra o espaço de trabalho alvo, uma receita registada no ambiente fornece cada recurso portátil na aplicação adaptativa. Por exemplo, Radius.Resources/aiModels resolve para um modelo de linguagem pequeno local (SLM) gerido pela Kaito quando a aplicação é implementada num ambiente Kubernetes local. O mesmo recurso corresponde a um endpoint do OpenAI ou do Azure OpenAI quando implementado num ambiente de nuvem. O raio injeta informação de ligação para dependências que a definição da aplicação declara explicitamente.

   

   Diagrama que mostra como as capacidades da aplicação adaptativa de exemplo preenchem cada ambiente-alvo. Uma caixa à esquerda mostra a aplicação adaptativa Radius que contém capacidades de computação, fornecedor de identidade, identidade da carga de trabalho, mensagens, modelo de IA, políticas e capacidade de observabilidade. Setas conduzem de cada capacidade aos alvos de implementação: Azure, Azure Arc ou outras clouds e ambientes personalizados. Cada alvo contém serviços e extensões específicas do alvo que implementam essa capacidade nesse ambiente.

   Descarregue um ficheiro Visio deste diagrama.

Components

• Radius é um modelo de aplicação open-source que expressa uma carga de trabalho como um grafo de tipos de recursos portáteis e resolve cada tipo para uma receita específica do ambiente no momento da implementação. Nesta arquitetura, a Radius é o contrato principal entre as equipas de aplicação e os operadores da plataforma. As aplicações adaptativas também utilizam ferramentas Radius para implementar aplicações em ambientes-alvo.

• Os portfólios de capacidades são contratos entre aplicações e as suas plataformas de alojamento. Esta arquitetura tem seis portfólios predefinidos para níveis de capacidade, desde uma implementação de edge básica até uma configuração empresarial completa com aplicação de políticas e IA no cluster. Os operadores da plataforma instalam portfólios de capacidades como gráficos de Helm.

• Ferramentas baseadas em IA fornecem uma CLI para configuração de infraestruturas e migração assistida por IA de aplicações brownfield. Nesta arquitetura, as ferramentas ajudam a migrar aplicações brownfield, incluindo aplicações de microserviços, aplicações legadas e mainframes, para o modelo de aplicação Radius.

Detalhes do cenário

Uma equipa de carga de trabalho pode precisar de executar a mesma aplicação num património heterogéneo que pode incluir os seguintes ambientes:

• Uma região de cloud pública para cargas de trabalho elásticas
• Uma região soberana para cumprir obrigações de residência de dados
• Um centro de dados local para processamento sensível à latência
• Uma frota de clusters edge remotos com conectividade intermitente

Cada ambiente tem normalmente o seu próprio provedor de identidade, camada de malha de serviços, pilha de observabilidade, mecanismo de políticas e estratégia de IA. Sem um contrato comum, as equipas de desenvolvimento de aplicações têm de: ou bifurcar a base de código-fonte para cada ambiente de destino, ou ficar limitadas a uma única plataforma, ou suportar custos de refatoração sempre que adicionam um novo ambiente.

As aplicações adaptativas resolvem este problema tornando a plataforma, e não a aplicação, responsável por absorver a variação ambiental. A aplicação é criada uma vez com base no modelo de aplicação Radius e, opcionalmente, no modelo de programação Dapr. Cada ambiente alvo instala um portefólio de capacidades que expõe as capacidades exigidas pela aplicação. Uma camada de receitas liga recursos portáteis a implementações específicas do ambiente no momento da implementação.

A arquitetura é intencionalmente não prescritiva quanto ao plano de controlo. Os fornecedores de capacidades podem disponibilizar portfólios através da Helm, extensões Arc, Bicep, Terraform ou instaladores personalizados. As aplicações continuam a ser portáteis desde que o ambiente resultante satisfaça o contrato de capacidade do portefólio.

Potenciais casos de utilização

• Implementações de cloud soberanas e reguladas

  Uma carga de trabalho regulada deve correr numa nuvem soberana ou numa infraestrutura controlada pelo cliente, partilhando uma base de código com a versão da nuvem pública. O portefólio core-ai ou ent-ai fornece um contrato coerente de capacidades entre os alvos de implementação, permitindo a portabilidade da aplicação. O ambiente-alvo impõe a implementação específica de capacidades e controlos, incluindo residência de dados, encriptação, controlo de acessos, auditoria e certificações de conformidade para cumprir os requisitos de soberania e regulamentos.

• Modernização brownfield sem mudar de plataforma

  Uma equipa de carga de trabalho moderniza incrementalmente uma aplicação de microserviços legada, introduzindo definições de recursos Radius para descrever as suas dependências de infraestrutura e adotando seletivamente capacidades Dapr. As ferramentas de refatoração impulsionadas por IA ajudam a acelerar partes da migração. Esta abordagem permite às equipas modernizar aplicações para melhorar a portabilidade, observabilidade e consistência operacional a um ritmo alinhado com os requisitos empresariais e técnicos.

• Inferência híbrida de IA na periferia

  Uma carga de trabalho de retalho ou industrial executa o mesmo aiModel serviço no Azure, na sede, recorrendo ao Azure OpenAI, e em clusters do Azure Local em lojas ou fábricas, recorrendo a um modelo de código aberto alojado no Kaito. O código de aplicação é idêntico e apenas a aiModel receita difere.

• Aresta intermitentemente ligada

  Uma implantação de defesa, marítima ou num local remoto executa o portefólio min-ai num único cluster com recursos limitados, sem dependência de serviços de identidade ou de IA alojados na cloud. A mesma carga de trabalho, quando redistribuída para o AKS com o core-ai portefólio, ganha automaticamente malha e observabilidade. O portefólio ent-ai inclui também a aplicação de políticas de governação.

• Implementação multicloud

  Uma equipa de carga de trabalho implementa recursos de aplicação modelados para outro espaço de trabalho usando rad deploy, desde que cada alvo implemente o mesmo contrato de capacidade. Tratam a explosão de carga de trabalho e a recuperação de desastres como preocupações separadas. Um ambiente secundário utilizável também necessita de capacidade, disponibilidade de artefactos e dados, sequenciação de dependências, identidade, conectividade de rede, encaminhamento de tráfego, verificações de saúde e procedimentos testados de failover/failback.

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Principais autores:

• Haishi Bai | Arquiteto Principal de Software
• Boris Scholl | VP de Engenharia
• Will Tsai | Gestor Principal de Produto

Para ver perfis não públicos do LinkedIn, faça login no LinkedIn.

Passo seguinte

• Explore o repositório Adaptive Apps no GitHub