Approcci architetturali per i piani di controllo nelle soluzioni multi-tenant

I piani di controllo sono una parte importante di soluzioni SaaS (Software as a Service) e multi-tenant, in particolare per gestire una soluzione su larga scala. In genere, esistono due componenti principali che costituiscono un piano di controllo:

• Il catalogo tenant, che archivia informazioni importanti sui tenant, ad esempio:
  • Configurazione del tenant.
  • SKU distribuiti per le risorse del tenant.
  • A quale distribuzione vengono allocati i tenant.
• Processi per la gestione delle modifiche all'ambiente, attivati dagli eventi del ciclo di vita del tenant. Ad esempio, l'onboarding dei tenant, l'offboarding del tenant e qualsiasi manutenzione regolare necessaria.

Un piano di controllo è un'applicazione. È necessario considerare attentamente il piano di controllo e progettarlo con lo stesso rigore e prestare attenzione all'uso con qualsiasi altra parte della soluzione. Per altre informazioni su che cos'è un piano di controllo, perché è consigliabile usarlo e considerazioni per la progettazione di un piano di controllo, vedere Considerazioni per i piani di controllo multi-tenant.

Questo articolo descrive alcuni approcci che è possibile prendere in considerazione per la progettazione e la creazione di un piano di controllo. L'elenco degli approcci descritti qui non è completo. Anche se gli approcci sono tutti validi, esistono altre architetture valide.

Approcci e modelli da prendere in considerazione

La tabella seguente riepiloga le differenze tra alcuni degli approcci che è possibile considerare per un piano di controllo. Vengono confrontati approcci manuali, con poco codice e personalizzati.

Processi manuali

Non è sempre essenziale creare un piano di controllo completamente automatizzato, soprattutto quando si inizia e si ha solo un numero ridotto di tenant.

È possibile mantenere il catalogo tenant in una posizione centralizzata, ad esempio in una cartella di lavoro di Excel o in un file JSON archiviato in una posizione a cui il team può accedere. Indipendentemente dal formato, è consigliabile archiviare le informazioni in modo strutturato in modo da poter usare facilmente i dati a livello di codice.

Per processi come l'onboarding dei tenant e le attività di manutenzione:

Il diagramma seguente illustra un modo per usare i processi manuali per un piano di controllo iniziale:

Scaricare un file di Visio di questa architettura.

Vantaggi di un approccio manuale

• Lightweight: la documentazione, gli script e le pipeline sono facili da sviluppare e modificare. Questo li rende appropriati quando si stanno cercando di capire i processi perché è possibile eseguire rapidamente l'iterazione e evolverli.
• Costo basso: la gestione e l'esecuzione di un approccio manuale è economica.
• Convalida il processo: anche se alla fine si intende usare un approccio più automatizzato, iniziare con un approccio manuale come modello di verifica è un buon modo per convalidare la strategia di manutenzione prima di investire tempo nello sviluppo di automazione più affidabile.

Svantaggi di un approccio manuale

• Mancanza di controllo: questo approccio si basa su tutti gli utenti coinvolti nel fare la cosa corretta. Qualcuno potrebbe deviare dai processi prescritti, accidentalmente o intenzionalmente. Ogni variazione del processo aumenta il rischio di incoerenza nell'ambiente, che rende la gestione continua molto più difficile.
• Problemi di controllo di accesso: quando si usa questo approccio, in genere è necessario concedere l'accesso altamente permissivo a chiunque gestisca la soluzione, in modo da rendere difficile seguire le procedure consigliate per la segmentazione di accesso.
• Scalabilità: il lavoro necessario per eseguire processi manuali viene ridimensionato con il numero di tenant che è necessario gestire.
• Verificabilità: i processi manuali sono difficili da convalidare e testare.

Quando prendere in considerazione la possibilità di allontanarsi da un approccio manuale

• Quando il team non è in grado di tenere il passo con la quantità di lavoro necessaria per gestire l'applicazione. Ad esempio, quando il numero di tenant supera un punto critico, che per la maggior parte dei team è compreso tra 5 e 10 tenant.
• Quando si prevede una crescita del tenant oltre un numero critico di tenant ed è necessario prepararsi per il lavoro coinvolto nell'amministrazione di tale numero di tenant.
• Quando è necessario attenuare il rischio di incoerenze. Ad esempio, potresti osservare alcuni errori che si verificano perché qualcuno non segue correttamente i processi o perché c'è troppa ambiguità nei processi. Il rischio di incoerenza aumenta in genere man mano che aumentano il numero di tenant di cui viene eseguito l'onboarding manualmente e man mano che il team cresce.

Piano di controllo a basso codice

Un piano di controllo con poco codice o senza codice si basa su una piattaforma progettata per automatizzare i processi aziendali e tenere traccia delle informazioni. Esistono molte piattaforme che consentono di eseguire queste attività senza scrivere codice personalizzato.

Microsoft Power Platform è un esempio di una di queste piattaforme. Se si usa Power Platform, è possibile mantenere il catalogo tenant in Dynamics 365, Dataverse o Microsoft 365. È anche possibile prendere in considerazione la conservazione dello stesso catalogo tenant usato per i processi manuali, se non si vuole eseguire il commit completo per automatizzare tutti gli elementi in un primo momento.

Per l'onboarding e la manutenzione dei tenant, è possibile usare Power Automate per eseguire flussi di lavoro che eseguono la gestione dei tenant, configurare tenant, attivare pipeline o chiamate API e così via. È possibile usare Power Automate per controllare le modifiche apportate al catalogo tenant, se i dati sono accessibili da qualche parte a Power Automate. Se si usa un catalogo tenant manuale, è anche possibile attivare manualmente i flussi di lavoro di Power Automate. È possibile decidere di includere passaggi di approvazione manuale nei flussi di lavoro se è necessario che qualcuno del team verifichi qualcosa o esegua passaggi aggiuntivi che non possono essere completamente automatizzati.

Questo approccio consente anche di fornire l'iscrizione self-service ai clienti consentendo all'applicazione Web di aggiungere direttamente i record al catalogo tenant senza intervento umano.

Il diagramma seguente illustra come creare un piano di controllo con iscrizione self-service usando Microsoft Power Platform:

Scaricare un file di Visio di questa architettura.

Vantaggi di un approccio a basso codice

• Leggero: spesso è veloce ed economico creare un set di flussi di lavoro con poco codice e connetterli ai sistemi circostanti.
• Usa gli strumenti della piattaforma: è possibile usare le funzionalità della piattaforma nativa per archiviare i dati, creare portali amministrativi per il team da usare e monitorare i flussi di lavoro durante l'esecuzione. Usando le funzionalità della piattaforma nativa, è possibile evitare di creare molti componenti manualmente.
• Personalizzabile: se è necessaria una maggiore personalizzazione, in genere è possibile aumentare i flussi di lavoro con codice e processi personalizzati. Ad esempio, è possibile usare Power Automate per attivare un flusso di lavoro di distribuzione in GitHub Actions oppure richiamare Funzioni di Azure per eseguire il proprio codice. Ciò consente anche di facilitare un'implementazione graduale.
• Sovraccarico ridotto: i servizi a basso codice sono in genere completamente gestiti, quindi non è necessario gestire l'infrastruttura.

Svantaggi di un approccio a basso codice

• Competenze necessarie: per usare piattaforme con poco codice per creare processi e usare in modo efficace queste piattaforme, in genere sono necessarie conoscenze proprietarie. Molte organizzazioni usano già questi strumenti, quindi il team potrebbe avere già le competenze necessarie, ma potrebbe non farlo. È consigliabile valutare se è necessario formare il team per poter usare in modo efficace queste piattaforme.
• Gestione: può essere difficile gestire la gestione di grandi quantità di configurazione a basso codice.
• Verificabilità: valutare come testare e alzare di livello le modifiche al piano di controllo. In una piattaforma gestita, la creazione di un processo DevOps tipico per il test e la promozione delle modifiche è più difficile, perché le modifiche vengono normalmente apportate tramite la configurazione, non tramite il codice.
• Progettazione: valutare attentamente come soddisfare i requisiti non funzionali, ad esempio sicurezza e affidabilità. Questi requisiti vengono spesso gestiti in una piattaforma a basso codice.

Quando prendere in considerazione l'allontanamento da un approccio a basso codice

• Alla fine, i requisiti potrebbero diventare così complessi che non è possibile incorporarli in modo sensibile in una soluzione a basso codice. Quando è necessario aggirare le limitazioni degli strumenti per soddisfare le proprie esigenze, probabilmente è opportuno allontanarsi da una soluzione gestita e verso un piano di controllo personalizzato.

Piano di controllo personalizzato

È anche possibile creare un piano di controllo completamente personalizzato. Questa opzione offre la massima flessibilità e potenza, ma richiede anche la maggior parte del lavoro. Il catalogo tenant viene in genere archiviato in un database. In questo caso non si lavora direttamente con il catalogo, ma lo si gestisce tramite un'interfaccia amministrativa, che potrebbe essere un'applicazione personalizzata o un sistema come l'applicazione CRM (Customer Relationship Management) dell'organizzazione.

In genere si crea un set di componenti del piano di controllo progettati per tutte le funzioni amministrative del tenant. Questi componenti possono includere un portale amministrativo o un'altra interfaccia utente, un'API e componenti di elaborazione in background. Se è necessario eseguire operazioni come distribuire codice o infrastruttura quando si verificano eventi del ciclo di vita del tenant, le pipeline di distribuzione possono anche creare il piano di controllo.

Assicurarsi che qualsiasi elaborazione a esecuzione prolungata usi strumenti appropriati. Ad esempio, è possibile usare Durable Functions o App per la logica di Azure per i componenti che orchestrano l'onboarding o le distribuzioni dei tenant o per i componenti che devono comunicare con sistemi esterni.

Analogamente all'approccio a basso codice, questo approccio consente di fornire l'iscrizione self-service ai clienti consentendo all'applicazione Web di aggiungere direttamente i record al catalogo tenant senza intervento umano.

Il diagramma seguente illustra un modo per creare un piano di controllo personalizzato di base che fornisce l'iscrizione self-service:

Scaricare un file di Visio di questa architettura.

Vantaggi di un approccio personalizzato

• Flessibilità e personalizzazione complete: è possibile controllare il funzionamento del piano di controllo e modificarlo se i requisiti cambiano.
• Verificabilità: è possibile usare un ciclo di vita di sviluppo software standard (SDLC) per l'applicazione del piano di controllo e implementare approcci normali per test e distribuzioni, proprio come per le applicazioni principali.

Svantaggi di un approccio personalizzato

• Responsabilità di manutenzione: questo approccio richiede un sovraccarico di manutenzione maggiore perché è necessario creare tutto manualmente. Un piano di controllo è importante come qualsiasi altra parte dell'applicazione. È necessario prestare molta attenzione allo sviluppo, ai test e al funzionamento del piano di controllo per garantire che sia affidabile e sicuro.

Approcci ibridi

È anche possibile prendere in considerazione l'uso di un approccio ibrido. È possibile usare una combinazione di sistemi manuali e automatizzati oppure è possibile usare una piattaforma gestita come Microsoft Power Platform e aumentarla con applicazioni personalizzate. Valutare la possibilità di implementare un approccio ibrido se è necessaria la personalizzazione di un piano di controllo personalizzato, ma non si vuole necessariamente compilare e gestire un sistema completamente personalizzato. Tenere presente che, a un certo punto, le personalizzazioni automatizzate per i processi manuali o la piattaforma gestita potrebbero diventare complesse come un sistema completamente personalizzato. Il punto di puntamento è diverso per ogni organizzazione, ma se l'approccio ibrido è complesso da gestire, è consigliabile passare a un sistema completamente personalizzato.

Implementazione graduale

Anche se si sa che alla fine si vuole automatizzare il piano di controllo, non è necessario iniziare necessariamente con questo approccio. Un approccio comune durante le fasi iniziali della creazione dell'applicazione consiste nell'iniziare con un piano di controllo manuale. Man mano che l'applicazione procede e esegue l'onboarding di più tenant, è necessario iniziare a identificare le aree di collo di bottiglia e automatizzarle in base alle esigenze, passando a un approccio ibrido. Man mano che si automatizzano di più, alla fine si potrebbe avere un piano di controllo completamente automatizzato.

Antipattern da evitare

• Basarsi su processi manuali per troppo tempo. Anche se è ragionevole usare processi manuali all'avvio o quando si ha un numero ridotto di tenant e si richiede una gestione piuttosto leggera, è necessario pianificare la scalabilità in una soluzione automatizzata man mano che si aumenta. Se è necessario assumere altri membri del team per tenere il passo con la richiesta dei processi manuali, è un buon segno che è consigliabile iniziare ad automatizzare parti del piano di controllo.
• Uso di strumenti inappropriati per i flussi di lavoro a esecuzione prolungata. Ad esempio, evitare di usare funzioni di Azure standard, chiamate API sincrone o altri strumenti con un limite di tempo di esecuzione per eseguire operazioni a esecuzione prolungata, ad esempio distribuzioni di Azure Resource Manager o orchestrazioni in più passaggi. Usare invece strumenti come App per la logica di Azure, Durable Functions e altri strumenti che possono eseguire flussi di lavoro o sequenze di operazioni a esecuzione prolungata. Per altre informazioni, vedere Funzioni di Azure modello di prestazioni e affidabilità e Asincrona Request-Reply.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

• John Downs | Principal Software Engineer
• Landon Pierce | Customer Engineer

Altri contributori:

• Mick Alberts | Writer tecnico
• Bohdan Cherchyk | Senior Customer Engineer
• Arsen Vladimirintune | Principal Customer Engineer

Passaggi successivi

• Microsoft Power Platform
• Power Automate

Risorse correlate

• Considerazioni sull'architettura per i piani di controllo in una soluzione multi-tenant
• Approcci architetturali per una soluzione multi-tenant