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.
  • Trova un equilibrio che sia tu che i tuoi inquilini possiate 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: Capire se i clienti prevedono finestre di manutenzione definite dal servizio o persino autodefinite. 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 di poter applicare gli aggiornamenti. Ad esempio, se si fornisce una soluzione sanitaria che include componenti IoT, potrebbe essere necessario ottenere l'approvazione dagli Stati Uniti Food and Drug Administration (FDA) prima di applicare un aggiornamento.
  • Sensibilità: 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.
  • Storia: Esamina il tuo storico di successo nel completamento degli aggiornamenti senza alcun impatto sui tuoi 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 tuoi clienti sanno che sei in grado di aggiornare i loro ambienti senza problemi, è meno probabile che si oppongano.
  • Rollback: Valutare se i clienti vogliono eseguire il rollback degli aggiornamenti in caso di un cambiamento che causa un malfunzionamento e chi attiverà una richiesta di rollback di questo tipo.

Requisiti

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

  • Controllo che sei disposto 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 possono essere ragionevolmente mantenute 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 tua strategia di distribuzione può supportare il rollback alle versioni precedenti? Si tratta di un elemento che si vuole abilitare?

Annotazioni

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 ulteriori informazioni su come ottenere distribuzioni senza interruzioni, vedere Eliminare le interruzioni tramite aggiornamenti del servizio con versioni controllate.

Trovare un saldo

Se si lascia la cadenza degli aggiornamenti del servizio interamente a discrezione degli inquilini, potrebbero scegliere di non aggiornare mai. È 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.

Avvertimento

Prestare attenzione nell'abilitare i tenant per avviare i propri aggiornamenti. Questo è complesso da implementare e richiede un impegno significativo per lo sviluppo e il test per consegnare e mantenerlo.

Qualsiasi cosa tu faccia, assicurati 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.

Considerare le domande seguenti:

  • Si invierà una notifica ai clienti degli aggiornamenti futuri?
  • Se lo fai, richiederai implicitamente l'autorizzazione fornendo un processo di opt-out, e quali sono i limiti all'opt-out?
  • 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 rapporti e visibilità sufficienti, in modo da conoscere la versione dell'infrastruttura, del software o delle funzionalità su cui si trova ogni tenant, a cosa sono idonei per la migrazione e qualsiasi dato temporale associato a tali stati.

Modello di Distribuzione a Timbri

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'istanza per ogni tenant o istanze condivise che eseguono i carichi di lavoro di più tenanti.

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

Indicatori 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 manualmente il codice o usando un servizio come Configurazione app di Azure.

Anelli di distribuzione

Gli anelli di distribuzione consentono di distribuire progressivamente gli aggiornamenti in un set di tenant o timbrature di distribuzione. È possibile assegnare un sottoinsieme di inquilini 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:

  • Canarino: Un anello canarino include i propri tenant di test e i clienti che vogliono ricevere aggiornamenti non appena sono disponibili, con la consapevolezza che potrebbero ricevere aggiornamenti più frequenti e che gli aggiornamenti potrebbero non essere stati sottoposti a un processo di convalida completo come negli altri.
  • Early adopter: Un anello di utilizzatori precoci (early adopter) include tenanti leggermente più avversi al rischio, ma che sono ancora pronti a ricevere aggiornamenti regolari.
  • Utenti: La maggior parte dei locatari appartiene all'anello degli utenti, che riceve aggiornamenti meno frequenti e meglio 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 dei cambiamenti sostanziali alle tue API. Prendere in considerazione l'uso di una strategia di controllo delle versioni delle API per ridurre il rischio di aggiornamenti all'API.

Contributori

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

Autore principale:

Altri collaboratori:

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

Passaggio successivo

Considera quando eseguire la mappatura delle richieste ai tenant in una soluzione multiutenza.