La meilleure infrastructure cloud pour une application de logiciel-service (SaaS) est celle que son équipe peut exploiter, nuits et fins de semaine comprises. Pour une entreprise SaaS sans ingénieur d’infrastructure attitré, il s’agit habituellement d’une plateforme en tant que service (PaaS) infogérée ou de machines virtuelles (VM) qu’un fournisseur exploite. Kubernetes mérite sa place quand des ingénieurs sont affectés à son exploitation, ou quand le produit dépend de son écosystème. La question décisive est de savoir qui appliquera les correctifs du système d’exploitation, exploitera la base de données et répondra aux alertes.
Quelles sont les options d’infrastructure pour une application SaaS ?
Une équipe SaaS choisit entre quatre modèles d’infrastructure : les machines virtuelles, un PaaS infogéré, Kubernetes et les services natifs d’un hyperscaler. Chacun transfère à un fournisseur une part différente du travail d’exploitation.
Machines virtuelles. Une machine virtuelle est un serveur défini par logiciel, doté de son propre système d’exploitation. Le fournisseur exploite le matériel et la couche de virtualisation. Le client exploite tout le reste à partir du système d’exploitation : les correctifs, les environnements d’exécution, le serveur web, la base de données, les sauvegardes et la surveillance. Un fournisseur d’hébergement infogéré peut prendre ce travail à sa charge.
PaaS infogéré. Une plateforme en tant que service exécute l’application à partir de son code ou d’une image de conteneur. La plateforme provisionne les environnements d’exécution, les bases de données, les répartiteurs de charge et la mise à l’échelle, et l’équipe ne gère pas le système d’exploitation. Des produits en libre-service comme Heroku et Render suivent ce modèle. Les plateformes applicatives qu’exploitent des fournisseurs de cloud infogéré le suivent aussi.
Kubernetes. Kubernetes est un système à code source ouvert qui répartit des conteneurs sur une grappe de machines, appelée cluster, et qui les redémarre quand ils tombent en panne. Les services Kubernetes infogérés des grands clouds publics exploitent le plan de contrôle, soit la partie qui prend les décisions d’ordonnancement. Dans la plupart des configurations, le client reste responsable des nœuds de travail, des mises à niveau de version, du routage du trafic, des secrets, de la surveillance et des définitions de déploiement.
Services natifs d’un hyperscaler. Les grands clouds publics, souvent appelés hyperscalers, vendent des fonctions sans serveur, des services de conteneurs infogérés et des bases de données infogérées. L’équipe exploite peu de serveurs. En contrepartie, le code applicatif est écrit pour les interfaces d’un seul fournisseur.
Comment se comparent les VM, un PaaS infogéré et Kubernetes pour un SaaS ?
Le tableau compare les quatre modèles selon les critères qui comptent le plus pour une petite équipe SaaS.
| Critère | Machines virtuelles | PaaS infogéré | Kubernetes | Services natifs d’un hyperscaler |
|---|---|---|---|---|
| Ce que votre équipe exploite | Le système d’exploitation et tout ce qui se trouve au-dessus, sauf si un fournisseur en a le mandat | L’application et sa configuration | La configuration du cluster, les mises à niveau, le routage, la surveillance et l’application | L’application et le compte cloud |
| Compétences requises à l’interne | Administration de systèmes, sécurité, sauvegardes | Développement applicatif | Ingénierie de plateforme, en plus du développement applicatif | Architecture cloud, contrôle des accès, contrôle des coûts |
| Mise à l’échelle | Redimensionner le serveur ou en ajouter, à la main sauf si l’équipe bâtit l’automatisation | Des règles ajoutent ou redimensionnent des nœuds, quand le niveau applicatif est sans état | Automatisée, une fois que l’équipe l’a bâtie et réglée | Automatisée, facturée à l’usage |
| Portabilité | Élevée, un serveur Linux standard se reconstruit chez la plupart des fournisseurs | Dépend du degré de standardisation des environnements d’exécution et des images | Élevée d’un cluster à l’autre, moindre dès que des modules propres à un cloud sont utilisés | Faible, le code appelle les interfaces d’un seul fournisseur |
| Risque principal | Personne n’applique les correctifs ni ne surveille les serveurs | Des besoins qui dépassent les régions ou les fonctions de la plateforme | La plateforme absorbe le temps d’ingénierie destiné au produit | Une facture et un compte qui grossissent sans responsable |
Quand les machines virtuelles sont-elles le bon choix pour un SaaS ?
Les machines virtuelles sont le bon choix quand l’équipe a besoin de maîtriser le serveur et que quelqu’un s’en occupe. Quatre conditions orientent vers les VM.
- Quelqu’un est responsable du système d’exploitation. Un ingénieur de l’équipe applique les correctifs, durcit et surveille les serveurs, ou un fournisseur le fait par contrat.
- La charge de travail exige un contrôle au niveau du système d’exploitation. Un logiciel sous licence, un panneau de contrôle d’hébergement ou un réseau sur mesure conviennent mieux à un serveur qu’à une plateforme.
- La charge est stable et prévisible. Un serveur plus gros, ou un serveur de plus ajouté dans le cadre de travaux planifiés, absorbe la croissance.
- L’application conserve un état sur le serveur. Un monolithe qui écrit ses sessions et ses fichiers téléversés sur le disque local ne peut pas encore tourner en plusieurs copies identiques.
Les machines virtuelles sont le mauvais choix quand personne n’applique les correctifs du système d’exploitation, ou quand les déploiements se font encore à la main dans une session à distance. Elles conviennent mal aussi quand les pics de trafic exigent de la capacité en quelques minutes et que personne n’a bâti de mise à l’échelle automatisée. Un autre article aide à décider s’il faut embaucher un ingénieur DevOps ou impartir les opérations.
Quand un PaaS infogéré est-il le bon choix, et quand ne l’est-il pas ?
Un PaaS infogéré est le bon choix pour une petite équipe SaaS qui exploite une application classique et qui veut que ses ingénieurs se consacrent au produit. Trois conditions orientent vers un PaaS.
- L’application tourne sur un environnement d’exécution courant, comme PHP, Node.js, Java, Python, Go, Ruby ou .NET, ou elle est livrée sous forme d’image de conteneur.
- Le niveau applicatif est sans état, ou peut le devenir, de sorte que la plateforme peut en exécuter plusieurs copies identiques. Les sessions, les fichiers téléversés et les caches passent à des services partagés.
- L’équipe veut des environnements de staging, des déploiements reproductibles et un retour arrière sans bâtir l’outillage.
Sur un PaaS, la mise à l’échelle exige tout de même une décision, et la base de connaissances explique quand ajouter des nœuds et quand les redimensionner. Un SaaS qui isole chaque client doit faire un deuxième choix, traité dans le guide sur un environnement par client ou un environnement partagé.
Un PaaS infogéré est le mauvais choix dans quatre situations.
- Le produit dépend de l’écosystème Kubernetes. Un logiciel empaqueté pour Kubernetes, ou qui s’appuie sur des opérateurs Kubernetes, a besoin d’un cluster.
- La charge de travail exige du matériel spécialisé. Demandez si la plateforme offre des processeurs graphiques (GPU) ou du matériel semblable avant de le tenir pour acquis.
- L’application est bâtie sur les services natifs d’un hyperscaler. Les fonctions sans serveur et les services de données propriétaires n’existent pas sur une plateforme applicative générique.
- L’entreprise a besoin de régions que la plateforme n’a pas. Une plateforme dont les sites se trouvent dans un seul pays ne peut pas servir localement des utilisateurs d’un autre continent.
Une petite équipe SaaS a-t-elle besoin de Kubernetes ?
Une petite équipe SaaS n’a habituellement pas besoin de Kubernetes. Kubernetes règle le problème que pose l’exploitation de nombreux services sur de nombreuses machines au moyen d’une seule interface cohérente. Une équipe qui a une application, quelques processus de traitement en arrière-plan (workers) et une base de données n’a pas encore ce problème.
Kubernetes est le bon choix à quatre conditions.
- Des ingénieurs sont affectés à la plateforme. L’exploitation du cluster figure dans la description de poste de quelqu’un, et une deuxième personne peut prendre la relève.
- Le produit compte de nombreux services aux cycles de release distincts. Plusieurs équipes déploient de façon indépendante et ont besoin de règles communes pour le routage, la mise à l’échelle et les accès.
- Les clients installent le produit dans leurs propres clusters. Un SaaS qui livre aussi une édition autohébergée standardise souvent les deux sur Kubernetes.
- La pile repose sur des logiciels natifs de Kubernetes. Certains outils de données, d’apprentissage automatique et de réseau supposent un cluster.
Kubernetes est le mauvais choix quand l’équipe l’adopte par effet de mode, pour attirer des candidats ou dans l’espoir qu’il règle les problèmes de disponibilité. Un cluster ajoute du travail récurrent : les mises à niveau de version au rythme des releases du projet, le routage du trafic et les certificats, les secrets, les politiques réseau, la surveillance et la répartition des coûts. L’article de la base de connaissances sur la migration d’une application cPanel vers Kubernetes montre à quel point il importe de régler d’abord la base de données, les secrets et le stockage.
Faut-il réécrire un monolithe patrimonial ou le déplacer vers une plateforme infogérée ?
Déplacez un monolithe patrimonial, c’est-à-dire une application ancienne d’un seul bloc, vers une plateforme infogérée quand l’application fonctionne et que les problèmes sont opérationnels. Les pannes, les déploiements sans retour arrière possible et les périodes de lenteur pendant les traitements par lots sont des problèmes de plateforme.
Un mandat publié illustre le compromis. Une entreprise canadienne de SaaS interentreprises (B2B) d’environ douze personnes exploitait un monolithe Laravel de dix ans sur un seul serveur dédié. Les fondateurs avaient prévu six mois pour une réécriture. Le scénario type sur la modernisation d’un monolithe Laravel rapporte que, dans ce seul mandat, Stack Harbor a déconseillé la réécriture. La même application est passée au Cloud PaaS infogéré de Stack Harbor au terme d’une migration de huit semaines, sans réécriture. Le coût d’infrastructure a augmenté de 11 %. Le scénario type estime aussi à soixante heures par mois le temps d’ingénierie des fondateurs rendu au produit. C’est le résultat d’un seul mandat pour une seule charge de travail, et non un résultat typique.
Le même scénario type précise qu’une réécriture peut être la bonne décision quand l’architecture empêche l’équipe de livrer sa prochaine ligne de produit.
Quels facteurs déterminent le coût de chaque option ?
Pour une petite équipe SaaS, le poste d’infrastructure explique rarement le plus grand écart de coût entre des VM, un PaaS infogéré et Kubernetes. La main-d’œuvre l’explique habituellement.
| Poste de coût | Machines virtuelles | PaaS infogéré | Kubernetes |
|---|---|---|---|
| Ressources d’infrastructure | Taille des serveurs, stockage, bande passante | Ressources utilisées, souvent avec des frais de plateforme en plus | Nœuds de travail, répartiteurs de charge et, sur certains services infogérés, des frais pour le plan de contrôle |
| Main-d’œuvre d’exploitation | Élevée, sauf si un fournisseur en a le mandat | Faible pour l’équipe, comprise dans la plateforme ou dans le périmètre infogéré | Élevée, et spécialisée |
| Outillage | Surveillance, sauvegardes et outils de déploiement achetés ou bâtis | Compris en grande partie, confirmez ce qui fait partie du périmètre | Outils de surveillance, de routage, de secrets et de livraison assemblés par l’équipe |
| Migration | Faible pour une application qui tourne déjà sur un serveur | Modérée, plus élevée quand le niveau applicatif doit d’abord devenir sans état | Élevée, l’application est conteneurisée et son déploiement redéfini |
Trois facteurs font varier un devis, quelle que soit l’option. Les environnements de staging et de prévisualisation multiplient les ressources. Une base de données répliquée coûte plus cher qu’une instance unique. Une réponse aux incidents jour et nuit coûte plus cher qu’une couverture pendant les heures ouvrables.
Pour chiffrer la main-d’œuvre, consignez pendant un mois les heures d’ingénierie consacrées aux correctifs, aux déploiements, aux incidents et aux questions de coût. Multipliez ce total par un coût horaire complet, avantages sociaux compris, et ajoutez le résultat à chaque option. L’article qui explique comment est tarifé l’hébergement cloud infogéré détaille les facteurs qui expliquent le devis d’un fournisseur.
À quelles questions une équipe SaaS devrait-elle répondre avant de choisir une plateforme ?
Sept questions règlent l’essentiel du choix entre des machines virtuelles, un PaaS infogéré et Kubernetes pour une application SaaS.
- Qui est de garde pour la plateforme ce soir ? Nommez la personne. S’il n’y a pas de nom, achetez l’exploitation avec la plateforme.
- Combien de services déployés séparément existent aujourd’hui ? Comptez ce qui existe, et non ce qu’imagine la feuille de route.
- Le niveau applicatif peut-il tourner en plusieurs copies identiques ? Sinon, dressez la liste de ce qui le lie à un seul serveur.
- Quels services appelés par le code n’existent que chez un seul fournisseur ? Une longue liste signifie que le choix de la plateforme est déjà fait.
- Où les données de production et les sauvegardes doivent-elles se trouver, et où sont les utilisateurs ? Les régions retiennent ou éliminent vite des options.
- Des clients ou des partenaires exigent-ils une plateforme précise ? Une édition autohébergée ou une règle d’approvisionnement peut trancher la question.
- Combien coûte l’installation actuelle chaque mois, main-d’œuvre comprise ? Sans ce chiffre, aucune option ne peut être comparée équitablement.
Un nom manquant à la question 1 et un petit nombre à la question 2 orientent vers un PaaS infogéré ou vers des machines virtuelles qu’un fournisseur exploite. Une longue liste à la question 4 indique qu’il vaut mieux rester sur ce cloud. Un autre article compare l’exploitation d’Amazon Web Services (AWS) par vos propres moyens et un cloud infogéré. Des ingénieurs de plateforme dans l’équipe, de nombreux services ou un oui à la question 6 orientent vers Kubernetes.
Où se situe Stack Harbor
Stack Harbor est un fournisseur d’exploitation infonuagique gérée (MSP) pour les environnements de production, de propriété canadienne, dont le siège est à Montréal. Elle travaille avec des entreprises SaaS, des agences et des éditeurs. Ses clients sont des petites et moyennes entreprises (PME) et des agences d’environ 5 à 200 personnes qui exploitent des systèmes de production sans avoir leur propre équipe d’exploitation 24/7. Sa propre infrastructure canadienne tourne dans deux centres de données à Montréal.
Stack Harbor offre deux des quatre modèles sur sa propre infrastructure. Cloud PaaS est une plateforme applicative infogérée dotée d’environnements d’exécution (runtimes) infogérés pour PHP, Node.js, Java, Python, Go, Ruby et .NET. Elle comprend des bases de données infogérées, des déploiements blue/green et rolling, et le clonage de la production vers le staging en un clic. La mise à l’échelle horizontale se déclenche sur le CPU, la mémoire ou des métriques personnalisées. Cloud PaaS repose sur la plateforme applicative Virtuozzo, et la base de connaissances explique pourquoi Stack Harbor utilise Virtuozzo.
Cloud Compute fournit des machines virtuelles, du bare metal et un réseau privé, avec un périmètre infogéré qui va de l’exploitation par le client à l’infogérance complète. Le redimensionnement vertical se fait en direct, l’ajout horizontal de serveurs est une opération planifiée, et la bascule régionale est une opération infogérée, pas automatique.
Stack Harbor ne vend pas Kubernetes comme service infogéré. Sa page de services décrit Cloud PaaS comme la couche plateforme pour les équipes qui ne veulent pas exploiter Kubernetes. Sa page sur les clusters à haute disponibilité (HA) qualifie Kubernetes d’utile pour certaines charges et d’exagéré pour la plupart des PME en croissance. Un SaaS qui a besoin de l’écosystème Kubernetes, ou de régions autres que les centres de données de Stack Harbor, devrait chercher ailleurs. Pour un SaaS dont la place est sur AWS, les opérations AWS infogérées couvrent le propre compte du client, et l’hébergement chez Stack Harbor n’est pas requis.
La solution d’auto-scaling fixe les règles de mise à l’échelle et un plafond dur pour le nombre de nœuds avant la mise en ligne. Dans la majorité des architectures de PME, la base de données ne se met pas à l’échelle automatiquement. La solution de pipeline de déploiement ajoute les builds, les tests, une porte d’approbation et le retour arrière.
Stack Harbor ne publie pas de prix. Le prix de Cloud PaaS combine des frais de plateforme par environnement et les ressources utilisées. Un devis fixe suit un appel de cadrage, comme l’explique la page qui décrit comment Stack Harbor cadre et chiffre un mandat.
Avant de comparer des plateformes, une équipe SaaS devrait mettre par écrit qui exploitera chaque couche une fois le produit en ligne.
