Choisir l'hébergement canadien pour une application SaaS : infrastructure, conformité et mise à l'échelle

Une application SaaS au service des entreprises canadiennes a des exigences d'infrastructure qu'un site web d'entreprise standard n'a pas. Les données de vos clients sont stockées aux côtés des données d'autres clients sur les mêmes serveurs. Votre application doit être disponible en permanence car les temps d'arrêt sont un problème contractuel. Vos obligations de confidentialité sont accrues car vous êtes un sous-traitant de données pour vos clients et leurs utilisateurs. Et si votre produit réussit, votre infrastructure doit pouvoir croître sans nécessiter une reconstruction complète.

Multi-location et isolation des données

La multi-location signifie que votre application sert plusieurs clients (locataires) depuis un seul déploiement d'infrastructure. Au niveau de la base de données, il existe deux approches courantes. La base de données par locataire crée une base de données séparée pour chaque client. L'isolation est propre : les données d'un client ne peuvent pas être accidentellement exposées à un autre. La base de données partagée, schéma partagé stocke toutes les données des locataires dans les mêmes tables avec une colonne tenant_id comme discriminateur. C'est la plus simple à développer mais nécessite une discipline extrême dans chaque requête pour éviter l'exposition des données entre locataires.

Infrastructure de départ pour un SaaS canadien

Le bon point de départ pour la plupart des applications SaaS canadiennes est un seul VPS avec une allocation de ressources généreuse, pas une architecture distribuée complexe. La complexité architecturale prématurée tue les produits en phase précoce en consommant du temps d'ingénierie qui devrait aller dans le développement du produit. La configuration de départ qui fonctionne pour la plupart des produits SaaS canadiens : un VPS de 4 à 8 vCPU avec 8 à 16 Go de RAM et du stockage NVMe, exécutant une instance PostgreSQL ou MySQL/MariaDB gérée, un serveur d'application dans le cadre qu'utilise votre produit, Nginx comme proxy inverse et Redis pour le stockage de session et la mise en cache.

Obligations de confidentialité en tant que fournisseur SaaS au Canada

Quand votre SaaS canadien traite des renseignements personnels sur les utilisateurs de vos clients, vous êtes un sous-traitant de données en vertu de la LPRPDE. Vos clients, en tant que responsables du traitement, remplissent en partie leurs obligations envers leurs propres utilisateurs en choisissant un sous-traitant (vous) qui offre des protections appropriées. Vos conditions de service et votre accord de traitement des données doivent aborder cette relation explicitement. Avoir un avenant sur le traitement des données disponible vous positionne comme un fournisseur crédible plutôt qu'une startup qui n'a pas réfléchi à la confidentialité.

Mise à l'échelle d'un VPS unique vers une architecture distribuée

Le chemin de mise à l'échelle canonique pour un SaaS canadien fonctionnant sur un VPS commence par la mise à l'échelle verticale (ajout de plus de CPU et de RAM au serveur existant) car elle ne nécessite aucun changement d'application. L'étape suivante est de séparer la base de données sur un serveur dédié. Après cela, la mise à l'échelle horizontale du niveau applicatif (plusieurs serveurs d'application derrière un équilibreur de charge) devient appropriée pour les charges de travail à haute concurrence. Chacune de ces étapes peut être exécutée sans réécriture complète si l'application a été conçue avec quelques principes de base : serveurs d'application sans état, connexions de base de données via un pool et configuration via des variables d'environnement.