Plan de contrôle ou plan d'application

Le schéma précédent fournit une vue conceptuelle des principaux concepts de l'architecture SaaS. Examinons maintenant cela plus en profondeur et définissons mieux la façon dont votre environnement SaaS se décompose en couches distinctes. Cette vision plus claire des frontières entre les concepts SaaS facilitera la description des éléments évolutifs d'une solution SaaS.

Le schéma suivant divise votre environnement SaaS en deux plans distincts. Le plan de contrôle est à droite. Cette partie du diagramme inclut toutes les fonctionnalités et tous les services utilisés pour intégrer, authentifier, gérer, exploiter et analyser un environnement mutualisé.

Plan de contrôle ou plan d'application

Ce plan de contrôle est à la base de tout modèle SaaS multi-tenant. Chaque solution SaaS, indépendamment du déploiement des applications et du schéma d'isolation, doit inclure les services qui vous permettent de gérer et d'exploiter vos clients via une expérience unique et unifiée.

Dans le plan de contrôle, nous l'avons ensuite décomposé en deux éléments distincts. Les services principaux présentés ici représentent l'ensemble des services utilisés pour orchestrer votre expérience mutualisée. Nous avons inclus certains des exemples courants de services qui font généralement partie du noyau, en reconnaissant que les services de base peuvent varier d'une solution SaaS à l'autre.

Vous remarquerez également que nous présentons une application d'administration distincte. Cela représente l'application (une application Web, une interface de ligne de commande ou une API) qui peut être utilisée par un fournisseur SaaS pour gérer son environnement mutualisé.

Une mise en garde importante est que le plan de contrôle et ses services ne sont pas réellement mutualisés. La fonctionnalité ne fournit pas les attributs fonctionnels réels de votre application SaaS (qui doit être mutualisée). Si vous examinez l'un des services principaux, par exemple, vous ne trouverez pas l'isolation des locataires ni les autres structures faisant partie de la fonctionnalité de votre application mutualisée. Ces services s'adressent à tous les locataires dans le monde entier.

Le côté gauche du diagramme fait référence au plan d'application d'un environnement SaaS. C'est là que réside la fonctionnalité multi-tenant de votre application. Ce qui apparaît dans le diagramme doit rester quelque peu vague, car chaque solution peut être déployée et décomposée différemment en fonction des besoins de votre domaine, de l'empreinte de votre technologie, etc.

Le domaine d'application est séparé en deux éléments. Il existe l'application SaaS qui représente l'expérience/l'application du locataire pour votre solution. Il s'agit de la surface que les locataires touchent pour interagir avec votre application SaaS. Ensuite, il y a les services dorsaux qui représentent la logique métier et les éléments fonctionnels d'une solution SaaS. Il peut s'agir de microservices ou d'autres packages de vos services applicatifs.

Vous remarquerez également que nous avons réparti le provisionnement. Cela permet de mettre en évidence le fait que tout approvisionnement de ressources pour les locataires lors de l'intégration ferait partie de ce domaine d'application. Certains diront que cela a sa place dans le plan de contrôle. Nous l'avons toutefois placé dans le domaine de l'application, car les ressources qu'il doit provisionner et configurer sont connectées plus directement aux services créés et configurés dans le plan de l'application.

En divisant cela en plans distincts, il est plus facile de réfléchir au paysage global d'une architecture SaaS. Plus important encore, cela met en évidence la nécessité de disposer d'un ensemble de services qui sortent totalement du cadre des fonctionnalités de votre application.