Procedure DevOps per carichi di lavoro SaaS in Azure
Le procedure DevOps sono integrali per la gestione dei carichi di lavoro in Azure, soprattutto per le applicazioni SaaS. Gli aspetti principali includono l'onboarding, l'offboarding e la modifica delle istanze dei clienti. Queste procedure non solo semplificano le operazioni, ma migliorano anche la scalabilità e l'affidabilità, riducendo al minimo le probabilità di interruzioni.
Questo articolo descrive le considerazioni di progettazione per una gestione efficiente del ciclo di vita dei clienti e procedure di distribuzione sicure.
Gestire i cicli di vita dei clienti
La gestione degli eventi del ciclo di vita dei clienti è fondamentale per qualsiasi applicazione SaaS. In genere, questi eventi includono:
- Onboarding: quando un cliente si iscrive.
- Modifica: modifica dell'istanza di un cliente, ad esempio la modifica del piano tariffario.
- Offboarding: quando un cliente annulla il proprio account.
Potrebbero verificarsi eventi aggiuntivi del ciclo di vita. Ad esempio, è possibile consentire ai clienti di sospendere la sottoscrizione mantenendo i dati per un periodo impostato e riprendere la sottoscrizione in un secondo momento. Ogni evento può avere implicazioni univoce per l'applicazione.
In alcune soluzioni, la gestione del ciclo di vita dei clienti potrebbe richiedere solo la creazione o la gestione dei dati in una tabella di database. Per altre soluzioni, potrebbe comportare l'orchestrazione della distribuzione dell'infrastruttura di Azure, del codice dell'applicazione e di una configurazione più complessa.
La gestione del ciclo di vita è una responsabilità fondamentale del piano di controllo di una soluzione SaaS. Inizialmente, il team potrebbe gestire queste attività manualmente, ma nel corso del tempo, provare a eseguire la transizione di più funzionalità in una soluzione o un'applicazione del piano di controllo formalizzato.
Considerazioni relative alla progettazione
Coerenza. Quando si pianifica la strategia di gestione del ciclo di vita, prendere in considerazione la complessità delle azioni necessarie per ogni evento del ciclo di vita del cliente. Sono incluse le dimensioni della soluzione, della base clienti e del sovraccarico dell'organizzazione. Assicurarsi di avere una chiara comprensione dei passaggi necessari per ogni evento e investire nei controlli per mantenere la coerenza. Esaminare e aggiornare regolarmente i processi per assicurarsi che rimangano validi man mano che la soluzione si evolve.
Modello tenancy. L'approccio alla gestione degli eventi del ciclo di vita dei clienti dipende dal modello di tenancy.
- Soluzioni completamente multi-tenant con risorse di infrastruttura. L'onboarding o l'offboarding di un cliente comporta in genere l'aggiornamento di un elenco di clienti e i dati associati nell'archivio dati dell'applicazione.
- Risorse dedicate per cliente. Le attività in genere comportano l'avvio delle distribuzioni in Azure, il monitoraggio dello stato di avanzamento e la gestione degli errori di distribuzione, possibilmente con l'intervento umano.
- Risorse distribuite dal cliente. Potrebbe essere necessario interfacciarsi direttamente con il team di progettazione del cliente per l'onboarding o l'offboarding.
Livelli. Prendere in considerazione il modello di determinazione dei prezzi e le diverse esigenze di infrastruttura di ogni livello, soprattutto se si consente ai clienti di modificare liberamente lo SKU in qualsiasi momento.
- Ad esempio, se la soluzione SaaS include un'applicazione principale e più moduli aggiuntivi a pagamento, assicurarsi che le risorse dell'app principale vengano distribuite durante l'onboarding. Inoltre, consentire l'aggiunta dinamica e la rimozione di moduli aggiuntivi. Quando un modulo viene rimosso, decidere se eliminare i dati associati o archiviarli per la potenziale riattivazione.
Suggerimenti per la progettazione
| Elemento consigliato | Vantaggio |
|---|---|
| Documentare ogni tipo di evento del ciclo di vita del cliente. Assicurarsi di acquisire i dettagli dettagliato del processo per ogni evento. |
Comprendendo gli eventi, è possibile pianificare come rispondere a ogni evento nella progettazione della soluzione. Istruzioni chiare consentono agli operatori umani di mantenere la coerenza e fungere da base per l'automazione futura. |
| Comunicare la responsabilità condivisa tra l'utente e il cliente per ogni evento del ciclo di vita. Comunicare chiaramente e presto le azioni che si prevede che i clienti eseseguono per completare una fase del ciclo di vita. | È possibile ridurre potenziali errori e frustrazione dei clienti causati da errori di comunicazione errata. |
| Eseguire la pianificazione della capacità per ogni evento del ciclo di vita. Ad esempio, quando si esegue l'onboarding di un nuovo cliente, pianificare la distribuzione di una nuova istanza dell'applicazione se le istanze esistenti non dispongono di capacità sufficiente per gestire il carico aggiuntivo. Per altre informazioni, vedere Fatturazione e gestione dei costi per i carichi di lavoro SaaS in Azure. |
È possibile supportare la scalabilità più semplice ed evitare errori di distribuzione. |
| Automatizzare gli eventi del ciclo di vita, quando pratici. Per soluzioni a basso volume o in fase iniziale, la distribuzione manuale e la configurazione potrebbero essere sufficienti, ma devono comunque usare script, anche se un tecnico li esegue ogni volta che si verifica un evento del ciclo di vita. Man mano che la soluzione matura, integrare queste responsabilità in un piano di controllo completo per ridurre l'errore umano e supportare una scalabilità superiore. |
È possibile ridurre il rischio significativo di errori umani e supportare una scala più elevata. |
Pianificare la strategia di gestione dell'infrastruttura
Sviluppare una strategia per la distribuzione, la gestione e la gestione dell'infrastruttura di Azure all'inizio. Quando si ridimensiona il modello SaaS, aumenta il numero di risorse. È più facile seguire una strategia di gestione fin dall'inizio piuttosto che riconciliare l'infrastruttura in un secondo momento quando diventa troppo complessa da gestire manualmente.
Considerazioni relative alla progettazione
Gestione delle risorse dei clienti. Il modello di tenancy influisce sulla distribuzione delle risorse nelle soluzioni SaaS. È possibile distribuire risorse di Azure dedicate per ogni cliente o condividere risorse tra un determinato numero di clienti. In alternativa, è possibile usare un singolo set di risorse condivise, riconfigurandole durante l'onboarding di nuovi clienti. Approcci comuni per la gestione del ciclo di vita delle risorse:
- Considerare l'elenco dei clienti come una configurazione delle risorse da distribuire. Usare pipeline di distribuzione centralizzate per distribuire e configurare tali risorse.
- Considera l'elenco dei clienti come dati. Usare un'applicazione del piano di controllo per effettuare il provisioning e configurare l'infrastruttura.
Automazione dell'infrastruttura. Molte organizzazioni iniziano distribuendo manualmente l'infrastruttura cloud tramite il portale di Azure, che inizialmente è facile ma non è scalabile correttamente. Pianificare l'automazione della configurazione dell'infrastruttura usando strumenti IaC (Infrastructure as Code) come Bicep o Terraform. Per requisiti più complessi, creare un piano di controllo che usi direttamente le API di Azure Resource Manager.
Attribuzione dell'infrastruttura. Tenere traccia dei clienti distribuiti in quale infrastruttura. Il rilevamento è importante per la pianificazione accurata della capacità e l'attribuzione dei costi. È possibile tenere traccia dell'infrastruttura dei clienti centralmente in un database del cliente o, per un'infrastruttura dedicata, usare i metadati delle risorse di Azure con gruppi di risorse e tag di risorse specifici del cliente. Per altre informazioni, vedere Organizzazione delle risorse per carichi di lavoro SaaS.
Suggerimenti per la progettazione
| Elemento consigliato | Vantaggio |
|---|---|
| Creare l'automazione dell'infrastruttura usando pipeline di distribuzione, script o modelli con gli strumenti con cui il team ha già familiarità. | L'uso di strumenti noti riduce il rischio di errori, perché l'automazione dell'infrastruttura può comportare interruzioni se gli strumenti non sono compresi. |
| Distribuire l'infrastruttura usando IaC, dove possibile. | La gestione manuale dell'infrastruttura diventa più rischiosa e più onerosa man mano che aumenta la quantità di infrastruttura. |
| Separare l'infrastruttura principale dall'infrastruttura a livello di cliente. | Diversi tipi di infrastruttura hanno cicli di vita e attività di gestione distinti. Separandoli, è possibile gestire ogni set in modo indipendente in base alla propria pianificazione. |
| Usare applicazioni gestite di Azure per distribuire e gestire le risorse distribuite dal cliente. | Le applicazioni gestite di Azure offrono una gamma di funzionalità che consentono di distribuire e gestire le risorse all'interno della sottoscrizione di Azure di un cliente. |
Pianificare le distribuzioni di applicazioni
Aggiornare regolarmente il codice e la configurazione dell'applicazione per migliorare le funzionalità. I clienti si aspettano tempi di attività coerenti durante gli aggiornamenti e implementazioni sicure per ridurre al minimo il rischio di interruzioni.
Considerazioni relative alla progettazione
Standardizzare gli strumenti e i processi. Gli strumenti DevOps collaudati nel settore garantiscono coerenza tra funzioni e maturità nei processi per la gestione delle distribuzioni delle applicazioni. Lo sviluppo di strumenti personalizzati è considerato un antipattern nella maggior parte delle situazioni.
Fare riferimento alle procedure di sviluppo software di OE:03.
Compromesso: complessità e costi. L'uso di strumenti DevOps familiari può essere conveniente in termini di denaro e competenze. Tuttavia, aggiunge il carico operativo di gestione di ogni strumento separatamente. È importante rimanere aperti alle nuove innovazioni tecnologiche che potrebbero trarre vantaggio dal carico di lavoro.Distribuire progressivamente gli aggiornamenti. Implementare gli aggiornamenti a un subset di clienti alla volta, dividendo gli utenti in raggruppamenti logici. Applicare lo stesso rigore alle modifiche alla configurazione, perché possono modificare il comportamento del codice e causare interruzioni. Seguire un processo di distribuzione per queste modifiche.
Adottare una strategia di controllo delle versioni. Consentire ai clienti di scegliere la versione dell'applicazione aggiunge flessibilità, ma complica le operazioni. Impostare aspettative chiare per deprecare le versioni precedenti e delineare cosa accade quando non sono più supportate.
Automazione. Le distribuzioni manuali sono soggette a rischi dovuti a errori umani e mancanza di coerenza. Anche se le distribuzioni vengono attivate manualmente, il processo di distribuzione deve essere automatizzato il più possibile e deve richiedere un intervento umano minimo. Prendere in considerazione i passaggi del processo di distribuzione e come automatizzarli al meglio.
Test. Integrare i test nel processo di distribuzione eseguendo:
- Unit test durante la compilazione del codice
- Test di integrazione post-distribuzione
- Test regolari delle prestazioni
- Test regolari di sicurezza e penetrazione
Decidere le azioni da eseguire se i test hanno esito negativo in qualsiasi fase.
Distribuzioni non riuscite. Pianificare gli errori di distribuzione considerando le azioni necessarie e preparando una strategia di rollback.
Accesso agli ambienti dei clienti. Se si distribuiscono le risorse negli ambienti dei clienti, comprendere come applicare gli aggiornamenti all'interno di tali ambienti. Prendere in considerazione le funzionalità offerte dalle applicazioni gestite di Azure, ad esempio la distribuzione di aggiornamenti alle applicazioni.
Suggerimenti per la progettazione
| Elemento consigliato | Vantaggio |
|---|---|
| Usare strumenti e processi DevOps consolidati e collaudati del settore per gestire le distribuzioni delle applicazioni. Lo sviluppo di strumenti personalizzati è considerato un antipattern nella maggior parte delle situazioni. Per altre informazioni, vedere Procedure di sviluppo software OE:03 |
È possibile assicurarsi che il team di progettazione venga distribuito in modo efficace senza dover apprendere strumenti creati personalizzati. |
| Notificare in modo proattivo ai clienti eventuali distribuzioni imminenti o completate. | È possibile assicurarsi che le aspettative appropriate siano impostate con i clienti in merito alle modifiche in arrivo nell'applicazione. |
| Adottare procedure di distribuzione sicure che distribuiscono gli aggiornamenti ai gruppi di clienti usando strategie come l'esposizione progressiva, i modelli di integrità e altri. Iniziare con clienti meno sensibili o early adopter prima di passare a quelli più importanti. Per altre informazioni, vedere Raccomandazioni per procedure di distribuzione sicure. |
Questo approccio consente di identificare i problemi prima che influiscano su tutti i clienti. |
| Gestire la configurazione come codice. | È possibile ridurre la probabilità di tempi di inattività e adottare un processo coerente per le modifiche di produzione. Ciò consente responsabilità operative centralizzate, ad esempio il test delle modifiche e l'implementazione progressiva degli aggiornamenti alla configurazione e al codice. |
| Definire un processo di gestione delle modifiche e comunicare i criteri di aggiornamento della versione per assicurarsi che i clienti sappiano chi attiva gli aggiornamenti, la frequenza e le condizioni. Se i clienti possono scegliere la versione dell'applicazione, impostare linee guida chiare per deprecare le versioni precedenti. Ridurre al minimo il numero di versioni dell'applicazione in esecuzione nell'ambiente di produzione. |
La gestione delle versioni precedenti causa un'inefficienza operativa. Fornire il controllo necessario per i clienti evitando di sovraccaricare il team impostando aspettative e criteri chiari. |
| Evitare di personalizzare le applicazioni per un singolo cliente. Per supportare diverse esigenze dei clienti, è possibile creare vari livelli della soluzione o usare flag di funzionalità per abilitare funzionalità specifiche per determinati utenti. |
Evitare ambiguità sulle funzionalità distribuite in quale versione e ridurre il carico di manutenzione. |
| Disporre di un piano di rollback per le distribuzioni non riuscite, inclusi i criteri per l'attivazione e le approvazioni necessarie. | I piani di rollback consentono di assicurarsi di poter eseguire il ripristino da errori di distribuzione anche in circostanze impreviste. |
| Testare l'applicazione regolarmente e in più fasi del processo di sviluppo software. Adottare una mentalità "shift-left" e intercettare bug e deviazioni all'inizio del ciclo di vita. | Evitare che gli errori critici influiscano sui clienti. |
Risorse aggiuntive
La multi-tenancy è una metodologia aziendale di base per la progettazione di carichi di lavoro SaaS. Questi articoli forniscono altre informazioni sull'adozione di procedure DevOps:
- Approcci architetturali per la distribuzione e la configurazione di soluzioni multi-tenant
- Considerazioni per l'aggiornamento di una soluzione multi-tenant
- Considerazioni per i piani di controllo multi-tenant
- Approcci architetturali per i piani di controllo nelle soluzioni multi-tenant
Passaggio successivo
Informazioni sulle considerazioni sulla gestione degli eventi imprevisti per l'implementazione di processi e strumenti che supportano una soluzione SaaS in Azure.