Architecture à mettre en place pour un SaaS en fonction du client
À travers sa présentation, Émilien nous partage son expérience quant aux décisions à prendre et quelles questions se poser pour partir l'esprit serein. J'ai donc voulu revenir sur ce sujet en reprenant les grandes lignes de sa conférence.
Mais avant ça, avez-vous déjà entendu parler de SaaS (ou Software as a Service) ? Ou peut-être aviez-vous prévu d'en créer un ? Ce type de solution présente bien des avantages en termes de business, mais qu'en est-il de son architecture et de l'utilisation de services tiers ?
Qu'est-ce qu'un SaaS ?
Un SaaS, ou Software as a Service, est une application qui sera hébergée par l'entreprise éditrice de ce dernier, et qui le mettra à disposition de ses clients sur Internet. L'utilisateur n'aura rien à installer de plus que son navigateur Web pour utiliser le service. Pour Émilien, un SaaS doit surtout répondre à un besoin commun.
Si on prend Netflix en exemple, ce service répond effectivement à un besoin commun : regarder un film, ou une série, depuis chez soi sans devoir acheter une version physique.
De même pour Microsoft avec sa suite Office en cloud : un besoin de pouvoir accéder en ligne à ses documents et de les éditer où que l'on soit sans avoir à installer de logiciel.
Mais alors, pourquoi créer un Saas ? Quels avantages ?
Découvrez les 4 avantages de cette solution présentés lors de cette conférence :
> Disponibilité
Le client profite du service dès sa souscription, sans avoir besoin de matériel ni intervention humaine. Plus besoin de matériel performant puisque le service est hébergé par son fournisseur.
> Déploiement
Lorsque le produit évoluera, il sera également plus facile de le déployer. Tous les utilisateurs en profiteront en même temps.
> Scalabilité
Bien souvent on peut retrouver plusieurs types d'abonnement :
- un premier tiers souvent gratuit, pour un solo-preneur ou un hobbyist,
- un second tiers avec un prix abordable pour un professionnel ayant plus de besoins,
- un dernier tiers, généralement destiné aux entreprises pour bénéficier de toutes les fonctionnalités.
> Financier
Proposer différent type d'abonnement permet de faire rentrer un client par la petite porte. Si son business grossis, son abonnement pourra changer selon ses besoins. Il y a donc le double avantage :
- Le client n'a plus à investir dans du matériel ou des licences. Il choisit l'abonnement en fonction de son besoin.
- Un système d'abonnement permet une rentrée d'argent régulière (mensuelle ou annuelle).
Évidemment, lorsqu'on est le concepteur, cela nécessite un lourd investissement financier avant que son produit soit disponible et surtout rentable.
Quelle architecture pour un SaaS (Software as a Service) ?
Choisir la bonne architecture est primordiale car c'est de ce choix dont dépendra la réussite du produit que vous souhaitez créer.
Multi-tenant
C'est le choix le plus pertinent lorsqu'on démarre un SaaS car il permet de limiter les coûts d'infrastructure.
> Multi-tenant avec une base de données par tenant
Cette architecture permet d'isoler les données de chacun de vos clients, ce qui facilite la restauration des données sans impacter les autres clients. En revanche si l'un des clients a une demande particulière, il sera plus difficile d'ajouter une fonctionnalité à l'application étant donné qu'elle est commune avec les autres clients.
> Multi-tenant avec une base de données commune
Ce type d'architecture permet de réaliser des économies considérables sur son architecture. En revanche les performances peuvent être impactées par les actions de l'un des clients. Un autre point négatif...la restauration. Il pourra être plus délicat de mettre en place un backup avec cette architecture.
> Quelle décision prendre ?
Pour faire son choix, il faudra finalement se poser les questions suivantes :
- Est-ce que j'ai de l'argent ?
- Est-ce que je veux une application scalable (facilement) ?
- Est-ce que j'ai suffisamment de développeurs ?
L'utilisation de service tiers
Il est essentiel de gérer les services tiers dont peux dépendre votre application SaaS. Voyons désormais quelles solutions il est possible de mettre en œuvre :
> Single point of failure – SPOF
Si votre application dépend d'un service tiers et que ce dernier tombe en panne, c'est le crash assuré pour votre application. C'est ce qu'on appelle le single point of failure (SPOF). Il faudra donc veiller à le prendre en considération lorsque vous aurez besoin de vous interconnecter avec un ou plusieurs services et de catcher les erreurs qui mèneront à l’interruption de service.
> Le pattern Circuit Breaker
Pour prévenir des crashs et donc éviter le SPOF (single point of failure), il sera donc judicieux de mettre en place ce design pattern sur votre application afin d'avoir une solution de repli.
Il agira comme un interrupteur avec un statut ouvert ou fermé et en fonction de ce statut, une solution de repli pourra être mis en place : utilisation de cache, redirection de l'utilisateur.
Maintenir des logs pour connaître l'état du service permettra de gagner du temps et des ressources lorsqu'une action est réalisée par l'utilisateur, nous parlerons donc de fail fast et encore une fois, une réponse adaptée pourra être retournée.
Le mot de la fin
Grâce à Émilien et son expertise sur le sujet, nous avons pu creuser un peu plus le sujet de l'architecture SaaS. Il faudra veiller à se poser les bonnes questions et faire les bons choix au moment opportun pour que la réalisation de son produit soit un succès. Mais une chose demeure importante avant même la technique, et je vais pour ça le citer à nouveau :
Comprendre le besoin utilisateur pour l'expliquer à une machine.
Edouard Bouard
Vous avez aimé cet article, découvrez les autres articles rédigés suite à l'AFUP Day 2024 :
- Maintien et scalabilité d'une application vieille de 20 ans
- Principes et implémentation d’OpenTelemetry dans des projets PHP
- Game-changing CSS : les techniques pour des sites Web performants
- Container, the hard way : un voyage à travers la complexité des conteneurs
- Comprendre le TDD : principes, architecture hexagonale et types de tests
- Introduction à l’Event Sourcing en PHP
Crédit photo : Melpomenem