Publié le 22 novembre 2024.

Pour une application SaaS, l'architecture mono-tenant garantit une isolation et permet une plus grande personnalisation pour chaque client, mais rend aussi la gestion des multiples instances complexes. Cet article explore comment Kubernetes, associé à Crossplane et ArgoCD, permet d'automatiser efficacement la gestion des applications mono-tenant.

Multi-tenant vs Mono-tenant : Quelle est la différence ?

Les architectures multi-tenant et mono-tenant sont deux modèles clés dans le développement d'applications SaaS.

  • Multi-tenant : Une seule instance de l'application est partagée entre plusieurs clients. Ce modèle réduit les coûts et simplifie la gestion des ressources, mais limite la personnalisation et complique l'isolation des données. Il est souvent utilisé pour des applications comme les outils de collaboration, de stockage cloud ou les plateformes de streaming.
  • Mono-tenant : Chaque client dispose de sa propre instance dédiée, ce qui permet une isolation totale des données, une personnalisation complète et une sécurité renforcée. Toutefois, ce modèle génère des coûts plus élevés et une gestion plus complexe de l'infrastructure. Il est souvent utilisé dans des secteurs exigeants comme la finance, la santé ou les logiciels métiers (CRM, ERP).

Prenons un exemple pratique : une startup fictive dans le domaine du médical qui propose à ses clients une application SaaS pour gérer ses factures. Cette entreprise opte pour l’architecture mono-tenant car certains de ses clients ont des exigences strictes en matière de sécurité et de conformité. Le défi est de taille : comment héberger et gérer ces multiples instances de manière scalable et la plus automatisée possible ?

La problématique d'héberger des applications mono-tenant

L'hébergement d'applications mono-tenant pose plusieurs défis techniques. Chaque client exige son propre environnement, avec ses ressources et sa base de données, ce qui conduit à une multiplication des environnements à gérer. Deux approches sont courantes pour relever ce défi :

  1. Utiliser des machines virtuelles (VMs) pour chaque client. Cette méthode garantit une isolation complète, mais implique de gérer chaque environnement individuellement : création, configuration, maintenance et mise à jour des ressources. Bien que cela puisse être automatisé en partie avec des outils d'infrastructure-as-code, la gestion des VMs reste relativement complexe, coûteuse en ressources et difficile à automatiser à grande échelle. Les VMs sont encore souvent utilisées pour des systèmes legacy, mais cette approche est de plus en plus remplacée par des solutions plus modernes.
  2. Utiliser la conteneurisation des applications. Il s’agit d’une solution qui permet d'isoler chaque instance d’application au sein d’un conteneur léger et reproductible, qui peut être déployé, redimensionné et mettre à jour rapidement. Cette approche, devenue le standard pour les applications modernes, garantit une flexibilité et une portabilité entre différents environnements d’hébergement.

Notre startup choisit cette deuxième méthode. Mais pour gérer efficacement des centaines ou des milliers de conteneurs mono-tenant, il est crucial d'utiliser un orchestrateur. C’est ici que Kubernetes entre en jeu.

Kubernetes : La solution pour automatiser et isoler les environnements mono-tenant

Kubernetes est devenu l’outil de référence pour orchestrer des conteneurs à grande échelle. Il utilise des namespaces pour organiser et séparer logiquement les ressources (comme les services, les pods et les volumes) au sein d'un même cluster. C’est ainsi que nous pouvons construire, pour chaque client de notre startup, son propre namespace, ce qui facilite la gestion des environnements. Kubernetes permet d'appliquer des quotas de ressources au niveau des namespaces, garantissant ainsi que chaque client dispose de limites sur l'utilisation de CPU et RAM, afin d'éviter qu'un client n'épuise les ressources au détriment des autres.

Attention toutefois, les namespaces ne représentent que des isolations logiques : si vous hébergez plusieurs clients au sein d’un même cluster Kubernetes, il est important d’isoler les namespaces entre eux pour garantir le cloisonnement entre clients. Pour assurer une isolation complète, il est nécessaire de mettre en place des mécanismes supplémentaires comme les permissions RBAC (Role-Based Access Control) pour gérer les accès et des network policies afin de restreindre les communications réseau entre les différents namespaces.

De plus, Kubernetes peut assurer une scalabilité automatique des ressources. Si un client a besoin de plus de puissance de calcul, par exemple un client avec une charge variable, il ajuste les ressources de manière dynamique. L'Horizontal Pod Autoscaler (HPA) permet d’ajuster automatiquement le nombre de pods en fonction de la charge, et le Cluster Autoscaler ou des solutions comme Karpenter adaptent dynamiquement la taille du cluster en ajoutant ou en retirant des nœuds en fonction des besoins en ressources.

Kubernetes gère ainsi les applications au niveau des conteneurs. Pour aller plus loin et gérer également l'infrastructure sous-jacente, nous devons introduire Crossplane.

Crossplane : Automatisation duprovisionnement d’infrastructures


Crossplane
étend les capacités de Kubernetes en permettant la gestion déclarative des infrastructures cloud. Cela est particulièrement important dans des environnements mono-tenant, où chaque client nécessite non seulement des applications isolées, mais aussi des infrastructures dédiées.

Bien que Terraform soit largement utilisé pour gérer des infrastructures de manière déclarative, il est surtout efficace dans des scénarios où l'infrastructure change peu fréquemment et peut être provisionnée à un rythme contrôlé. Pour notre entreprise, l’arrivée de nouveaux clients est fréquente et les infrastructures client doivent être déployées à la volée. Crossplane devient alors particulièrement utile.

Cet outil permet ainsi de déployer automatiquement les ressources cloud nécessaires pour chaque client. Cela inclut la création d’instances de base de données, de réseaux ou de systèmes de stockage, entièrement orchestrée par Kubernetes, garantissant une cohérence globale.

Dans notre exemple, cela est particulièrement utile pour des clients ayant des exigences spécifiques sur l’hébergement, comme le choix du fournisseur cloud. Ainsi, notre startup peut offrir à ses clients différents niveaux d’hébergement :

  • Environnement mono-tenant partagé sur GCP : Les clients A (une entreprise de suivi de la nutrition) et B (une entreprise donnant des conseils santé), souhaitent partager une infrastructure commune pour optimiser les coûts tout en garantissant une isolation logique des ressources.
  • Environnement mono-tenant dédié sur GCP : Le client C, un fournisseur de logiciels pour l'industrie pharmaceutique, souhaite disposer de son propre cluster Kubernetes et de son infrastructure dédiée, garantissant une isolation complète des ressources.
  • Environnement mono-tenant souverain sur S3NS : Le client D, une entreprise de médecine en ligne gérant des données sensibles, souhaite que celles-ci soient hébergées sur un cloud souverain en France, respectant les normes de sécurité et de conformité aux régulations locales.

Crossplane fonctionne de manière déclarative : les infrastructures sont définies à l’aide de fichiers YAML, ce qui permet de versionner et de suivre chaque environnement client via un dépôt Git.

Nous savons maintenant gérer les conteneurs et l’infrastructure sous-jacente. Mais pour assurer une gestion fluide et continue des déploiements et des mises à jour, nous avons besoin d'une solution GitOps robuste comme ArgoCD.

ArgoCD : Automatisation des déploiements


ArgoCD
est un outil GitOps qui automatise le déploiement des applications au sein des clusters Kubernetes à partir de définitions codées dans Git.

Il contrôle les modifications dans le dépôt Git et applique ces changements directement dans Kubernetes. Cela garantit que toutes les instances mono-tenant sont toujours synchronisées avec leur configuration d'origine. Pour revenir à notre exemple, lorsqu'une nouvelle fonctionnalité ou une mise à jour de sécurité est ajoutée à l'application de notre entreprise, ArgoCD déploie automatiquement cette version dans tous les environnements clients.

Enfin, ArgoCD surveille constamment l'état des environnements. En cas de divergence entre l'état réel et la configuration déclarée dans Git, il applique les correctifs nécessaires pour maintenir l’état désiré.

Résultat de l’exemple

Reprenons l’exemple de notre startup. Voici une vue simplifiée de l’architecture propos

Vue simplifiée de l’architecture

Il est totalement possible, en appliquant la méthode décrite dans cet article, d’offrir une flexibilité maximale et répondre aux besoins spécifiques de chaque client. Notre startup peut ainsi proposer à ses clients des environnements mono-tenant avec plusieurs options de souveraineté, grâce à ArgoCD qui gère les applications qui se trouvent dans les clusters et Crossplane qui gère les infrastructures, le tout orchestré par Kubernetes.

Conclusion

L’intégration de Kubernetes, Crossplane et ArgoCD offre une solution complète pour automatiser la gestion des applications mono-tenant. Kubernetes garantit une isolation stricte des ressources grâce aux namespaces et aux quotas, Crossplane provisionne les infrastructures nécessaires et facilite la gestion de plusieurs clouds, tandis qu'ArgoCD orchestre les déploiements de manière continue grâce au GitOps. Ensemble, ces outils permettent de créer une infrastructure cloud évolutive et personnalisable, essentielle pour les entreprises SaaS cherchant à optimiser la gestion de leurs applications mono-tenant tout en réduisant la complexité opérationnelle.

Chez Theodo Cloud, nous aidons les entreprises à tirer parti de ces technologies pour créer des infrastructures adaptées aux besoins des clients.