Stabilire linee di prodotto comuni vendita di abbonamenti
La distribuzione automatica delle sottoscrizioni consente alle organizzazioni di raggiungere i principi di progettazione della democratizzazione delle sottoscrizioni delle zone di destinazione di Azure, che è fondamentale per la scalabilità coerente, la sicurezza e la governance degli ambienti di Azure. La distribuzione automatica delle sottoscrizioni consente anche alle organizzazioni di allinearsi ai principi di progettazione della piattaforma. Per altre informazioni, vedere Adottare una mentalità orientata ai prodotti e Consentire agli sviluppatori di usare self-service con protezioni.
Molte organizzazioni hanno difficoltà a offrire ai team delle applicazioni la flessibilità necessaria per offrire in modo efficace carichi di lavoro e servizi. Un ostacolo fondamentale è la mancanza di un approccio standardizzato alla vendita di abbonamenti, che può causare confusione, ritardo e inefficienza.
Questo articolo illustra in che modo i team della piattaforma possono stabilire vendita di abbonamenti linee di prodotto comuni che soddisfano le diverse esigenze dei vari team dell'applicazione. L'articolo illustra i vantaggi dell'offerta di varie linee di prodotto e fornisce esempi di scenari comuni basati su distribuzioni reali dei clienti. Si apprenderà anche perché vendita di abbonamenti non ha una progettazione "una dimensione adatta a tutte" e perché è necessario fornire varie linee di prodotto ai team delle applicazioni.
Il diagramma seguente illustra l'organizzazione di gruppi di gestione e sottoscrizioni all'interno di un ambiente Azure.
Le indicazioni seguenti descrivono perché potrebbero essere necessarie diverse linee di prodotto e descrivono esempi di linee di prodotto per i clienti che usano zone di destinazione di Azure e vendita di abbonamenti.
Sfruttare i vantaggi di varie linee di prodotto
Le sottoscrizioni richieste dai team dell'applicazione per fornire i carichi di lavoro e i servizi sono disponibili in molti tipi e stili. All'esterno dei team dell'applicazione, l'organizzazione potrebbe avere altri requisiti che richiedono l'uso di una sottoscrizione di Azure, ad esempio diverse regole di conformità e gestione dei dati o modelli di architettura.
Quando si decide l'approccio dell'organizzazione alla progettazione e all'implementazione di vendita di abbonamenti, è consigliabile porre queste domande:
Quali altre risorse devono essere gestite dal team della piattaforma come parte del processo di vendita di abbonamenti?
Per ogni team di applicazioni, si distribuiscono più sottoscrizioni, ad esempio una per ogni ambiente, per impostazione predefinita?
Per ogni applicazione, eseguire il peering o connettere la rete virtuale spoke agli hub di connettività per impostazione predefinita?
In che modo è consigliabile strutturare il controllo degli accessi in base al ruolo all'interno di ogni sottoscrizione?
Come è necessario gestire e controllare le risorse e gli stili dell'architettura o degli archetipi usati nelle sottoscrizioni?
Non è possibile soddisfare i requisiti univoci di ogni applicazione e team della piattaforma con qualsiasi tipo di sottoscrizione o stile di sottoscrizione che si vende. I team della piattaforma devono offrire ai team delle applicazioni la flessibilità necessaria per scegliere tra più tipi e stili di sottoscrizioni che il team può inviare tramite un sistema self-service. Questi tipi di sottoscrizioni sono detti linee di prodotto.
Le organizzazioni che forniscono solo un approccio "una dimensione adatta a tutte" per vendita di abbonamenti spesso limitano la flessibilità dei clienti interni. Ad esempio, la mancanza di flessibilità potrebbe limitare le scelte di progettazione dell'architettura di un team di applicazioni e potenzialmente causare compromessi a causa di ciò che sono stati vendeti.
Di conseguenza, i team della piattaforma devono fornire diverse linee di prodotto per soddisfare le esigenze dell'organizzazione. Questa flessibilità garantisce che i consumatori possano scegliere la linea di prodotti più adatta alle proprie esigenze.
Gestire gli ambienti dell'applicazione
L'organizzazione deve gestire gli ambienti dell'applicazione per i team delle applicazioni come parte dei processi e delle implementazioni vendita di abbonamenti. Tuttavia, è anche necessario offrire flessibilità in modo che i team delle applicazioni possano gestire gli ambienti dell'applicazione, ad esempio sviluppo/test/produzione, come vogliono quando offrono applicazioni. Per altre informazioni, vedere Ambienti, sottoscrizioni e gruppi di gestione.
Alcuni servizi di Azure offrono funzionalità native per isolare un ambiente all'interno di una singola istanza di risorsa in una singola sottoscrizione di Azure, ad esempio app Azure Servizio con la relativa funzionalità degli slot di distribuzione. Questo esempio impone ai team dell'applicazione di usare sottoscrizioni separate, in modo che i team non possano sfruttare il set completo di funzionalità dei servizi offerti da Azure. Le sottoscrizioni separate possono anche aumentare i costi di recapito delle applicazioni, incluso il sovraccarico operativo e di manutenzione.
Progettare linee di prodotto comuni per vendita di abbonamenti
Ora che si è compreso che i team della piattaforma devono fornire più tipi e stili di sottoscrizione di Azure o linee di prodotto, ai consumer della piattaforma Azure, questa sezione descrive diverse linee di prodotto comuni che è possibile usare in settori e paesi o aree geografiche.
Il team della piattaforma deve usare queste linee di prodotto comuni vendita di abbonamenti come baseline. Il team può offrire più opzioni ai propri consumer predefiniti, che si allineano al principio di progettazione della piattaforma per i clienti con priorità. Questo approccio offre ai clienti interni la libertà di usare i principi di progettazione della zona di destinazione di Azure e le raccomandazioni per l'area di progettazione per offrire carichi di lavoro e servizi e fornisce anche la governance della piattaforma Azure.
Nota
Usare questi esempi come punto di partenza. È possibile personalizzare ed espandere queste linee di prodotto per soddisfare le esigenze dell'organizzazione.
Le linee di prodotto comuni per vendita di abbonamenti includono:
Corp connected: carichi di lavoro che richiedono la connettività tradizionale di routing IP di livello 3 ad altre applicazioni e ambienti locali tramite la sottoscrizione connectivity.
Online: carichi di lavoro che si connettono ad altre applicazioni tramite architetture e servizi di connettività moderni, ad esempio collegamento privato di Azure o interazione tramite API o endpoint esposti da ogni applicazione.
Piattaforma tecnica: carichi di lavoro che creano una piattaforma in cui è possibile creare altre applicazioni. Ad esempio, una flotta di cluster servizio Azure Kubernetes (AKS) gestiti da un team della piattaforma servizio Azure Kubernetes può ospitare altre applicazioni all'interno dei cluster del servizio Azure Kubernetes per conto di altri team dell'applicazione.
Portfolio di applicazioni condivise: carichi di lavoro condivisi tra gli stessi team di applicazioni per un set comune di applicazioni strettamente associate. Non si vuole ospitare le applicazioni autonomamente o con un carico di lavoro specifico.
Sandbox: un'area in cui i team delle applicazioni possono creare un modello di verifica (PoC) o un prodotto minimo funzionante (MVP) e imporre un minor numero di controlli, in modo che il team possa promuovere lo sviluppo, l'invenzione e la libertà di creare la migliore applicazione possibile dal catalogo dei servizi di Azure disponibili.
La linea di prodotti connessa aziendale
La linea di prodotti connessa aziendale, detta anche linea di prodotti interna o privata, per la zona di destinazione dell'applicazione vendita di abbonamenti fornisce connettività tramite metodi IP di livello 3 tradizionali. È possibile usare questa linea di prodotti per fornire connettività tra le risorse che sono:
Nella stessa zona di destinazione dell'applicazione.
In zone di destinazione dell'applicazione connesse all'azienda diverse tramite un'appliance virtuale di rete o un firewall di Azure.
In locale o in cloud diversi tramite Azure ExpressRoute o connessioni VPN.
Le organizzazioni che usano vendita di abbonamenti spesso incorporano questa linea di prodotti perché si allineano strettamente al funzionamento attuale della maggior parte degli ambienti locali. Tuttavia, è consigliabile usare la linea di prodotti connessa aziendale solo quando è necessario. È consigliabile preferire approcci nativi del cloud più moderni, ad esempio la linea di prodotti online, quando possibile.
Suggerimento
Per informazioni sulle differenze tra carichi di lavoro di corp e online, vedere Qual è lo scopo dei gruppi di gestione connectivity, Corp e Online?
Il diagramma seguente illustra un esempio della linea di prodotti vendita di abbonamenti connessa all'azienda. È possibile usare questa configurazione per un modello di rete hub-spoke per gestire efficacemente il traffico e i criteri di rete.
Quando usare la linea di prodotti connessa aziendale
Usare la linea di prodotti connessa aziendale quando:
Si vogliono eseguire migrazioni rehosting e refactoring e compilazioni di applicazioni in base alle cinque rs della razionalizzazione.
Si vuole iniziare il percorso in Azure e si ha familiarità con un'architettura locale simile.
Si vogliono trasferire in Azure le applicazioni in modalità lift-and-shift.
Si vuole migliorare la sicurezza tra i carichi di lavoro isolando le applicazioni nelle proprie sottoscrizioni di zona di destinazione e passando ai principi di micro-segmentazione da zero-trust senza ancora riprogettare l'applicazione in modo che sia completamente nativa del cloud.
Prendere nota di queste altre considerazioni per la linea di prodotti connessa aziendale:
Il team della piattaforma può distribuire la rete virtuale nella sottoscrizione della zona di destinazione dell'applicazione ed eseguire il peering della rete virtuale all'hub regionale o all'hub di Azure rete WAN virtuale. Il team può quindi usare uno strumento di gestione degli indirizzi IP per controllare l'allocazione degli indirizzi IP.
I team della piattaforma in genere non distribuiscono subnet o altre risorse nella rete virtuale. I team della piattaforma assegnano invece queste attività ai team delle applicazioni in modo che possano progettare la rete delle applicazioni come vogliono.
I team della piattaforma usano criteri di Azure assegnati ai gruppi di gestione sopra la sottoscrizione per applicare il comportamento desiderato, ad esempio i gruppi di sicurezza di rete standardizzati collegati a ogni subnet. Il team dell'applicazione eredita questo criterio di Azure e non può modificarlo. Questo approccio segue il principio di progettazione della zona di destinazione di Azure della democratizzazione delle sottoscrizioni.
La linea di prodotti online
La linea di prodotti online, detta anche linea di prodotto esterna o pubblica, per la zona di destinazione dell'applicazione vendita di abbonamenti non fornisce connettività tramite metodi IP di livello 3 tradizionali tra le risorse in altre zone di destinazione dell'applicazione o in locale tramite connessioni ExpressRoute o VPN. Le risorse nella stessa sottoscrizione della zona di destinazione dell'applicazione online possono usare le reti virtuali per comunicare tra loro tramite metodi IP di livello 3. Tuttavia, le reti virtuali in genere non vengono sottoposte a peering a hub di connettività a livello di area o ad altre zone di destinazione dell'applicazione.
È invece possibile fornire connettività tramite interfacce pubbliche tra le risorse che sono:
In zone di destinazione dell'applicazione diverse.
Locale.
Nei carichi di lavoro che si trovano in cloud diversi.
È possibile proteggere le connessioni con controlli di rete, funzionalità di autenticazione e funzionalità di autorizzazione esposte dalle varie soluzioni PaaS (Platform as a Service) usate per costruire l'applicazione.
È possibile usare il servizio collegamento privato e gli endpoint privati di Azure all'interno e tra le sottoscrizioni della zona di destinazione dell'applicazione online per abilitare ed esporre la connettività privata basata sul livello 3 tra le applicazioni. È anche possibile usare questo approccio tra i servizi PaaS usati all'interno delle zone di destinazione dell'applicazione per impedire l'uso di queste interfacce pubbliche dei servizi PaaS per la sicurezza o il controllo normativo.
È anche possibile usare il servizio collegamento privato con endpoint privati per esporre e pubblicare applicazioni ospitate all'interno delle zone di destinazione dell'applicazione online in zone di destinazione dell'applicazione connesse, posizioni locali o altri cloud. È possibile inserire endpoint privati nelle zone di destinazione dell'applicazione connesse all'azienda o direttamente negli hub di connettività, che quindi concedono l'accesso a questi endpoint privati tramite metodi di connettività tradizionali di livello 3, ad esempio il peering di rete virtuale, le connessioni ExpressRoute o le connessioni VPN.
Si pensi alla linea di prodotto della zona di destinazione dell'applicazione online come isole isolate. Per impostazione predefinita, le uniche risorse che possono accedere alle risorse all'interno della sottoscrizione sono le risorse distribuite all'interno della stessa sottoscrizione dell'area di destinazione dell'applicazione online. Come accennato in precedenza, è quindi possibile usare le tecniche descritte in questo articolo per espandere la connettività ad altre zone di destinazione dell'applicazione, posizioni locali o altri cloud.
Suggerimento
Per altre informazioni sulle differenze tra carichi di lavoro di corp e online, vedere Qual è lo scopo dei gruppi di gestione connectivity, Corp e Online?
Il diagramma seguente mostra un esempio di linea vendita di abbonamenti prodotto online.
Quando utilizzare la linea di prodotti online
Utilizzare la linea di prodotti online quando si desidera:
Effettuare il refactoring, riprogettare, ricompilare ed eseguire migrazioni e compilazioni di applicazioni, in base alle cinque rs della razionalizzazione.
Fornire ai team delle applicazioni una zona di destinazione dell'applicazione completamente democratizzata da usare, anche per quanto riguarda la configurazione di rete.
Sfruttare i vantaggi di servizi e architetture nativi del cloud.
Migliorare notevolmente l'allineamento con i principi zero-trust.
Usare la linea di prodotti connessa aziendale, ma lo spazio degli indirizzi IP privati non è disponibile o limitato.
- In questo scenario è necessario esaminare le indicazioni riportate in Impedire l'esaurimento IPv4 in Azure.
La linea di prodotti della piattaforma Tech
I team che usano piattaforme tecnologiche, ad esempio soluzione Azure VMware o Desktop virtuale Azure, devono implementare la linea di prodotti della piattaforma tecnologica. La linea di prodotti della piattaforma tecnologica è essenzialmente una linea di prodotti vendita di abbonamenti più adatta ai requisiti altamente tecnici. È possibile usare la linea di prodotti della piattaforma tech per ospitare e gestire carichi di lavoro complessi e di grandi dimensioni che in genere ospitano più applicazioni per diversi altri team dell'applicazione nell'organizzazione. Usare questa linea di prodotto se il team dell'applicazione gestisce solo le parti dell'applicazione e non le parti della piattaforma tecnologica sottostante.
Suggerimento
Per comprendere meglio questa linea di prodotti, considerare l'esempio seguente. Un team della piattaforma tecnologica, come un team del servizio Azure Kubernetes, mira a offrire il servizio Azure Kubernetes come servizio gestito ad altri team di applicazioni che devono eseguire le proprie applicazioni nella piattaforma servizio Azure Kubernetes. Il team della piattaforma tecnica del servizio Azure Kubernetes fornisce la gestione, la manutenzione, la sicurezza e la configurazione del servizio Azure Kubernetes. Il team dell'applicazione mantiene quindi solo l'applicazione e la distribuisce nella piattaforma.
È possibile includere i prodotti seguenti in una linea di prodotti della piattaforma tecnologica:
Un ambiente del servizio app, in genere tramite piani di servizio app separati.
Il servizio Azure Kubernetes, in genere tramite spazi dei nomi all'interno di uno o più cluster.
Azure Macchine virtuali in cluster o host di soluzione Azure VMware.
Desktop virtuale Azure per fornire desktop virtuali o applicazioni all'intera organizzazione.
È possibile includere questi prodotti nelle linee di prodotto connesse o online, a seconda dei requisiti per la piattaforma tecnologica che il team vuole fornire come servizio ad altri team dell'applicazione nell'organizzazione.
Portfolio di applicazioni condivise
La linea di prodotto del portfolio di applicazioni condivise per la zona di destinazione dell'applicazione vendita di abbonamenti riguarda i carichi di lavoro che non necessitano di diverse sottoscrizioni di zone di destinazione dell'applicazione separate per applicazioni semplici che potrebbero essere costruite solo da un numero ridotto di risorse di Azure.
I team dell'applicazione e i reparti possono usare questa linea di prodotti per ospitare diverse applicazioni di piccole dimensioni o componenti condivisi, ad esempio account di archiviazione o server SQL. I team condividono questi componenti tra diverse applicazioni in una singola sottoscrizione o un numero ridotto di sottoscrizioni.
Importante
Un team comune possiede sottoscrizioni che si vende sotto questa linea di prodotti. Questo team gestisce il portfolio correlato di applicazioni distribuite in questa sottoscrizione per questa linea di prodotti. Non usare questa linea di prodotti per distribuzioni generali di carichi di lavoro di applicazioni non correlati con proprietari distinti del portfolio di applicazioni.
Pianificare attentamente per garantire flessibilità continua, controllo di accesso, governance e manutenibilità se l'organizzazione cambia in una singola sottoscrizione e usa i gruppi di risorse per delegare l'accesso.
Se si considera la delega del gruppo di risorse in una singola sottoscrizione tra più team, tenere presenti le considerazioni seguenti prima di prendere una decisione finale:
| Area | Considerazioni |
|---|---|
| Proprietà comune del portfolio di applicazioni correlate | - Avere un proprietario comune, ad esempio una business unit di un reparto, gestire le applicazioni per semplificare la gestione delle modifiche in modo che rimanga all'interno dell'ambito di approvazione della stessa entità. - Assicurarsi che i carichi di lavoro seguano l'assegnazione coerente dei criteri nella sottoscrizione, tra cui registrazione, monitoraggio e sicurezza. |
| Conformità alle normative | - Usare IAM e i criteri di Azure per creare sottoscrizioni per carichi di lavoro con requisiti di conformità alle normative, tra cui National Institute of Standards and Technology (NIST), Center for Internet Security (CIS), Payment Card Industry Security Standards Council (PCI SSC), requisiti del settore e requisiti regionali. Per altre informazioni, vedere Adattare le zone di destinazione di Azure. - Creare sottoscrizioni per carichi di lavoro che usano requisiti di privacy e gestione dei dati per la governance. Le singole sottoscrizioni riducono l'accesso. |
| Criteri di Azure | Definire l'ambito dei criteri di Azure per gruppi di gestione, sottoscrizioni, gruppi di risorse e risorse. Assegnare criteri di Azure a un livello di ambito elevato per una governance efficiente quando si distribuiscono le risorse nei gruppi di risorse. Quando si gestiscono Criteri di Azure a livello di ambito del gruppo di risorse, considerare i vincoli seguenti: - Aumenta il sovraccarico di gestione per creare assegnazioni Criteri di Azure quando si aggiungono nuovi gruppi di risorse alle sottoscrizioni - Aumenta il carico di lavoro quando si gestiscono le modifiche alle assegnazioni dei criteri - Aumenta le lacune di sicurezza e governance quando non si assegnano immediatamente criteri ai gruppi di risorse - Riduce la possibilità di eseguire il rollup dello stato di conformità in ambiti elevati, ad esempio gruppi di gestione e sottoscrizioni |
| Limiti delle sottoscrizioni | - Controllare i limiti per assicurarsi che le applicazioni non riscontrino limiti rigidi che impediscono la crescita. Ogni sottoscrizione presenta limiti flessibili e rigidi per i servizi di Azure. - Creare sottoscrizioni separate per le applicazioni che prevedono modelli di crescita di grandi dimensioni che soddisfano i limiti delle sottoscrizioni. - Non condividere le sottoscrizioni con i team delle applicazioni di diverse business unit o reparti per evitare problemi rumorosi nei vicini . |
| Allineamento di servizi e funzionalità di Azure | È possibile distribuire servizi che forniscono primitive di base del servizio di Azure, ad esempio Macchine virtuali, reti virtuali e semplici servizi PaaS, all'interno di un singolo gruppo di risorse. Tuttavia, la complessità delle offerte composite moderne può richiedere la distribuzione di questi servizi più complessi al di fuori dei limiti di un singolo gruppo di risorse. Usare altri approcci di sottoscrizione democratizzati descritti in precedenza in questo articolo per questi scenari di distribuzione. |
| Solo i team della piattaforma possono creare gruppi di risorse | Quando si condivide una sottoscrizione tra vari team di applicazioni tra le business unit o i reparti, è possibile limitare la capacità di qualsiasi team di creare nuovi gruppi di risorse nella sottoscrizione condivisa. Questa restrizione limita lo sprawl del gruppo di risorse. Solo il team della piattaforma può creare e gestire nuovi gruppi di risorse. Questo approccio aumenta la complessità delle assegnazioni di controllo degli accessi in base al ruolo e pone una maggiore dipendenza dai team della piattaforma per gestire le distribuzioni di applicazioni, che possono impedire l'agilità e l'responsabilizzazione dei team delle applicazioni. |
È possibile inserire le sottoscrizioni che si distribuisce nella linea di prodotti del portfolio di applicazioni condivise in gruppi di gestione Corp o Online. Questo metodo è allineato alla gerarchia consigliata predefinita delle zone di destinazione di Azure. In alternativa, è possibile inserire le sottoscrizioni sotto i nuovi gruppi di gestione se la gerarchia dei gruppi di gestione dell'organizzazione segue le indicazioni riportate in Personalizzare l'architettura della zona di destinazione di Azure per soddisfare i requisiti.
Il diagramma seguente mostra un esempio del portfolio di applicazioni condivise vendita di abbonamenti linea di prodotti.
Usare la linea di prodotto portfolio di applicazioni condivise se:
Il team dell'applicazione deve distribuire diverse piccole risorse o componenti condivisi dalle applicazioni, ma i componenti non rientrano direttamente in nessuna delle zone di destinazione dell'applicazione dedicate.
Sono disponibili risorse o componenti che è necessario condividere tra applicazioni nello stesso reparto, ma i componenti non rientrano direttamente nelle zone di destinazione dell'applicazione dedicate.
I team della piattaforma tecnologica vogliono ospitare servizi condivisi di grandi dimensioni gestiti, ad esempio servizio Azure Kubernetes, Desktop virtuale Azure e soluzione Azure VMware, in modo che altri team applicazioni possano usare o ospitare le applicazioni nei servizi.
Sandbox
Usare la linea di prodotti sandbox per la zona di destinazione dell'applicazione vendita di abbonamenti per fornire aree di test sicure, leggere e visibili per creare PC o MVP in Azure.
Per altre informazioni, vedere Ambienti sandbox della zona di destinazione e Gestire gli ambienti di sviluppo di applicazioni nelle zone di destinazione di Azure.
Le sandbox sono spesso vincolate dal tempo o vincolate dal budget, il che significa che hanno un limite di tempo o un limite di budget. In questi casi, è necessario estendere o rimuovere e rimuovere la sandbox.
Se l'organizzazione non fornisce una linea di prodotti sandbox per i team delle applicazioni o altri utenti per testare ed sperimentare i servizi in Azure, i team potrebbero ricorrere alle configurazioni IT shadow. In tal caso, l'organizzazione potrebbe avere difficoltà a fornire report e visibilità e applicare la governance alle sottoscrizioni create dagli utenti aziendali al di fuori del controllo e della supervisione del team della piattaforma.
Il team della piattaforma deve fornire accesso facilmente accessibile, preferibilmente self-service e approvato automaticamente alle sottoscrizioni sandbox per gli utenti e i team dell'organizzazione. Fornire agli utenti e ai team l'accesso a un ambiente che il team della piattaforma può visualizzare e gestire per impedire gli ambienti IT shadow a cui il team della piattaforma non può accedere o controllare, creando rischi.
Le sandbox spesso seguono l'approccio di configurazione della rete delle sottoscrizioni line-line online perché non vengono sottoposte a peering ad altre reti virtuali al di fuori del limite della sottoscrizione della sandbox. Le sandbox hanno spesso controlli aggiuntivi per impedire la connettività ibrida a posizioni locali o altre posizioni. Usare questi controlli in modo che le origini sconosciute non possano esfiltrare dati da sandbox a percorsi non approvati. È possibile usare criteri di Azure per applicare questi controlli.
Proprio come il portfolio di applicazioni condivise e le linee di prodotti della piattaforma tecnologica, è anche possibile condividere la linea di prodotti sandbox tra i team nello stesso reparto con le stesse considerazioni. Non creare una singola sottoscrizione sandbox e condividerla tra i team tramite gruppi di risorse. Creare invece sottoscrizioni sandbox aggiuntive.
Usare la linea di prodotti sandbox se è necessario fornire una sottoscrizione di Azure sicura, sicura e regolamentata a chiunque nell'organizzazione voglia sperimentare, creare PC o creare MVP in Azure. È necessario gestire gli utenti in modo leggero e concedere loro l'accesso a tutti i servizi per impedire le procedure IT shadow.
Riepilogo e considerazioni
Questo articolo illustra le linee guida prescrittive per esplorare processi di vendita di abbonamenti complessi e passare all'implementazione.
Determinare i requisiti dei team delle applicazioni future per scegliere la linea di prodotti vendita di abbonamenti più adatta alle proprie esigenze. Identificare i requisiti per il set iniziale di carichi di lavoro creati o migrati per definire la priorità delle linee di prodotto vendita di abbonamenti che si desidera abilitare ed esporre tramite un'interfaccia self-service.
Ogni linea di prodotto ha un costo di implementazione e un costo di manutenzione. Valutare i costi a lungo termine rispetto ai vantaggi e all'utilizzo a lungo termine.
I clienti in genere abilitano inizialmente le seguenti vendita di abbonamenti linee di prodotto:
Risorse aggiuntive
Per supportare ulteriormente l'approccio di progettazione della piattaforma, esaminare le risorse seguenti durante la progettazione e l'implementazione delle linee di prodotto e delle offerte vendita di abbonamenti dell'organizzazione:
- Video: Quante sottoscrizioni è consigliabile usare in Azure?
- Zone di destinazione della piattaforma e zone di destinazione dell'applicazione
- Criteri inclusi nelle implementazioni di riferimento delle zone di destinazione di Azure
- Personalizzare l'architettura della zona di destinazione di Azure per soddisfare i requisiti
- Qual è lo scopo dei gruppi di gestione Connectivity, Corp e Online?
- Gestire gli ambienti di sviluppo di applicazioni nelle zone di destinazione di Azure
- Principi di progettazione della piattaforma
Passaggio successivo
Per ottenere risultati ottimali, è consigliabile automatizzare la maggior parte del processo vendita di abbonamenti possibile. Usare il materiale sussidiario complementare sull'implementazione dell'automazione vendita di abbonamenti.