Piano di controllo vs. piano di applicazione - Nozioni di base sull'architettura SaaS

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Piano di controllo vs. piano di applicazione

Il diagramma precedente fornisce una visione concettuale dei concetti fondamentali dell'architettura SaaS. Ora approfondiamo questo aspetto e definiamo meglio come il tuo ambiente SaaS si è scomposto in livelli distinti. Avere questo quadro più chiaro dei confini tra i concetti SaaS renderà più facile descrivere le parti mobili di una soluzione SaaS.

Il diagramma seguente divide l'ambiente SaaS in due piani distinti. Sul lato destro sul lato destro al piano di controllo. Questa parte del diagramma include tutte le funzionalità e i servizi utilizzati per integrare, autenticare, gestire, utilizzare e analizzare un ambiente multi-tenant.

Un diagramma che rappresenta il piano di controllo rispetto al piano di applicazione.

Piano di controllo vs. piano di applicazione

Questo piano di controllo è fondamentale per qualsiasi modello SaaS multi-tenant. Ogni soluzione SaaS, indipendentemente dalla distribuzione delle applicazioni e dallo schema di isolamento, deve includere quei servizi che consentono di gestire e gestire i tenant attraverso un'unica esperienza unificata.

All'interno del piano di controllo, lo abbiamo ulteriormente suddiviso in due elementi distinti. I servizi principali qui rappresentano la raccolta di servizi utilizzati per orchestrare la tua esperienza multi-tenant. Abbiamo incluso alcuni degli esempi più comuni di servizi che in genere fanno parte del core, riconoscendo che i servizi di base potrebbero variare in base a ciascuna soluzione SaaS.

Noterai anche che mostriamo un'applicazione di amministrazione separata. Rappresenta l'applicazione (un'applicazione Web, un'interfaccia a riga di comando o un'API) che potrebbe essere utilizzata da un provider SaaS per gestire il proprio ambiente multi-tenant.

Un'avvertenza importante è che il piano di controllo e i suoi servizi non sono effettivamente multi-tenant. La funzionalità non fornisce gli attributi funzionali effettivi dell'applicazione SaaS (che deve essere multi-tenant). Se esamini uno qualsiasi dei servizi principali, ad esempio, non troverai l'isolamento dei tenant e gli altri costrutti che fanno parte delle funzionalità delle tue applicazioni multi-tenant. Questi servizi sono globali per tutti gli inquilini.

Il lato sinistro del diagramma fa riferimento al piano di applicazione di un ambiente SaaS. È qui che risiede la funzionalità multi-tenant della tua applicazione. Ciò che appare nel diagramma deve rimanere alquanto vago, poiché ogni soluzione può essere implementata e scomposta in modo diverso in base alle esigenze del dominio, all'impronta della tecnologia e così via.

Il dominio dell'applicazione è diviso in due elementi. Esiste l'applicazione SaaS che rappresenta l'esperienza/applicazione del tenant per la tua soluzione. Questa è la superficie che i tenant toccano per interagire con la tua applicazione SaaS. Poi ci sono i servizi di backend che rappresentano la logica aziendale e gli elementi funzionali di una soluzione SaaS. Questi potrebbero essere microservizi o altri pacchetti dei servizi applicativi.

Avrai anche notato che abbiamo interrotto l'approvvigionamento. Questo viene fatto per evidenziare il fatto che qualsiasi fornitura di risorse per i tenant durante l'onboarding farebbe parte di questo dominio applicativo. Qualcuno potrebbe obiettare che questo appartatto nel piano di controllo. Tuttavia, l'abbiamo inserito nel dominio dell'applicazione, perché le risorse che deve fornire e configurare sono più direttamente connesse ai servizi creati e configurati nel piano dell'applicazione.

Suddividerlo in piani distinti rende più facile pensare al panorama complessivo di un'architettura SaaS. Ancora più importante, evidenzia la necessità di una serie di servizi che esulano completamente dall'ambito delle funzionalità dell'applicazione.