Les applications SaaS sont la nouvelle norme de nos jours, et les fournisseurs de logiciels cherchent à transformer leurs applications en une application Software As a Service. Pour cela, la seule solution est de construire une application SaaS en architecture multi-tenant. Vous êtes-vous déjà demandé comment Slack, Salesforce, AWS (Amazon Web Services) et Zendesk peuvent servir plusieurs organisations ? Chacun a-t-il son logiciel cloud unique et personnalisé par client ? Par exemple, avez-vous déjà remarqué que, sur Slack, vous avez votre propre URL « nomdevotreentreprise.slack.com ?
La plupart des gens pensent qu’en arrière-plan, ils ont créé un environnement particulier pour chaque organisation – application ou base de code – et pensent que les clients Slack ont leur propre environnement serveur/application. Si c’est vous, vous avez peut-être supposé qu’ils ont un processus reproductible pour exécuter des milliers d’applications sur tous leurs clients. Et bien non. La vraie solution est une architecture multi-tenant sur AWS pour une application SaaS.
Commençons par ce fait impressionnant : 70 % de toutes les applications Web sont considérées comme des applications SaaS selon IDC Research. Donc, si vous connaissez l’architecture SaaS et le multi-locataire, vous couvrez probablement 70% du paysage de l’architecture des applications Web qui sera disponible à l’avenir.
« 70 % de toutes les applications Web sont SaaS, mais seules quelques-unes d’entre elles sont multi-locataires.”
Cette recherche vise à présenter un aperçu des stratégies, des défis et des contraintes auxquels DevOps et les développeurs de logiciels sont susceptibles d’être confrontés lors de la conception d’une application SaaS multi-tenant.
Il y a deux concepts qu’il est important que nous comprenions avant de commencer :
Les prochains points sont ce que nous allons explorer dans une architecture multi-tenant pour votre application SaaS, et mes contributions seront :
Qu’est-ce que l’architecture multi-locataire ?
Tout d’abord, vous devez comprendre ce qu’est un locataire unique et architecture multi-tenant est:
- Architecture à locataire unique (modèle en silo): est une architecture unique par organisation où l’application possède sa propre infrastructure, matériel et écosystème logiciel. Disons que vous avez dix organisations ; dans ce cas, vous devrez créer dix environnements autonomes et votre application SaaS, ou entreprise, fonctionnera comme une architecture à locataire unique. De plus, cela implique plus de coûts, de maintenance et un niveau de difficulté à mettre à jour dans tous les environnements.
- Architecture multi-tenant: est un écosystème ou un modèle où un seul environnement peut servir plusieurs locataires en utilisant une architecture évolutive, disponible et résiliente. L’infrastructure sous-jacente est entièrement partagée, logiquement isolée et avec des services entièrement centralisés. L’architecture multi-tenant évolue en fonction de l’organisation ou du sous-domaine (organisation.saas.com) connecté à l’application SaaS ; et est totalement transparent pour l’utilisateur final.
Gardez à l’esprit que dans cet article, nous aborderons deux modèles d’architecture multi-locataires, un pour la couche application et un pour la couche base de données.
Avantages multi-locataires
L’adoption d’une approche d’architecture multi-tenant apportera de nombreux avantages précieux à votre application SaaS.
Passons en revue les contributions suivantes :
- Une réduction des coûts d’infrastructure de serveur grâce à une stratégie d’architecture multi-tenant :
- Au lieu de créer un environnement SaaS par client, vous incluez un environnement d’application pour tous vos clients. Cela permet de réduire considérablement vos coûts d’hébergement AWS de centaines de serveurs à un seul.
- Une seule source de confiance :
- Disons encore une fois que vous avez un client qui utilise votre SaaS. Imaginez combien de référentiels de code vous auriez par client. Au moins 3-4 succursales par client, ce qui représenterait beaucoup de surcharge et de versions de code mal alignées. Pire encore, visualisez le processus de déploiement de votre code sur l’ensemble de la batterie de locataires ; c’est extrêmement compliqué. Ce n’est pas viable et prend du temps. Avec une architecture SaaS multi-tenantvous évitez ce type de conflit, où vous aurez une base de code (source de confiance), et un dépôt de code avec quelques branches (dev/test/prod). En suivant la pratique ci-dessous – avec une seule commande (déploiement en un clic) – vous effectuerez rapidement le processus de déploiement en quelques secondes.
- Réduction des coûts de développement et du time-to-market :
- La réduction des coûts prend en compte une séquence de décisions à prendre, comme avoir une base de code unique, un environnement de plate-forme SaaS, une architecture de base de données multi-tenant, un stockage centralisé, des API et suivre la méthodologie des douze facteurs. Tous vous permettront de réduire les coûts de main-d’œuvre de développement, les délais de mise sur le marché et l’efficacité opérationnelle.
Pile technologique SaaS pour une architecture sur AWS
Pour créer une architecture mutualisée, vous devez intégrer la pile Web AWS appropriée, y compris le système d’exploitation, le langage, les bibliothèques et les services aux technologies AWS. Ce n’est que la première étape vers la création d’une architecture multi-tenant de nouvelle génération.
Même si nous présenterons quelques autres bonnes pratiques d’architecture multi-locataires, cet article sera principalement orienté vers cette pile Web AWS SaaS.
Plongeons-nous dans notre pile technologique SaaS sur AWS :
Langage de programmation
Peu importe la plate-forme linguistique que vous sélectionnez. Ce qui est essentiel, c’est que votre application puisse évoluer, utiliser les meilleures pratiques d’architecture multi-locataires, les principes natifs du cloud et un langage bien connu de la communauté open source. Le les dernières tendances pour créer des applications SaaS sont Python + React + AWS. Une autre « variante » est Node.js + React + AWS, mais au final, les dénominateurs communs sont toujours AWS et React. Si vous êtes une société financière, ML ou AI, avec des algorithmes complexes ou un travail backend, je dirai que vous devriez opter pour Python.
D’autre part, si vous utilisez des technologies modernes telles que les chats en temps réel, les mini-flux, le streaming, etc., optez pour Node.js. Il existe un marché dans le secteur bancaire qui exploite Java, mais c’est pour les entreprises établies. Toute nouvelle application SaaS va mieux avec la pile Web mentionnée. Encore une fois, c’est exactement ce que j’ai remarqué comme tendance et ce que la communauté exige.
Note: Ces données proviennent d’une enquête que nous avons réalisée il y a quelques mois auprès des entreprises de services financiers et SaaS.
Langues idéales
Fournisseur de cloud
En tant qu’équipe d’experts DevOps, j’ai constaté une variation cloud ces deux dernières années, et qui correspond à ces pourcentages : 70 % de nos implémentations DevOps sont basées sur AWS, 25 % sur Azure, et 5 % sur GCP et océan numérique. Chaque année, la tendance est similaire, à l’exception qu’Azure grandit progressivement avec les années. Ce ne sont pas seulement mes mots, mais aussi des idées soutenues par plusieurs partenaires DevOps. Je vous recommande donc fortement de déployer votre application SaaS sous AWS. Il a un certain nombre d’avantages; chaque jour, un nouveau service est disponible pour vous, et une nouvelle fonctionnalité qui facilite votre développement et votre déploiement. Totalement recommandé pour déployer votre SaaS sur AWS.
Microservices
Si vous envisagez d’exploiter le cloud, vous devez tirer parti des principes natifs du cloud. L’un de ces principes consiste à intégrer des microservices à Docker. Assurez-vous que votre application SaaS est sous microservices, ce qui apporte de nombreux avantages, notamment la flexibilité et la standardisation, la facilité de dépannage, l’isolation des problèmes et la portabilité. Tout comme le cloud, Docker et les microservices ont transformé l’écosystème informatique et le resteront encore longtemps.
Plate-forme d’orchestration de conteneurs
C’est une décision compliquée et abstraite; il existe trois options dans AWS pour gérer, orchestrer et créer un environnement de cluster de microservice :
- Amazon ECS: Il s’agit du système naturel d’orchestration de conteneurs Amazon dans l’écosystème AWS. (Fortement recommandé pour les startups, les petits SaaS et les moyens SaaS).
- Amazon Fargate: Presque sans serveur et le prix et la gestion sont par tâche. Effort opérationnel minimal par rapport à ECS. Certaines études ont été menées par notre équipe DevOps ; en termes de performances. Fargate peut être plus lent que ECS, donc pour ce cas particulier, je recommanderais Amazon ECS, au lieu de Fargate. Une autre pensée est que si votre équipe est composée de purs développeurs et ne prévoit pas d’embaucher un ingénieur DevOps, Fargate est peut-être la solution.
- Amazon EKS: Il s’agit d’un service géré qui facilite la gestion de Kubernetes sur AWS. Utilisez Amazon EKS au lieu de déployer un cluster Kubernetes sur une instance EC2, configurez la mise en réseau Kubernetes et les nœuds de travail. (Recommandé pour les grandes applications SaaS et une équipe de développement DevOps et Web sophistiquée).
Base de données
La base de données inhérente sera PostgreSQL avec Amazon RDS. Cependant, je recommande fortement que si vous avez une équipe de développement senior et que vous prévoyez un trafic élevé pour votre application SaaS – ou même des centaines de locataires – vous feriez mieux d’architecturer votre base de données avec MongoDB. En plus de cela, utilisez les meilleures pratiques qui seront mentionnées ci-dessous concernant la base de données multi-tenant. Dans ce cas, j’opterais pour Amazon RDS avec PostgreSQL ou DynamoDB (MongoDB).
« Si vous prévoyez un trafic élevé pour votre application SaaS, vous feriez mieux d’architecturer votre base de données avec MongoDB. »
GraphQL ou Amazon AppSync
GraphQL est un langage de requête et une alternative à une API RESTful pour vos services de base de données. Ce nouvel écosystème moderne est adopté comme intermédiaire entre le client et le serveur de base de données. Il vous permet de récupérer plus rapidement les données de la base de données, d’atténuer la surextraction dans les bases de données, de récupérer les données précises nécessaires à partir du schéma GraphQL et de maintenir la vitesse de développement en itérant plus rapidement qu’un service RESTful. L’adoption d’une application backend monolithique dans une architecture de microservices multi-locataires est le moment idéal pour tirer parti de GraphQL ou d’AppSync. Ainsi, lors de la transformation de votre application SaaS, n’oubliez pas d’inclure GraphQL !
Note: Je n’ai pas inclus ce service dans le diagramme d’architecture AWS SaaS, car il est implémenté de plusieurs manières et nécessiterait une explication approfondie sur ce sujet.
Automatisation
Vous avez besoin d’un mécanisme pour déclencher ou lancer de nouveaux locataires/organisations et l’attacher à votre…