Condividi tramite

Considerazioni per l'aggiornamento di una soluzione multi-tenant

  • Articolo

Uno dei vantaggi della tecnologia cloud è il continuo miglioramento e l'evoluzione. In qualità di provider di servizi, è necessario applicare gli aggiornamenti alla soluzione: potrebbe essere necessario apportare modifiche al codice dell'applicazione, all'infrastruttura di Azure, agli schemi del database o a qualsiasi altro componente. È importante pianificare come aggiornare gli ambienti. In una soluzione multi-tenant, è particolarmente importante essere chiari sui criteri di aggiornamento perché alcuni tenant potrebbero essere riluttanti a consentire modifiche ai propri ambienti oppure potrebbero avere requisiti che limitano le condizioni in base alle quali è possibile aggiornare il servizio.

Quando si pianifica una strategia per aggiornare la soluzione, è necessario:

  • Identificare i requisiti dei tenant.
  • Chiarire i propri requisiti per gestire il servizio.
  • Trovare un equilibrio che sia l'utente che i tenant possono accettare.
  • Comunicare chiaramente la strategia ai tenant e ad altri stakeholder.

In questo articolo vengono fornite indicazioni per i decision maker tecnici sugli approcci che è possibile prendere in considerazione per aggiornare il software dei tenant e i compromessi coinvolti.

Requisiti dei clienti

I clienti spesso hanno requisiti espliciti o impliciti che possono influire sul modo in cui il sistema viene aggiornato. Considerare gli aspetti seguenti per creare un quadro di eventuali punti di preoccupazione che i clienti potrebbero generare:

  • Aspettative e requisiti: scoprire eventuali aspettative o requisiti che i clienti potrebbero avere su quando è possibile aggiornare la soluzione. Questi potrebbero essere comunicati formalmente all'utente in contratti o contratti di servizio, o potrebbero essere informali.
  • Finestre di manutenzione: comprendere se i clienti prevedono finestre di manutenzione definite dal servizio o persino autodefendite. Potrebbe essere necessario comunicare agli utenti su eventuali potenziali interruzioni oppure potrebbe essere necessario testare aspetti importanti del servizio dopo il completamento dell'aggiornamento.
  • Normative: chiarire se i clienti hanno problemi normativi che richiedono un'approvazione aggiuntiva prima che gli aggiornamenti possano essere applicati. Ad esempio, se si fornisce una soluzione sanitaria che include componenti IoT, potrebbe essere necessario ottenere l'approvazione dal Stati Uniti Food and Drug Administration (FDA) prima di applicare un aggiornamento.
  • Riservatezza: comprendere se uno dei clienti è particolarmente sensibile o resistente alla presenza di aggiornamenti applicati. In caso affermativo, cercare di capire perché. Ad esempio, se eseguono un negozio fisico o un sito Web di vendita al dettaglio, potrebbero voler evitare aggiornamenti intorno al Black Friday, perché i rischi sono superiori ai potenziali benefici.
  • Cronologia: esaminare il record di avanzamento del completamento degli aggiornamenti senza alcun impatto per i clienti. È consigliabile seguire buone procedure devOps, test, distribuzione e monitoraggio per ridurre la probabilità di interruzioni e assicurarsi di identificare rapidamente eventuali problemi introdotti dagli aggiornamenti. Se i clienti sanno che è possibile aggiornare gli ambienti senza problemi, è meno probabile che vengano oggetto.
  • Rollback: valutare se i clienti vogliono eseguire il rollback degli aggiornamenti in caso di modifica che causa un'interruzione e che attiverebbero una richiesta di rollback di questo tipo.

Requisiti

È anche necessario considerare le domande seguenti dal proprio punto di vista:

  • Controllare se si è disposti a fornire: è ragionevole che i clienti abbiano il controllo su quando vengono applicati gli aggiornamenti? Se si sta creando una soluzione usata dai clienti aziendali di grandi dimensioni, la risposta potrebbe essere sì. Tuttavia, se si sta creando una soluzione orientata al consumer, è improbabile che si dia un controllo sul modo in cui si aggiorna o si gestisce la soluzione.
  • Versioni: quante versioni della soluzione è possibile mantenere contemporaneamente? Tenere presente che se si trova un bug ed è necessario aggiornarlo, potrebbe essere necessario applicare l'hotfix a tutte le versioni in uso.
  • Conseguenze delle versioni precedenti: qual è l'impatto di consentire ai clienti di essere troppo indietro rispetto alla versione corrente? Se si rilasciano regolarmente nuove funzionalità, le versioni precedenti diventeranno obsolete rapidamente? Inoltre, a seconda della strategia di aggiornamento e dei tipi di modifiche, potrebbe essere necessario mantenere infrastrutture separate per ogni versione della soluzione. Pertanto, potrebbero esserci costi operativi e finanziari, in quanto si mantiene il supporto per le versioni precedenti.
  • Rollback: la strategia di distribuzione può supportare i rollback alle versioni precedenti? Si tratta di un elemento che si vuole abilitare?

Nota

Valutare se è necessario portare la soluzione offline per gli aggiornamenti o la manutenzione. In genere, le finestre di interruzione sono considerate una pratica obsoleta e le moderne procedure DevOps e le tecnologie cloud consentono di evitare tempi di inattività durante gli aggiornamenti e la manutenzione. Tuttavia, è necessario progettare per distribuzioni senza tempi di inattività, quindi è importante considerare il processo di aggiornamento quando si pianifica l'architettura della soluzione.

Anche se non si pianificano interruzioni durante il processo di aggiornamento, è comunque consigliabile definire una normale finestra di manutenzione. Una finestra può essere utile per comunicare ai clienti che le modifiche si verificano in momenti specifici.

Per altre informazioni su come ottenere distribuzioni senza tempi di inattività, vedere Eliminare i tempi di inattività tramite gli aggiornamenti del servizio con controllo delle versioni.

Trovare un saldo

Se si lascia la cadenza degli aggiornamenti del servizio interamente a discrezione dei tenant, potrebbe scegliere di non eseguire mai l'aggiornamento. È importante consentire a se stessi di aggiornare la soluzione, tenendo conto di eventuali problemi o vincoli ragionevoli che i clienti potrebbero avere. Ad esempio, se un cliente è particolarmente sensibile agli aggiornamenti di un venerdì perché è il giorno più affollato della settimana, è possibile rinviare facilmente gli aggiornamenti a lunedì, senza influire sulla soluzione?

Un approccio ottimale consiste nell'implementare gli aggiornamenti in base al tenant, usando uno degli approcci descritti di seguito. Notificare al cliente gli aggiornamenti pianificati. Consenti ai clienti di rifiutare temporaneamente il rifiuto esplicito, ma non per sempre; impostare un limite ragionevole su quando sarà necessario applicare l'aggiornamento.

Valutare anche la possibilità di distribuire patch di sicurezza o altri hotfix critici, con preavviso minimo o senza preavviso. Assicurarsi che i tenant comprendano questa procedura e la sua importanza nella salvaguardia dei dati.

Un altro approccio può essere quello di consentire ai tenant di avviare i propri aggiornamenti, al momento della propria scelta. Anche in questo caso, è necessario specificare una scadenza, a questo punto si applica l'aggiornamento per loro conto.

Avviso

Prestare attenzione all'abilitazione dei tenant per avviare i propri aggiornamenti. Questo è complesso da implementare e richiede un impegno significativo per lo sviluppo e il test per offrire e gestire.

Qualsiasi operazione eseguita, assicurarsi di disporre di un processo per monitorare l'integrità dei tenant, soprattutto prima e dopo l'applicazione degli aggiornamenti. Spesso, gli eventi imprevisti di produzione critici (detti anche eventi imprevisti del sito live) si verificano dopo gli aggiornamenti al codice o alla configurazione. È quindi importante monitorare in modo proattivo e rispondere a eventuali problemi per mantenere la fiducia dei clienti. Per altre informazioni sul monitoraggio, vedere Raccomandazioni per la progettazione e la creazione di un sistema di monitoraggio.

Comunicare con i clienti

La comunicazione chiara è fondamentale per costruire la fiducia dei clienti. È importante spiegare i vantaggi degli aggiornamenti regolari, tra cui nuove funzionalità, correzioni di bug, risoluzione delle vulnerabilità di sicurezza e miglioramenti delle prestazioni. Uno dei vantaggi di una soluzione moderna ospitata nel cloud è la distribuzione continua di funzionalità e aggiornamenti.

Prendere in considerazione le domande seguenti:

  • Si invierà una notifica ai clienti degli aggiornamenti futuri?
  • In caso affermativo, si richiederà in modo implicito l'autorizzazione fornendo un processo di rifiuto esplicito e quali sono i limiti alla rifiuto esplicito?
  • Si dispone di una finestra di manutenzione pianificata usata quando si applicano gli aggiornamenti?
  • Cosa accade se si dispone di un aggiornamento di emergenza, ad esempio una patch di sicurezza critica? È possibile forzare gli aggiornamenti in tali situazioni?
  • Se non è possibile inviare notifiche proattive ai clienti degli aggiornamenti futuri, è possibile fornire notifiche retrospettive? Ad esempio, è possibile aggiornare una pagina nel sito Web con l'elenco degli aggiornamenti applicati?
  • Quante versioni separate del sistema verranno mantenute nell'ambiente di produzione?

Comunicare con il team di supporto clienti

È importante che il proprio team di supporto abbia visibilità completa sugli aggiornamenti applicati all'infrastruttura di ogni tenant. I rappresentanti del supporto tecnico devono essere in grado di rispondere facilmente alle domande seguenti:

  • Gli aggiornamenti sono stati applicati di recente all'infrastruttura di un tenant o ai componenti condivisi?
  • Qual è la natura di questi aggiornamenti?
  • Qual era la versione precedente?
  • Con quale frequenza vengono applicati gli aggiornamenti a questo tenant?

Se uno dei clienti presenta un problema a causa di un aggiornamento, è necessario assicurarsi che il team di supporto clienti disponga delle informazioni necessarie per comprendere le modifiche apportate.

Strategie di distribuzione per supportare gli aggiornamenti

Valutare come distribuire gli aggiornamenti nell'infrastruttura. Questo è fortemente influenzato dal modello di tenancy usato. Tre approcci comuni per la distribuzione degli aggiornamenti sono indicatori di distribuzione, flag di funzionalità e anelli di distribuzione. È possibile usare questi approcci in modo indipendente oppure combinarli insieme per soddisfare requisiti più complessi.

In tutti i casi, assicurarsi di disporre di report e visibilità sufficienti, in modo da conoscere la versione dell'infrastruttura, del software o della funzionalità su cui si trova ogni tenant, su ciò che sono idonei per la migrazione e a tutti i dati correlati all'ora associati a tali stati.

Modello degli stamp di distribuzione

Molte applicazioni multi-tenant sono adatte al modello Deployment Stamps, in cui si distribuiscono più copie dell'applicazione e di altri componenti. A seconda dei requisiti di isolamento, è possibile distribuire un timbro per ogni tenant o indicatori condivisi che eseguono più carichi di lavoro dei tenant.

Gli stamp sono un ottimo modo per fornire l'isolamento tra i tenant. Offrono anche flessibilità per il processo di aggiornamento, perché è possibile implementare gli aggiornamenti progressivamente tra i timbri, senza influire sugli altri utenti.

Flag di funzionalità

I flag di funzionalità consentono di aggiungere funzionalità alla soluzione, esponendo tale funzionalità solo a un subset di clienti o tenant.

È consigliabile usare i flag di funzionalità se una di queste situazioni si applica:

  • Gli aggiornamenti vengono distribuiti regolarmente, ma si vuole evitare di visualizzare nuove funzionalità fino a quando non viene completamente implementato.
  • Si vuole evitare di applicare modifiche nel comportamento fino a quando un cliente non acconsente esplicitamente.

È possibile incorporare il supporto dei flag di funzionalità nell'applicazione scrivendo il codice manualmente o usando un servizio come app Azure Configurazione.

Anelli di distribuzione

Gli anelli di distribuzione consentono di implementare progressivamente gli aggiornamenti in un set di tenant o indicatori di distribuzione. È possibile assegnare un subset di tenant a ogni anello.

È possibile determinare il numero di anelli da creare e il significato di ogni anello per la propria soluzione. In genere, le organizzazioni usano gli anelli seguenti:

  • Canary: un anello canary include i propri tenant di test e i clienti che vogliono avere aggiornamenti non appena sono disponibili, con la consapevolezza che potrebbero ricevere aggiornamenti più frequenti e che gli aggiornamenti potrebbero non essere stati attraverso un processo di convalida completo come negli altri elementi.
  • Early adopter: un anello early adopter contiene tenant leggermente più rischiosi, ma che sono ancora pronti a ricevere aggiornamenti regolari.
  • Utenti: la maggior parte dei tenant appartiene all'anello degli utenti , che riceve aggiornamenti meno frequenti e più altamente testati.

Versioni dell'API

Se il servizio espone un'API esterna, tenere presente che gli aggiornamenti applicati potrebbero influire sul modo in cui i clienti o i partner si integrano con la piattaforma. In particolare, è necessario essere consapevoli delle modifiche di rilievo apportate alle API. Prendere in considerazione l'uso di una strategia di controllo delle versioni delle API per ridurre il rischio di aggiornamenti all'API.

Collaboratori

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

Autore principale:

Altri contributori:

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

Passaggio successivo

Prendere in considerazione quando si esegue il mapping delle richieste ai tenant in una soluzione multi-tenant.