Metodologia di progettazione per carichi di lavoro SaaS in Azure
I fornitori di software indipendenti (ISV) devono pianificare attentamente i requisiti della soluzione SaaS (Software as a Service), dato che la soluzione è la propria azienda. I clienti aziendali, ad esempio altre aziende o singoli consumatori, sono gli utenti diretti della soluzione. Questo modello di business imposta aspettative elevate perché è necessario considerare sia i requisiti del carico di lavoro che le esigenze dei clienti come architetto della progettazione.
Questo articolo descrive una metodologia di progettazione che è possibile usare per definire e perfezionare sistematicamente i requisiti. In caso di dubbi sulle varie opzioni di progettazione e tecnologia, rivedere questa metodologia per rimanere allineata ai requisiti aziendali. La creazione di un carico di lavoro SaaS è un processo iterativo che richiede flessibilità per adattarsi ai mercati in evoluzione e alle esigenze dei clienti. Questo framework consente di collaborare con i team di marketing e di vendita per convalidare le decisioni tecniche e valutare il feedback dei clienti per un miglioramento continuo.
Progettare per il modello aziendale
È importante comprendere in che modo i requisiti aziendali influiscono sulla soluzione downstream. Prendere in considerazione i punti decisionali seguenti:
Il percorso in cui si distribuiscono le risorse limita i modelli di architettura che è possibile usare. È possibile distribuire tutte le risorse nelle sottoscrizioni di Azure oppure i clienti possono acquistare la soluzione e distribuirla nelle proprie sottoscrizioni di Azure. In alternativa, il carico di lavoro può usare le risorse distribuite dal cliente nelle sottoscrizioni di Azure.
Ad esempio, se si distribuisce il software nell'ambiente del cliente, non è possibile usare un modello di architettura basato solo sulle risorse condivise perché ogni cliente ha un proprio ambiente autonomo con risorse dedicate.
Per altre informazioni, vedere Modelli di distribuzione ISV.
Il modello di determinazione dei prezzi determina i ricavi dell'azienda, che a sua volta influisce sul costo consentito delle merci vendute. Questa dinamica influisce direttamente sull'architettura tecnica.
Per altre informazioni, vedere Modello tariffario.
Le funzionalità o i prodotti forniti possono influire sull'architettura. Potrebbe essere necessario apportare modifiche o aggiunte all'architettura tecnica quando si scelgono funzionalità specifiche. Fornire prodotti diversi a vari clienti può anche portare a un'architettura più complessa perché deve supportare queste varianti.
Progettare per i requisiti dei clienti
Progettare la soluzione tenendo presenti i requisiti dei clienti. I clienti potrebbero avere requisiti aggiuntivi per la soluzione, che crea un superset che la soluzione deve soddisfare. Questi requisiti aggiuntivi possono talvolta entrare in conflitto con le esigenze aziendali o con le esigenze di altri clienti. Quando questi requisiti differiscono dalle esigenze aziendali o aggiungono altre restrizioni, le decisioni per la soluzione possono essere difficili. Ad esempio, la soluzione potrebbe soddisfare gli standard di sicurezza, ma un cliente potrebbe avere requisiti di sicurezza più rigorosi che è necessario soddisfare per proteggere l'azienda.
Creare un'architettura flessibile per soddisfare questi requisiti aggiuntivi. Se i requisiti dei clienti non influiscono sui propri requisiti, provare a integrarli nel modello aziendale. Calcolare il costo di queste rettifiche. Se i requisiti univoci di un cliente comportano costi aggiuntivi, valutare la possibilità di caricarli di conseguenza.
Assicurarsi di avere obiettivi di affidabilità realistici che soddisfino le aspettative dei clienti e progettare l'architettura per raggiungerli.
Progettare il modello di tenancy
La maggior parte delle soluzioni SaaS si basa sulla multi-tenancy come strategia tecnica principale per ottimizzare l'efficienza dei costi. La multi-tenancy prevede una gamma di scelte che non hanno modelli standard. Il modello di tenancy influisce sugli aspetti dell'architettura, tra cui overhead di gestione, costi e isolamento dei dati. Trovare il giusto equilibrio per la soluzione. Il modello di tenancy scelto è fondamentale perché deve bilanciare le esigenze aziendali e dei clienti.
Per aiutarti a prendere decisioni informate, fai riferimento a questi articoli:
L'architettura deve avere la flessibilità necessaria per modificare il modello di tenancy in base ai requisiti dei clienti nuovi o in ingresso. Ad esempio, è possibile usare un'architettura completamente multi-tenant, ma ottenere un nuovo cliente in un settore altamente regolamentato che necessita di maggiore sicurezza. È possibile partizionare verticalmente la distribuzione per fornire un timbro dedicato. Questa modifica genera una decisione aziendale sul fatto che debbano pagare più di altri tenant. Questa configurazione aumenta i costi delle risorse e la complessità, quindi è opportuno pagare di più.
Progettare per essere ben progettato
Quando si progetta un carico di lavoro SaaS, è necessario prestare particolare attenzione per garantire che il sistema sia resiliente, sicuro, efficiente, efficiente e bilancia i requisiti dei clienti. A differenza delle applicazioni aziendali, gli errori in un'applicazione SaaS possono influire anche sull'azienda, sui clienti e sui relativi utenti.
Per ogni decisione, valutare i compromessi tra i pilastri di Azure Well-Architected Framework. Per informazioni sugli approcci strategici per ogni pilastro, vedere Principi di progettazione.
Progettare per le operazioni
Le operazioni del carico di lavoro SaaS richiedono una prospettiva diversa. È necessario considerare fattori come la supportabilità. Determinare come fornire supporto alla piattaforma di tutti i giorni e assumere persone con il set di competenze corretto. Non considerare le operazioni come un afterthought o concentrarsi solo sulla creazione di nuove funzionalità. Includere l'operabilità nella progettazione fin dall'inizio. Valutare la scalabilità dei processi man mano che si ottengono più clienti. Ad esempio, le operazioni manuali potrebbero funzionare inizialmente, ma in genere non funzionano correttamente nel tempo.
Se si ha una piattaforma legacy, valutare come o se è necessario spostare i clienti nella nuova piattaforma SaaS. Un percorso di migrazione uniforme è fondamentale per mantenere soddisfatti i clienti durante la trasformazione aziendale.