Distributori automatici di sottoscrizioni

  • Articolo

La distribuzione automatica delle sottoscrizioni offre un meccanismo di piattaforma per l'emissione a livello di codice di sottoscrizioni ai team delle applicazioni che devono distribuire i carichi di lavoro. Il diagramma seguente mostra dove vendita di abbonamenti rientra nei cicli di vita della piattaforma e del carico di lavoro.

Diagramma che mostra quattro passaggi.

La distribuzione automatica delle sottoscrizioni si basa sul concetto di democratizzazione delle sottoscrizioni e la applica alle zone di destinazione dell'applicazione. Con la democratizzazione delle sottoscrizioni, le sottoscrizioni, non i gruppi di risorse, sono le unità principali di gestione e scalabilità del carico di lavoro. Per altre informazioni, vedi:

Perché vendita di abbonamenti?

La distribuzione automatica delle sottoscrizioni offre diversi vantaggi alle organizzazioni che devono distribuire i carichi di lavoro in Azure. Standardizza e automatizza il processo di richiesta, distribuzione e governance delle sottoscrizioni per le zone di destinazione dell'applicazione. La distribuzione automatica delle sottoscrizioni semplifica il processo di creazione della sottoscrizione e la inserisce nella governance dell'organizzazione, in modo che i team delle app possano concentrarsi sulla distribuzione dei carichi di lavoro con maggiore sicurezza ed efficienza.

  • Processo semplificato: il distributore di sottoscrizioni offre un frontdoor ufficiale per i team delle applicazioni per richiedere le sottoscrizioni, eliminando la necessità di spostarsi autonomamente nel processo di sottoscrizione.
  • Velocità migliorata: i team delle applicazioni possono accedere alle zone di destinazione delle applicazioni più velocemente ed eseguire l'onboarding dei carichi di lavoro più velocemente.
  • Governance efficiente: il team della piattaforma può applicare la governance sulle zone di destinazione delle applicazioni con un sovraccarico minimo.

Come implementare vendita di abbonamenti

Il distributore di abbonamenti coinvolge tre team. Il Cloud Center of Excellence (CCoE) stabilisce la logica di business e il processo di approvazione. Quando si è pronti, i team dell'applicazione effettuano richieste di sottoscrizione. Il team della piattaforma usa la richiesta per creare e configurare la sottoscrizione prima di distribuire la sottoscrizione al team dell'applicazione. Il team dell'applicazione aggiorna il budget, distribuisce il carico di lavoro e stabilisce le operazioni. Le indicazioni seguenti forniscono altri dettagli su ogni passaggio del processo di vendita di abbonamenti. Per altre informazioni, vedere Linee guida per l'implementazione del distributore di sottoscrizioni.

Diagramma che mostra il processo di vendita di abbonamenti.

I team della piattaforma possono distribuire molte opzioni e tipi di sottoscrizione ai team delle applicazioni. Questi tipi sono definiti linee di prodotto perché si riferiscono ai principi e alle procedure di progettazione della piattaforma. Per altre informazioni sulla scelta dell'opzione più adatta alle proprie esigenze, vedere Linee di prodotto comuni vendita di abbonamenti.

Stabilire la logica di business e il processo di approvazione

Per implementare il modello di vendita di abbonamenti, è necessario stabilire un processo di approvazione che raccoglie informazioni essenziali sulla sottoscrizione. Il Cloud Center of Excellence (CCoE) deve programmare il processo di approvazione e stabilire regole business relative alle informazioni da raccogliere.

Automatizzare il processo. È consigliabile automatizzare il processo di acquisizione e approvazione delle richieste di sottoscrizione per un provisioning più rapido e una migliore conformità.

Eseguire l'integrazione con gli strumenti esistenti. È consigliabile integrare il processo di approvazione vendita di abbonamenti nello strumento di gestione dei servizi IT (ITSM) esistente. L'integrazione può semplificare il processo di approvazione, ridurre il lavoro manuale e migliorare l'efficienza riducendo al contempo gli errori. Semplifica inoltre la manutenzione nel tempo e aiuta a creare report di conformità per i controlli.

Connettersi alla pipeline di distribuzione. È consigliabile associare la logica di business del processo di approvazione alla pipeline di distribuzione della sottoscrizione gestita dal team della piattaforma. I flussi di lavoro di Azure Pipelines o GitHub Actions sono soluzioni comuni per la pipeline di distribuzione delle sottoscrizioni.

Raccogliere i requisiti in fase di assunzione. La logica di business deve consentire ai team dell'applicazione di richiedere una sottoscrizione e fornire i requisiti di sottoscrizione. Questi requisiti devono includere budget previsti, proprietari di sottoscrizioni, aspettative di rete e classificazione della criticità aziendale e riservatezza. La raccolta di queste informazioni all'inizio del processo informa i parametri di distribuzione e le esigenze di approvazione degli stakeholder. Il processo di assunzione deve anche fornire al team della piattaforma informazioni sufficienti per inserire il carico di lavoro nella gerarchia del gruppo di gestione.

Con il processo di approvazione, i team delle applicazioni possono iniziare a effettuare richieste di sottoscrizione.

Effettuare una richiesta di sottoscrizione

La distribuzione automatica delle sottoscrizioni offre un processo standard per i team delle applicazioni per richiedere una sottoscrizione. È importante socializzare la disponibilità di vendita di abbonamenti e assicurarsi che le richieste di sottoscrizione siano facili da effettuare. Dopo che il team dell'applicazione ha inviato una richiesta di sottoscrizione, il team della piattaforma assume il controllo del processo. Il team della piattaforma mantiene il controllo fino a quando non crea la sottoscrizione e distribuisce la sottoscrizione al team dell'applicazione.

Configurare la rete

L'automazione delle sottoscrizioni deve configurare i componenti di rete necessari e deve essere sufficientemente flessibile per soddisfare le esigenze di ogni team dell'applicazione. Come indicazioni generali, non usare mai indirizzi IP sovrapposti in un singolo dominio di routing. È possibile aggiungere o eliminare lo spazio degli indirizzi di una rete virtuale senza tempi di inattività se i requisiti di dimensione cambiano. Per altre informazioni, vedi:

Usare lo strumento Gestione indirizzi IP. È consigliabile usare e integrare un sistema di Gestione indirizzi IP nel processo di distribuzione automatica per semplificare l'assegnazione degli indirizzi IP. Per altre informazioni e indicazioni su Gestione indirizzi IP, vedere strumenti Gestione indirizzi IP (Gestione indirizzi IP).

Concedere all'app l'autonomia del team dell'app. È necessario concedere ai team dell'applicazione i diritti per creare subnet e anche alcune reti virtuali nella sottoscrizione. Il team della piattaforma deve sempre creare reti virtuali con peering a un hub centrale.

Applicare la governance della rete. Il team della piattaforma deve applicare la governance della rete virtuale tramite (1) Criteri di Azure assegnati alla gerarchia dei gruppi di gestione o (2) Regole di amministrazione di Azure Rete virtuale Manager e sicurezza. Per altre informazioni, vedere Governance basata su criteri e Come bloccare le porte ad alto rischio.

Determinare il posizionamento della sottoscrizione

Il team della piattaforma deve usare i requisiti di rete e governance per inserire la sottoscrizione nella gerarchia del gruppo di gestione. Devono anche esaminare i limiti di quota della sottoscrizione prima di creare la sottoscrizione. Per altre informazioni, vedere Personalizzare l'architettura della zona di destinazione di Azure per soddisfare i requisiti.

Identificare il gruppo di gestione corretto. I gruppi di gestione consentono di organizzare e gestire le sottoscrizioni e le distribuzioni dei carichi di lavoro. Individuare o creare un gruppo di gestione che applichi i criteri necessari per la classificazione e le esigenze di ogni carico di lavoro.

Creare un'automazione flessibile. L'automazione deve essere sufficientemente flessibile (1) per distribuire più sottoscrizioni e (2) adattarsi ai limiti del servizio di sottoscrizione.

  • Più sottoscrizioni: alcuni carichi di lavoro necessitano di diverse sottoscrizioni. Ad esempio, alcuni carichi di lavoro hanno diverse istanze separate dalla sottoscrizione. In alternativa, le architetture SaaS che usano risorse dedicate per cliente usano spesso decine di sottoscrizioni.

  • Limiti del servizio di sottoscrizione: un'organizzazione con diverse migliaia di sottoscrizioni deve disporre di automazione che può essere distribuita in una sottoscrizione precedente o di colocare i carichi di lavoro in una sottoscrizione per evitare i limiti. Per altre informazioni, vedere Domande frequenti sulle zone di destinazione di Azure.

    È possibile richiedere aumenti di quota manualmente usando il portale di Azure dopo il provisioning. È più semplice automatizzare questo processo usando le API disponibili. Tuttavia, la richiesta di quota può avere esito negativo, pertanto è necessario eseguire uno script per gestire eventuali errori. Per altre informazioni, vedere Microsoft.Capacity, Microsoft.Quota e Microsoft.Support

Creare e configurare la sottoscrizione

È ora possibile creare e configurare la sottoscrizione richiesta. L'obiettivo è creare un processo ripetibile e coerente. Automatizzare la maggior parte del processo di creazione e configurazione della sottoscrizione possibile.

Usare l'infrastruttura come codice (IaC). Una strategia comune per vendita di abbonamenti consiste nel creare e configurare la sottoscrizione a livello di codice tramite IaC. È necessario un contratto commerciale per creare una sottoscrizione di Azure a livello di codice, ma è possibile automatizzare tutti gli aspetti della configurazione della sottoscrizione senza un contratto commerciale. Per altre informazioni, vedi:

Esistono esempi vendita di abbonamenti moduli Bicep e Terraform che consentono di adottare un modello di vendita di abbonamenti indipendentemente dalla registrazione in un contratto commerciale. È consigliabile usare GitHub actions o Azure Pipelines per orchestrare l'automazione.

Usare i tag per la gestione dei costi. È consigliabile automatizzare l'assegnazione coerente dei tag a ogni sottoscrizione per la gestione dei costi e la creazione di report in Gestione costi Microsoft. Anche se si ricevono report di fatturazione con i contratti commerciali, Gestione costi offre una maggiore funzionalità. Ad esempio, è possibile creare report per le sottoscrizioni con tag specifici. Per altre informazioni, vedere Come usare i tag nei dati sui costi e sull'utilizzo e raggruppare e allocare i costi usando l'ereditarietà dei tag

Usare sottoscrizioni di produzione e non di produzione. Nella richiesta di una nuova sottoscrizione è necessario specificare se il carico di lavoro è per Production o DevTest. Gli ambienti DevTest comportano costi di risorse inferiori, ma hanno altri termini. Nota L'offerta DevTest non è disponibile per il Contratto Microsoft Partner. Per altre informazioni, vedi:

Configurare i controlli degli accessi in base al ruolo e delle identità. La gestione dell'accesso alle risorse all'interno di una sottoscrizione di Azure è fondamentale per mantenere un ambiente sicuro e conforme. Per controllare l'accesso, è essenziale configurare identità e RBAC. Questa configurazione comporta la progettazione di un proprietario della sottoscrizione, la creazione di gruppi di Microsoft Entra per gestire l'accesso e la definizione di account di automazione per distribuire i carichi di lavoro.

  • Designare un proprietario della sottoscrizione. L'automazione vendita di abbonamenti deve designare un proprietario della sottoscrizione al momento della creazione. La richiesta di sottoscrizione deve acquisire queste informazioni all'assunzione. I proprietari delle sottoscrizioni possono essere solo utenti o entità servizio nella directory di sottoscrizione selezionata. Non è possibile selezionare gli utenti della directory guest. Se si seleziona un'entità servizio, immettere il relativo ID app.

  • Creare gruppi di Microsoft Entra. Oltre al proprietario della sottoscrizione, è necessario assicurarsi che il processo di distribuzione automatica usi la struttura del gruppo Microsoft Entra per gestire l'accesso alla sottoscrizione. Per l'accesso con privilegi elevati (ad esempio, scrittura), è consigliabile usare PIM per i gruppi. L'automazione di questo processo di creazione non deve violare le procedure consigliate, ad esempio la limitazione del numero di proprietari di sottoscrizioni e l'uso del livello minimo di accesso richiesto.

  • Stabilire le identità del carico di lavoro. Le identità del carico di lavoro (principi del servizio) usate per la distribuzione del carico di lavoro spesso hanno autorizzazioni elevate nell'ambito della sottoscrizione. Il processo di richiesta di sottoscrizione deve raccogliere le esigenze di identità del carico di lavoro in fase di assunzione. Il processo di distribuzione automatica deve creare queste identità e assegnare l'accesso appropriato alla sottoscrizione. È importante notare che l'identità del carico di lavoro non può usare PIM e riceve l'accesso permanente alle risorse. È consigliabile usare le identità gestite per evitare la necessità di gestire i segreti. Per altre informazioni, vedere l'area di progettazione delle identità.

Passare al team dell'applicazione. Dopo aver creato la sottoscrizione, il team della piattaforma deve passare la sottoscrizione al team dell'applicazione.

Aggiornare il budget della sottoscrizione

I team della piattaforma e del carico di lavoro condividono la responsabilità dell'integrità finanziaria della sottoscrizione. La distribuzione deve creare un budget di sottoscrizione in base alle informazioni contenute nella richiesta di sottoscrizione. L'applicazione deve aggiornare il budget per soddisfare le proprie esigenze quando ricevono la sottoscrizione. I budget sono utili per controllare la spesa rispetto all'utilizzo corrente e previsto, ma non sono limiti rigidi. È consigliabile creare avvisi relativi al budget per notificare ai proprietari della sottoscrizione se il carico di lavoro sta per superare la soglia di budget. Per i servizi condivisi, ad esempio Gestione API, prendere in considerazione l'uso delle regole di allocazione dei costi di Azure per ridistribuire i costi tra le sottoscrizioni che usano.

Distribuire il carico di lavoro e operare

Il team dell'applicazione deve avere autonomia per creare le risorse necessarie per il carico di lavoro e gestire le operazioni. Il team della piattaforma rimane responsabile della governance delle sottoscrizioni. Man mano che cambiano i requisiti di governance di un carico di lavoro, il team della piattaforma deve spostare le sottoscrizioni nel gruppo di gestione che soddisfa meglio le esigenze del carico di lavoro. È possibile automatizzare lo spostamento usando Bicep o Terraform. Per altre informazioni, vedi:

Passaggi successivi

Esaminare le sottoscrizioni o le linee di prodotto che è possibile distribuire ai team delle applicazioni. Stabilire un ottimo punto di partenza per soddisfare diversi scenari.

Stabilire linee di prodotto comuni vendita di abbonamenti