Creare applicazioni portabili con app adattive

La portabilità è un requisito operativo e di approvvigionamento per le applicazioni moderne. I team devono progettare applicazioni reversibili e che possono essere convertite in destinazioni diverse, tra cui cloud sovrani, infrastruttura locale e ambienti perimetrali connessi in modo intermittente. Le condizioni seguenti determinano la necessità di portabilità:

• Regole di residenza e sovranità dei dati
• Obblighi di conformità specifici del settore
• Ambienti di connettività intermittenti
• Requisiti di continuità aziendale

I modelli di intelligenza artificiale perimetrale, Radius e Kubernetes abilitati per Arc creano una base pratica per un modello di architettura in grado di soddisfare i requisiti di portabilità. Questo modello di architettura è la soluzione di app adattive .

Le app adattive separano la finalità dell'applicazione dall'implementazione specifica dell'ambiente. Gli sviluppatori descrivono i carichi di lavoro e le funzionalità necessarie una sola volta e gli operatori della piattaforma associano tali risorse portabili alle ricette del servizio locale, ai criteri, all'identità, alla rete, all'osservabilità e all'infrastruttura appropriati per ogni ambiente. Questo articolo descrive la soluzione di app adattive e illustra come i portfolio di funzionalità, i protocolli aperti e i flussi di lavoro di distribuzione basati su Radius consentono alle applicazioni di rimanere coerenti, gestibili e operativi ovunque vengano eseguiti.

Architecture

Un'applicazione modellata con Radius è costituita da un set di risorse. È possibile classificare queste risorse in componenti dell'applicazione e risorse a livello di piattaforma che supportano l'applicazione. La raccolta di queste risorse a livello di piattaforma è denominata portfolio di funzionalità.

Una risorsa Radius definisce un'interfaccia astratta per una funzionalità a livello di piattaforma. Quando si distribuisce una risorsa Radius in un ambiente di destinazione, una ricetta specifica della destinazione può eseguire il mapping del tipo di risorsa a un'implementazione specifica della piattaforma concreta. Si proietta il portfolio di funzionalità in ambienti di destinazione diversi tramite le ricette corrispondenti.

Questa architettura fornisce all'applicazione le funzionalità necessarie senza che sia necessario riscrivere il codice dell'applicazione per ogni piattaforma specifica.

Scaricare un file di Visio di questa architettura.

L'architettura consente la portabilità tramite due livelli di astrazione complementari.

• Innanzitutto, Radius fornisce un'astrazione del modello di applicazione che separa i requisiti dell'applicazione dalle implementazioni specifiche della piattaforma. I tipi di risorse astratti rappresentano risorse come database, cache o sistemi di messaggistica che possono essere mappati a implementazioni diverse tramite ricette specifiche dell'ambiente. Questo approccio consente di distribuire la stessa definizione dell'applicazione in più ambienti senza modificare gli artefatti di distribuzione.

• In secondo luogo, le applicazioni possono adottare un'astrazione del modello di programmazione. Le applicazioni possono interagire con le dipendenze tramite protocolli e standard ampiamente adottati o tramite un livello di astrazione basato sul sidecar facoltativo, ad esempio Dapr. Questi approcci riducono l'accoppiamento delle applicazioni alle API di servizio specifiche della piattaforma e migliorano la portabilità in ambienti diversi.

Queste astrazioni offrono un'esperienza di "scrittura una sola volta, eseguita in molti ambienti", ma introducono anche compromessi. Per rimanere portabili, le applicazioni potrebbero dover limitare l'uso diretto di funzionalità e ottimizzazioni specifiche della piattaforma che non sono disponibili in tutti gli ambienti di destinazione. Quando si usa un sidecar o un'astrazione di programmazione comune per ottenere la portabilità, è necessario accettare i vincoli imposti da tale livello di astrazione.

Teams deve impegnarsi a convalidare il comportamento dell'applicazione tra le destinazioni di distribuzione supportate, aumentando così la complessità operativa e i test. Visualizzare la portabilità come scelta architetturale intenzionale che sacrifica un'integrazione più approfondita della piattaforma per la flessibilità di distribuzione, la riduzione del blocco e una maggiore coerenza tra ambienti eterogenei.

Flusso di lavoro

Il flusso di lavoro seguente corrisponde al diagramma precedente. Il flusso di lavoro descrive un'app di esempio che contiene componenti tipici, ad esempio un front-end, un back-end, un agente di intelligenza artificiale, un broker di messaggi e un provider di identità OpenID Connect (OIDC).

1. Uno sviluppatore di applicazioni usa una definizione di applicazione Radius per descrivere il carico di lavoro una volta.

   La definizione dell'applicazione è costituita da un elenco di risorse, ad esempio una Applications.Core/containers risorsa che descrive un front-end del payload in contenitori e un back-end. Il modello di app adattive definisce anche alcune estensioni del tipo di risorsa che astraggono le funzionalità comuni della piattaforma per separare l'applicazione da qualsiasi piattaforma specifica.

   Invece di definire nuove astrazioni del piano dati, le app adattive usano componenti open source ampiamente adottati e protocolli aperti, ad esempio OIDC per l'autenticazione e il trasporto di telemetria di accodamento messaggi (MQTT) per la messaggistica. Questo approccio impedisce all'applicazione di essere vincolata da un'interfaccia astratta e consente di usare direttamente le funzionalità complete dei protocolli corrispondenti.

   Tipo di risorsa	Finalità
   Radius.Resources/agentGuardrails	Criteri di governance specifici dell'agente
   Radius.Resources/aiModels	Modelli di intelligenza artificiale che supportano inferenze di intelligenza artificiale
   Radius.Resources/governance	Criteri di governance aziendale
   Radius.Resources/mqttBrokers	Broker di messaggi basati su MQTT
   Radius.Resources/workloadIdentities	Identità del carico di lavoro usate per identificare un carico di lavoro o un agente all'interno di un'applicazione

2. Lo sviluppatore può creare o aggiornare il codice dell'applicazione usando un'API portabile.

   A livello di modello di programmazione, un'applicazione può adottare altre tecnologie sidecar come Dapr, che fornisce API indipendenti dalla piattaforma per attività comuni, ad esempio pub/sub, gestione dello stato e segreti. Radius include il supporto nativo per i sidecar Dapr.

   I servizi Brownfield che usano già Azure SDK possono continuare a funzionare in destinazioni se sono disponibili gli endpoint Azure necessari, i flussi di identità e la connettività di rete. I servizi che usano protocolli comuni possono continuare a funzionare dove vengono fornite implementazioni compatibili. Per una portabilità più ampia, i nuovi servizi possono adottare API Dapr per consentire alle applicazioni di adattarsi a più variazioni della piattaforma.

3. Un operatore di piattaforma esegue il bootstrap di un portfolio di funzionalità per ogni destinazione.

   L'operatore seleziona uno dei sei portfolio predefiniti: min, core, ent, min-ai, core-ai, o ent-ai, in base alle esigenze di footprint e conformità dell'ambiente. L'operatore installa il portfolio tramite un grafico Helm. Nella tabella seguente viene illustrato se i portfolio predefiniti supportano vari protocolli.

   Portafoglio	Identità (OIDC)	Mesh di servizi (Istio)	Osservabilità (OTel)	Governance (OPA)	Intelligenza artificiale nel cluster (Kaito)	Guardrail agente
   min	✓	✗	✗	✗	✗	✗
   core	✓	✓	✓	✗	✗	✗
   ent	✓	✓	✓	✓	✗	✗
   min-ai	✓	✗	✗	✗	✓	✗
   core-ai	✓	✓	✓	✗	✓	✓
   ent-ai	✓	✓	✓	✓	✓	✓

   Le app adattive forniscono anche uno strumento da riga di comando per facilitare i passaggi di configurazione dell'infrastruttura oltre l'installazione helm e rendere disponibili le informazioni sull'infrastruttura per la distribuzione delle applicazioni.

4. Radius associa l'applicazione a ricette specifiche dell'ambiente.

   Quando rad deploy viene eseguito nell'area di lavoro di destinazione, una ricetta registrata con l'ambiente effettua il provisioning di ogni risorsa portabile nell'app adattiva. Ad esempio, Radius.Resources/aiModels viene risolto in un modello SLM (Local Small Language Model) gestito da Kaito quando l'app viene distribuita in un ambiente Kubernetes locale. La stessa risorsa viene risolta in un endpoint OpenAI o Azure OpenAI quando viene distribuito in un ambiente cloud. Radius inserisce informazioni di connessione per le dipendenze dichiarate in modo esplicito dalla definizione dell'applicazione.

   

   Diagramma che mostra come le funzionalità dell'app adattiva di esempio popolano ogni ambiente di destinazione. Una casella a sinistra mostra l'app adattiva Radius che contiene funzionalità di calcolo, provider di identità, identità del carico di lavoro, messaggistica, modello di intelligenza artificiale, criteri e osservabilità. Le frecce portano da ogni funzionalità alle destinazioni di distribuzione: Azure, Azure Arc o altri cloud e ambienti personalizzati. Ogni destinazione contiene servizi e estensioni specifici della destinazione che implementano tale funzionalità in tale ambiente.

   Scaricare un file di Visio di questo diagramma.

Components

• Radius è un modello di applicazione open source che esprime un carico di lavoro come grafico dei tipi di risorse portabili e risolve ogni tipo in una ricetta specifica dell'ambiente in fase di distribuzione. In questa architettura Radius è il contratto principale tra i team dell'applicazione e gli operatori della piattaforma. Le app adattive usano anche gli strumenti Radius per distribuire applicazioni in ambienti di destinazione.

• I portfolio di funzionalità sono contratti tra le applicazioni e le relative piattaforme di hosting. Questa architettura include sei portfolio predefiniti per i livelli di funzionalità, da un footprint perimetrale di base a una configurazione aziendale completa con applicazione dei criteri e intelligenza artificiale nel cluster. Gli operatori della piattaforma installano i portfolio di funzionalità come grafici Helm.

• Gli strumenti basati sull'intelligenza artificiale offrono un'interfaccia della riga di comando per la configurazione dell'infrastruttura e la migrazione assistita dall'intelligenza artificiale delle applicazioni brownfield. In questa architettura, gli strumenti consentono di eseguire la migrazione di applicazioni brownfield, tra cui applicazioni microservizi, applicazioni legacy e applicazioni mainframe, al modello di applicazione Radius.

Dettagli dello scenario

Un team del carico di lavoro potrebbe dover eseguire la stessa applicazione in un ambiente eterogeneo che può includere gli ambienti seguenti:

• Un'area cloud pubblica per carichi di lavoro elastici
• Un'area sovrana per soddisfare gli obblighi di residenza dei dati
• Un data center locale per l'elaborazione sensibile alla latenza
• Una flotta di cluster perimetrali remoti con connettività intermittente

Ogni ambiente ha in genere un proprio provider di identità, una sovrapposizione di mesh di servizi, uno stack di osservabilità, un motore di criteri e una strategia di intelligenza artificiale. Senza un contratto unificato, i team delle applicazioni devono creare un fork della codebase per ogni destinazione, bloccarsi in una singola piattaforma o comportare il refactoring dei costi ogni volta che aggiungono un nuovo ambiente.

Le app adattive risovono questo problema rendendo la piattaforma, non l'applicazione, responsabile dell'assorbimento della variazione ambientale. L'applicazione viene creata una volta con il modello di applicazione Radius e, facoltativamente, il modello di programmazione Dapr. Ogni ambiente di destinazione installa un portfolio di funzionalità che espone le funzionalità richieste dall'applicazione. Un livello di ricetta associa le risorse portabili alle implementazioni specifiche dell'ambiente in fase di distribuzione.

L'architettura è intenzionalmente non prescrittiva sul piano di controllo. I fornitori di funzionalità possono offrire portfolio tramite helm, estensioni Arc, Bicep, Terraform o programmi di installazione personalizzati. Le applicazioni rimangono portabili finché l'ambiente risultante soddisfa il contratto di capacità del portfolio.

Casi d'uso potenziali

• Distribuzioni cloud sovrane e regolamentate

  Un carico di lavoro regolamentato deve essere eseguito in un cloud sovrano o in un'infrastruttura controllata dal cliente durante la condivisione di una codebase con la versione del cloud pubblico. Il core-ai portfolio o ent-ai offre un contratto di funzionalità coerente tra le destinazioni di distribuzione, consentendo la portabilità delle applicazioni. L'ambiente di destinazione applica l'implementazione specifica di funzionalità e controlli, tra cui residenza dei dati, crittografia, controllo di accesso, controllo e certificazioni di conformità per soddisfare i requisiti normativi e sovranità.

• Modernizzazione brownfield senza ripiattaforma

  Un team del carico di lavoro modernizza in modo incrementale un'applicazione di microservizi legacy introducendo definizioni di risorse Radius per descrivere le dipendenze dell'infrastruttura e adottando in modo selettivo le funzionalità Dapr. Gli strumenti di refactoring basati sull'intelligenza artificiale consentono di accelerare parti della migrazione. Questo approccio consente ai team di modernizzare le applicazioni per migliorare la portabilità, l'osservabilità e la coerenza operativa in base ai requisiti aziendali e tecnici.

• Inferenza ibrida di intelligenza artificiale al perimetro

  Un carico di lavoro di vendita al dettaglio o industriale esegue lo stesso aiModel servizio in Azure nella sede centrale chiamando Azure OpenAI e nei cluster Azure Locale in negozi o impianti chiamando un modello open source ospitato da Kaito. Il codice dell'applicazione è identico e solo la aiModel ricetta è diversa.

• Bordo collegato in modo intermittente

  Una distribuzione di difesa, marittimo o sito remoto esegue il min-ai portfolio in un singolo cluster vincolato a risorse senza dipendenze da servizi di identità o intelligenza artificiale ospitati nel cloud. Lo stesso carico di lavoro, quando si ridistribuisce nel servizio Azure Kubernetes con il core-ai portfolio, ottiene automaticamente mesh e osservabilità. Il ent-ai portfolio aggiunge anche l'applicazione dei criteri di governance.

• Distribuzione multicloud

  Un team del carico di lavoro distribuisce le risorse dell'applicazione modellate in un'altra area di lavoro usando rad deploy, purché ogni destinazione implementi lo stesso contratto di funzionalità. Considerano il bursting del carico di lavoro e il ripristino di emergenza come problematiche separate. Un ambiente secondario utilizzabile richiede anche capacità, disponibilità di artefatti e dati, sequenziazione delle dipendenze, identità, connettività di rete, routing del traffico, controlli di integrità e procedure di failover/failback testate.

Contributori

Microsoft mantiene questo articolo. I seguenti collaboratori hanno scritto questo articolo.

Autori principali:

• Haishi Bai | Principal Software Architect
• Boris Scholl | VP Engineering
• Will Tsai | Product Manager principale

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passo successivo

• Esplorare il repository delle app adattive in GitHub