Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Azure offre molte opzioni per organizzare le risorse. In una soluzione multi-tenant è necessario considerare compromessi specifici quando si pianifica la strategia dell'organizzazione delle risorse. Questo articolo è incentrato su due elementi principali dell'organizzazione delle risorse di Azure: isolamento del tenant e scalabilità orizzontale tra più risorse. Descrive alcuni approcci di distribuzione comuni che possono supportare modelli di isolamento del tenant diversi. Questo articolo descrive anche come usare limiti e quote delle risorse di Azure e come ridimensionare la soluzione oltre questi limiti.
Considerazioni e requisiti chiave
Le sezioni seguenti descrivono l'isolamento del tenant e le considerazioni sulla scalabilità da tenere presenti quando si organizzano le risorse di Azure.
Requisiti di isolamento del tenant
Quando si distribuisce una soluzione multi-tenant in Azure, è necessario decidere se dedicare risorse a ogni tenant o condividere risorse tra più tenant. Le sezioni relative agli approcci multi-tenancy e alle linee guida specifiche del servizio di questa serie di articoli descrivono le opzioni e i compromessi per molte categorie di risorse. In generale, sono disponibili diverse opzioni per l'isolamento del tenant. Per altre informazioni su come decidere il modello di isolamento, vedere Modelli di tenancy per una soluzione multi-tenant.
Scala
La maggior parte delle risorse, dei gruppi di risorse e delle sottoscrizioni di Azure impone limiti che possono influire sulla capacità di ridimensionare. Potrebbe essere necessario prendere in considerazione la scalabilità orizzontale o la compressione dei contenitori per soddisfare il numero pianificato di tenant o il carico di sistema pianificato.
Se sai con certezza che non arriverai ad avere un numero elevato di tenant o un carico elevato, non complicare eccessivamente il tuo piano di scalabilità orizzontale. Tuttavia, se prevedi di far crescere la tua soluzione, valuta attentamente il tuo piano di scalabilità orizzontale. Seguire le indicazioni riportate in questo articolo per assicurare di progettare per la scalabilità.
Se si dispone di un processo di distribuzione automatizzato e si deve gestire l'espansione delle risorse, stabilire come si intende eseguire la distribuzione e assegnare i tenant tra le varie istanze di risorse. Si consideri ad esempio come rilevare quando si avvicina il numero di tenant che è possibile assegnare a una risorsa specifica. È possibile pianificare la distribuzione di nuove risorse al momento giusto, proprio quando ne hai bisogno. In alternativa, è possibile distribuire in anticipo un pool di risorse in modo che siano pronti per l'uso quando sono necessari.
Suggerimento
Nelle prime fasi di progettazione e sviluppo, è possibile non scegliere di implementare processi di scalabilità orizzontale automatizzati. È comunque consigliabile prendere in considerazione e documentare chiaramente i processi necessari per la scalabilità man mano che si cresce. Documentando i processi, è più semplice automatizzarli in caso di necessità in futuro.
È anche importante evitare di fare ipotesi in tutto il codice e la configurazione che possono limitare la scalabilità. Ad esempio, potrebbe essere necessario espandere a più account di archiviazione in futuro. Quando costruisci il livello dell'applicazione, assicurati che possa passare dinamicamente all'account di archiviazione a cui si connette in base al tenant attivo.
Approcci e modelli da considerare
Quando si pianifica l'organizzazione delle risorse di Azure, prendere in considerazione i seguenti approcci: isolamento dei tenant, raggruppamento binario, tag delle risorse e stack di deployment.
Isolamento degli inquilini
Le risorse di Azure vengono distribuite e gestite tramite una gerarchia. La maggior parte delle risorse viene distribuita in gruppi di risorse, contenuti nelle sottoscrizioni. I gruppi di gestione raggruppano logicamente le sottoscrizioni. Tutti questi livelli gerarchici sono associati a un tenant di Microsoft Entra.
Quando si determina come distribuire le risorse per ogni tenant, è possibile isolare a livelli diversi nella gerarchia. Ogni opzione è valida per tipi specifici di soluzioni multi-tenant e ogni opzione include vantaggi e compromessi. È anche comune combinare approcci usando modelli di isolamento diversi per diversi componenti di una soluzione.
Isolamento all'interno di una risorsa condivisa
È possibile scegliere di condividere una risorsa di Azure tra più tenant ed eseguire tutti i carichi di lavoro in una singola istanza. Per considerazioni o opzioni specifiche che potrebbero essere importanti, vedere le linee guida specifiche del servizio per i servizi di Azure usati.
Quando si eseguono singole istanze di una risorsa, è necessario prendere in considerazione eventuali limiti del servizio, limiti di sottoscrizione o quote che è possibile raggiungere durante la scalabilità. Ad esempio, esiste un numero massimo di nodi supportati da un cluster del servizio Azure Kubernetes e un limite superiore per il numero di transazioni al secondo supportato da un account di archiviazione. Pianifica la scalabilità a più risorse condivise in prossimità di questi limiti.
È anche necessario assicurarsi che il codice dell'applicazione sia completamente consapevole della multi-tenancy e che limiti l'accesso ai dati per un tenant specifico.
Come esempio dell'approccio alle risorse condivise, si supponga che Contoso stia creando un'applicazione SaaS (Software as a Service) multi-tenant che include un'applicazione Web, un database e un account di archiviazione. Potrebbero decidere di distribuire risorse condivise per il servizio di tutti i clienti. Nel diagramma seguente tutti i clienti condividono un singolo set di risorse.
Nel diagramma, una casella che rappresenta il tenant di Microsoft Entra per Contoso contiene un'altra casella che rappresenta la sottoscrizione di Azure di Contoso. Tale casella contiene un'altra casella che rappresenta un gruppo di risorse condiviso. Contiene l'applicazione, il database e l'archiviazione.
Separare le risorse in un gruppo di risorse
È anche possibile distribuire risorse dedicate per ogni tenant. È possibile distribuire un'intera copia della soluzione per un singolo tenant. In alternativa, è possibile condividere alcuni componenti tra tenant e dedicare altri componenti a un tenant specifico. Questo approccio è noto come partizionamento orizzontale.
È consigliabile usare i gruppi di risorse per gestire le risorse con lo stesso ciclo di vita. In alcuni sistemi multi-tenant è opportuno distribuire risorse per più tenant in un singolo gruppo di risorse o in un set di gruppi di risorse.
È importante considerare come distribuire e gestire queste risorse, ad esempio se la pipeline di distribuzione o l'applicazione avvia la distribuzione di risorse specifiche del tenant. È anche necessario determinare come identificare chiaramente le risorse specifiche correlate a locatari specifici. Valuta l'uso di una chiara strategia di convenzioni di denominazione, dei tag delle risorse o di un database di catalogo del tenant.
È consigliabile usare gruppi di risorse separati per le risorse condivise tra più tenant e le risorse distribuite per singoli tenant. Tuttavia, per alcune risorse, Azure limita il numero di risorse di un singolo tipo che possono essere distribuite in un gruppo di risorse. Questo limite significa che potrebbe essere necessario ridimensionare più gruppi di risorse man mano che si aumenta.
Si supponga che Contoso abbia tre clienti o tenant: Adventure Works, Fabrikam e Tailwind. Possono scegliere di condividere l'applicazione Web e l'account di archiviazione tra i tre tenant e quindi distribuire singoli database per ogni tenant. Il diagramma seguente mostra un gruppo di risorse che contiene risorse condivise e un gruppo di risorse che contiene il database di ogni tenant.
Nel diagramma, una casella che rappresenta il tenant di Microsoft Entra per Contoso contiene un'altra casella che rappresenta la sottoscrizione di Azure di Contoso. Tale casella contiene un'altra casella contenente due gruppi di risorse. Un gruppo di risorse contiene l'applicazione e l'archiviazione e viene contrassegnato come condiviso. L'altro gruppo di risorse contiene un database tenant per ogni cliente: Adventure Works, Fabrikam e Tailwind.
Separare i gruppi di risorse in una sottoscrizione
Quando si distribuisce un set di risorse per ogni tenant, è consigliabile usare gruppi di risorse dedicati specifici del tenant. Ad esempio, quando si segue il modello Impronta di distribuzione, è necessario distribuire ogni impronta nel proprio gruppo di risorse. È possibile valutare la possibilità di distribuire più gruppi di risorse specifici del tenant in una sottoscrizione di Azure condivisa. Questo approccio consente di configurare facilmente criteri e regole di controllo di accesso.
È possibile scegliere di creare un set di gruppi di risorse per ogni tenant e gruppi di risorse condivisi per tutte le risorse condivise.
Quando si distribuiscono gruppi di risorse specifici del tenant in sottoscrizioni condivise, tenere presente il numero massimo di gruppi di risorse in ogni sottoscrizione e altri limiti a livello di sottoscrizione applicabili alle risorse distribuite. Man mano che ci si avvicina a questi limiti, potrebbe essere necessario distribuire il carico tra più sottoscrizioni.
Nell'esempio Contoso potrebbe scegliere di distribuire un timbro per ognuno dei clienti e inserire i francobolli in gruppi di risorse dedicati all'interno di una singola sottoscrizione. Nel diagramma seguente viene creata una sottoscrizione, che contiene tre gruppi di risorse, per ogni cliente.
Nel diagramma, una casella che rappresenta il tenant di Microsoft Entra per Contoso contiene un'altra casella che rappresenta la sottoscrizione di Azure di Contoso. Tale casella contiene un'altra casella contenente tre gruppi di risorse. Ogni gruppo di risorse contiene l'applicazione, il database e l'archiviazione per ogni cliente: Adventure Works, Fabrikam e Tailwind.
Sottoscrizioni separate
È possibile distribuire sottoscrizioni specifiche del tenant per isolare completamente le risorse specifiche del tenant. È anche possibile assicurarsi che ogni tenant disponga di tutte le quote applicabili usando una sottoscrizione separata per ogni tenant perché la maggior parte delle quote e dei limiti si applica all'interno di una sottoscrizione. Per alcuni tipi di account di fatturazione di Azure, è possibile creare sottoscrizioni a livello di codice. È anche possibile usare Prenotazioni di Azure e Piano di risparmio di Azure per il calcolo tra le sottoscrizioni.
Assicurarsi di conoscere il numero di sottoscrizioni che è possibile creare. Il numero massimo di sottoscrizioni può variare a seconda della relazione commerciale con Microsoft o di un partner Microsoft, ad esempio se si ha un contratto Enterprise.
Può essere più difficile richiedere aumenti di quota quando si lavora in un numero elevato di sottoscrizioni. La Quota API fornisce un'interfaccia programmatica per alcuni tipi di risorse. Tuttavia, per molti tipi di risorse, gli aumenti di quota devono essere richiesti aprendo un caso di supporto. Può anche essere difficile lavorare con i contratti di supporto di Azure e i casi di supporto quando si lavora con molte sottoscrizioni.
Valutare la possibilità di raggruppare le sottoscrizioni specifiche del tenant in una gerarchia di gruppi di gestione per semplificare la gestione delle regole e dei criteri di controllo di accesso.
Si supponga, ad esempio, che Contoso decida di creare sottoscrizioni di Azure separate per ognuno dei clienti, come illustrato nel diagramma seguente. Ogni sottoscrizione contiene un gruppo di risorse che include il set completo di risorse per il cliente.
Nel diagramma, una casella che rappresenta il tenant di Microsoft Entra per Contoso contiene un'altra casella che rappresenta il gruppo di gestione. Il gruppo di gestione contiene tre caselle separate che rappresentano una sottoscrizione di Azure per ogni cliente: Adventure Works, Fabrikam e Tailwind. Ogni sottoscrizione di Azure contiene un'altra casella che rappresenta il gruppo di risorse per ogni cliente. Ogni gruppo di risorse contiene l'applicazione, il database e l'archiviazione per ogni cliente.
Ogni sottoscrizione contiene un gruppo di risorse che include il set completo di risorse per il cliente.
In questo esempio Contoso usa un gruppo di gestione per semplificare la gestione delle sottoscrizioni. Includendo Produzione nel nome del gruppo di gestione, possono distinguere chiaramente i tenant di produzione dai tenant non di produzione o dai tenant di test. Regole e criteri di controllo di accesso di Azure diversi si applicano ai tenant non di produzione.
Tutte le sottoscrizioni di Contoso sono associate a un singolo tenant di Microsoft Entra. Usando un singolo tenant di Microsoft Entra, Contoso può usare le identità del team, inclusi gli utenti e le entità servizio, nell'intero ambiente di Azure.
Sottoscrizioni separate in tenant di Microsoft Entra separati
È anche possibile creare manualmente singoli tenant di Microsoft Entra per ognuno dei tenant o distribuire le risorse nelle sottoscrizioni all'interno dei tenant di Microsoft Entra dei clienti. Tuttavia, l'uso di più tenant di Microsoft Entra rende più difficile l'autenticazione, la gestione delle assegnazioni di ruolo, l'applicazione di criteri globali e l'esecuzione di molte altre operazioni di gestione.
Avvertimento
Sconsigliamo di creare più tenant di Microsoft Entra per la maggior parte delle soluzioni multitenant. Lavorare tra i tenant di Microsoft Entra introduce complessità aggiuntive e riduce la capacità di ridimensionare e gestire le risorse. In genere, questo approccio viene usato solo dai provider di servizi gestiti (MSP) che gestiscono ambienti Di Azure per conto dei clienti.
Prima di eseguire uno sforzo per distribuire più tenant di Microsoft Entra, valutare se è possibile ottenere i requisiti usando invece gruppi di gestione o sottoscrizioni all'interno di un singolo tenant.
Nelle situazioni in cui è necessario gestire le risorse di Azure in sottoscrizioni associate a più tenant di Microsoft Entra, valuta l'uso di Azure Lighthouse per semplificare la gestione delle risorse tra i tenant di Microsoft Entra.
Ad esempio, Contoso può creare tenant Microsoft Entra separati e sottoscrizioni di Azure separate per ognuno dei clienti, come illustrato nel diagramma seguente.
Nel diagramma tre caselle separate rappresentano il tenant di Microsoft Entra per ognuno dei clienti di Contoso: Adventure Works, Fabrikam e Tailwind. Ogni tenant contiene un'altra casella che rappresenta la sottoscrizione di Azure per ogni cliente. Ogni sottoscrizione di Azure contiene un'altra casella che rappresenta il gruppo di risorse per ogni cliente. Ogni gruppo di risorse contiene l'applicazione, il database e l'archiviazione per ogni cliente. Sul lato destro del diagramma, una linea blu rappresenta Azure Lighthouse. Una freccia parte da questa linea blu e punta a ognuno dei tenant di Microsoft Entra.
Un tenant di Microsoft Entra è configurato per ognuno dei tenant di Contoso. Ogni tenant contiene una sottoscrizione e le risorse necessarie per ogni cliente. Azure Lighthouse è connesso a ogni tenant di Microsoft Entra.
Imballaggio bin
Indipendentemente dal modello di isolamento delle risorse, è importante considerare quando e come prevedi di scalare la tua soluzione su più risorse. Potrebbe essere necessario ridimensionare le risorse man mano che il carico nel sistema aumenta o man mano che aumenta il numero di tenant. Prendere in considerazione la creazione di contenitori per distribuire un numero ottimale di risorse per i requisiti.
Suggerimento
In molte soluzioni è più semplice ridimensionare l'intero set di risorse insieme anziché ridimensionare singolarmente le risorse. Valuta di seguire il modello Deployment Stamps pattern.
Limiti delle risorse
Le risorse di Azure hanno limiti e quote che è necessario prendere in considerazione nella pianificazione della soluzione. Ad esempio, le risorse potrebbero supportare un numero massimo di richieste simultanee o impostazioni di configurazione specifiche del tenant.
Il modo in cui si configura e si usa ogni risorsa influisce anche sulla scalabilità di tale risorsa. Si supponga, ad esempio, che l'applicazione possa rispondere correttamente a un numero definito di transazioni al secondo quando è disponibile una quantità specifica di risorse di calcolo. Oltre questo punto, potrebbe essere necessario scalare orizzontalmente. I test delle prestazioni aiutano a identificare il punto in cui le risorse non soddisfano più i tuoi requisiti.
Annotazioni
Il principio di ridimensionamento a più risorse si applica anche quando si lavora con servizi che supportano più istanze.
Ad esempio, Servizio app di Azure supporta la scalabilità orizzontale del numero di istanze del piano, ma esistono limiti su fino a che punto è possibile scalare un singolo piano. In un'app multi-tenant su larga scala, è possibile superare questi limiti e distribuire più piani di servizio app per soddisfare la crescita.
Quando si condividono alcune delle risorse tra tenant, è necessario innanzitutto determinare il numero di tenant supportati dalla risorsa quando è configurato in base ai requisiti. Quindi, distribuisci tutte le risorse necessarie per supportare il numero totale di tenant.
Ad esempio, supponiamo di distribuire gateway applicazione di Azure come parte di una soluzione SaaS multi-tenant. Rivedi la progettazione dell'applicazione, testi le prestazioni del gateway applicativo sotto carico e ne rivedi la configurazione. Si determina quindi che una singola risorsa del gateway applicazione può essere condivisa tra 100 clienti. In base al piano di crescita dell'organizzazione, si prevede di eseguire l'onboarding di 150 clienti nel primo anno, quindi è necessario pianificare la distribuzione di più gateway applicazione per il servizio del carico previsto.
Nel diagramma, una casella che rappresenta una sottoscrizione contiene un'altra casella che rappresenta un gruppo di risorse. Il gruppo di risorse contiene due gateway applicativi. Un gateway è dedicato ai clienti da 1 a 100 e l'altro è dedicato ai clienti da 101 a 200.
Il diagramma mostra due gateway applicazioni. Il primo gateway è dedicato ai clienti da 1 a 100 e il secondo è dedicato ai clienti da 101 a 200.
Limiti relativi a gruppi di risorse e sottoscrizioni
Sia che si lavori con risorse condivise o dedicate, è importante tenere conto dei limiti. Azure limita il numero di risorse che possono essere distribuite in un gruppo di risorse e in una sottoscrizione di Azure. Quando si avvicinano questi limiti, è necessario pianificare la scalabilità tra più gruppi di risorse o sottoscrizioni.
Ad esempio, supponiamo di distribuire un gateway applicativo dedicato per ciascuno dei clienti in un gruppo di risorse condivise. Per alcune risorse, Azure supporta la distribuzione di un massimo di 800 risorse dello stesso tipo all'interno di un singolo gruppo di risorse. Pertanto, quando si raggiunge questo limite, è necessario distribuire qualsiasi nuovo gateway applicativo in un altro gruppo di risorse. Nel diagramma seguente sono presenti due gruppi di risorse. Ogni gruppo di risorse contiene 800 gateway applicativi.
Nel diagramma, una casella che rappresenta una sottoscrizione contiene tre caselle che rappresentano il gruppo di risorse 1, il gruppo di risorse 2 e il gruppo di risorse N. La casella gruppo di risorse 1 contiene i gateway applicazione per i tenant da 1 a 800. La casella del gruppo risorse 2 contiene i gateway applicativi per i tenant da 801 a 1600. Il gruppo di risorse N contiene i gateway applicativi per N tenant.
Distribuire i tenant tra gruppi di risorse e sottoscrizioni in modo ottimale
È anche possibile applicare il concetto di compressione bin tra risorse, gruppi di risorse e sottoscrizioni. Ad esempio, quando si dispone di alcuni tenant, potrebbe essere possibile distribuire una singola risorsa e condividerla tra tutti i tenant. Il diagramma seguente mostra la compressione del contenitore in una singola risorsa.
Nel diagramma, una casella che rappresenta la sottoscrizione A contiene un'altra casella che rappresenta il gruppo di risorse A1. Il gruppo di risorse A1 contiene la risorsa A1-1.
Man mano che si cresce, si potrebbe raggiungere il limite di capacità per una singola risorsa e quindi eseguire un'espansione su più risorse (R). Il diagramma seguente mostra il bin packing tra più risorse.
Nel diagramma, una casella che rappresenta la sottoscrizione A contiene un'altra casella che rappresenta il gruppo di risorse A1. Il gruppo di risorse A1 contiene le risorse da A1 a A1-R.
Se si raggiunge il limite del numero di risorse in un singolo gruppo di risorse, è possibile distribuire più risorse (R) in più gruppi di risorse (G). Il diagramma seguente mostra la compressione dei contenitori tra più risorse, in più gruppi di risorse.
Nel diagramma, una casella che rappresenta la sottoscrizione A contiene due caselle. Una casella rappresenta il gruppo di risorse A1 e l'altra rappresenta il gruppo di risorse AG. Il gruppo di risorse A1 contiene le risorse da A1 a A1-R. Il gruppo di risorse AG contiene risorse da AG-1 a AG-R.
Man mano che si aumenta ancora di più, è possibile distribuire le risorse tra più sottoscrizioni (S), ognuna contenente più gruppi di risorse (G) con più risorse (R). Il diagramma seguente illustra il bin packing tra più risorse, in più gruppi di risorse e sottoscrizioni.
Nel diagramma, una casella che rappresenta la sottoscrizione A contiene due caselle. Una casella rappresenta il gruppo di risorse A1 e l'altra rappresenta il gruppo di risorse AG. Il gruppo di risorse A1 contiene le risorse da A1 a A1-R. Il gruppo di risorse AG contiene risorse da AG-1 a AG-R. Un'altra casella che rappresenta la sottoscrizione S contiene due caselle. Una casella rappresenta il gruppo di risorse S1 e l'altra rappresenta il gruppo di risorse SG. Il gruppo di risorse S1 contiene le risorse da S1-1 a S1-R. Il gruppo di risorse SG contiene le risorse da SG-1 a SG-R.
Pianificando la tua strategia di scalabilità orizzontale, è possibile adattarsi a un numero elevato di tenant e sostenere un elevato livello di carico.
Etichette
I tag delle risorse consentono di aggiungere metadati personalizzati alle risorse di Azure. È possibile usare questi metadati per gestire le risorse e tenere traccia dei costi. Per altre informazioni, vedere Allocare i costi usando i tag delle risorse.
Stack di distribuzione
Gli stack di distribuzione consentono di raggruppare le risorse in base a una durata comune, anche se si estendono su più gruppi di risorse o sottoscrizioni. Gli stack di distribuzione sono utili quando si distribuiscono risorse specifiche del tenant, soprattutto se si ha un approccio di distribuzione che richiede di distribuire diversi tipi di risorse in posizioni diverse a causa di problemi di scalabilità o conformità. Gli stack di distribuzione consentono anche di rimuovere facilmente tutte le risorse correlate a un singolo tenant in un'unica operazione se si esegue l'offboarding di tale tenant. Per altre informazioni, vedere Creare e distribuire stack di distribuzione di Azure.
Schemi negativi da evitare
Mancata pianificazione della scalabilità. Assicurarsi di comprendere i limiti delle risorse distribuite. Conoscere i limiti che possono diventare importanti man mano che aumenta il carico o il numero di tenant. Pianifica come distribuire più risorse man mano che aumenti la capacità e testa quel piano.
Non prevede di bin pack. Anche se non hai bisogno di espanderti immediatamente, pianifica la scalabilità delle tue risorse Azure su più risorse, gruppi di risorse e sottoscrizioni nel tempo. Evitare di fare ipotesi nel codice dell'applicazione, ad esempio avere una singola risorsa quando potrebbe essere necessario ridimensionare più risorse in futuro.
Ridimensionamento di molte singole risorse. Se si dispone di una topologia di risorse complessa, può risultare difficile ridimensionare ogni componente singolarmente. Spesso è più semplice ridimensionare la soluzione come unità seguendo il modello Deployment Stamps.
Distribuzione di risorse isolate per ogni tenant quando non è necessario. In molte soluzioni è più conveniente ed efficiente distribuire risorse condivise per più tenant.
Non è possibile tenere traccia delle risorse specifiche del tenant. Quando si distribuiscono risorse specifiche del tenant, assicurarsi di comprendere quali risorse sono allocate a quali tenant. Queste informazioni sono importanti per scopi di conformità, per tenere traccia dei costi e per il deprovisioning delle risorse se si esegue l'offboarding di un tenant. Prendere in considerazione l'uso dei tag delle risorse per tenere traccia delle informazioni sul tenant e prendere in considerazione l'uso di stack di distribuzione per raggruppare le risorse specifiche del tenant in un'unità logica indipendentemente dal gruppo di risorse o dalla sottoscrizione in cui si trovano.
Uso di tenant Microsoft Entra separati. In linea generale, è sconsigliabile effettuare il provisioning di più tenant di Microsoft Entra. La gestione delle risorse nei tenant di Microsoft Entra è complessa. È più semplice ridimensionare le sottoscrizioni collegate a un singolo tenant di Microsoft Entra.
Progettare un'architettura eccessiva quando non serve scalare. In alcune soluzioni si sa con certezza che non si crescerà oltre un determinato livello di scalabilità. In questi scenari non è necessario creare logica di ridimensionamento complessa. Tuttavia, se l'organizzazione prevede di crescere, è necessario prepararsi a ridimensionare rapidamente.
Contributori
Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.
Autore principale:
- John Downs | Ingegnere software principale, Azure Patterns & Practices
Altri collaboratori:
- Jason Beck | Senior Customer Engineer, FastTrack di Azure
- Bohdan Cherchyk | Ingegnere Senior del Cliente, FastTrack for Azure
- Laura Nicolas | Senior Customer Engineer, FastTrack per Azure
- Arsen Vladimirskiy | Ingegnere principale per i clienti, FastTrack per Azure
- Joshua Waddell | Ingegnere Senior per i Clienti, FastTrack per Azure
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.