Accompagner le passage d'une solution on-premise en SaaS

Le contexte

Un éditeur de logiciel dont la solution se déployait chez le client, et qui engage le passage à un modèle SaaS. Le sujet n’est pas seulement technique : changer de modèle économique change l’architecture. Une application livrée chez le client peut ignorer l’isolation, la montée de version et le coût par client ; une application SaaS ne le peut pas.

Ce qui a été fait

Un même projet, deux interventions espacées d’un an — un socle EKS, EC2, VPC et S3.

La première — la conception de l’architecture SaaS : trancher les questions structurantes avant d’écrire du code. Comment on isole les clients, comment on met à jour, comment on dimensionne.

La seconde — faire évoluer l’infrastructure en place, sous de nouvelles contraintes à intégrer.

Un même projet, deux temps

Ce n’est pas un second projet : la même solution, un an plus tard, avec de nouvelles contraintes. La seconde intervention n’était pas une refonte — il s’agissait de faire évoluer l’infrastructure en place, notamment sur le réseau.

C’est le genre de demande qu’une architecture SaaS doit savoir encaisser : les contraintes d’exploitation évoluent après la conception, et la question devient de savoir si le socle se laisse étendre ou s’il faut repasser par la case départ.

Services AWS mobilisés

Amazon EKS, Amazon EC2, Amazon VPC, Amazon S3.