« Ça tourne dans le cloud ? » « Oui. » « C’est donc cloud native ? » « Euh. »
Cloud native fait partie de ces termes qu’on vous assène le plus souvent quand on veut vous vendre quelque chose, en général Kubernetes, parfois un projet de migration très coûteux. L’idée derrière est simple. Et elle n’est pas anodine, surtout si vous faites développer un logiciel sur mesure qui doit tenir les prochaines années.
Hébergé dans le cloud, c’est autre chose
Mettre votre application existante sur un serveur cloud ne la rend pas vraiment cloud native. Le logiciel ne remarque même pas qu’il est dans le cloud. Il attend toujours une seule machine, un seul disque, un seul endroit où tout se trouve. Cela marche très bien, jusqu’au jour où cette machine tombe, où vous avez soudain deux fois plus d’utilisateurs, ou où vous voulez changer de fournisseur.
Un logiciel cloud native part dès le début du principe que la machine sur laquelle il tourne peut disparaître à tout moment, et qu’il peut tout aussi bien tourner en cinq copies à la fois. Pour un administrateur système, cela ressemble à un détail. En pratique, c’est exactement la décision qui détermine combien votre logiciel vous coûtera dans les années à venir.
L’application n’écrit rien sur le disque
C’est le cœur du sujet. Tout le reste en découle.
Si un programme en cours d’exécution ne garde rien dont vous avez besoin, vous pouvez sans conséquence l’arrêter, le remplacer ou le lancer dix fois en parallèle. Déployer une nouvelle version ? Vous démarrez un nouveau conteneur, vous y envoyez le trafic et vous arrêtez l’ancien. Un plantage ? On redémarre. Un pic d’utilisation ? On en ajoute deux.
Si ce même programme garde quelque chose (un fichier envoyé, une session en mémoire, un fichier de log), aucune de ces astuces ne fonctionne plus, et chaque intervention devient une corvée risquée.
Les conteneurs, en pratique Docker, rendent cela possible. Ils emballent votre application avec tout ce dont elle a besoin, pour qu’elle tourne à l’identique partout. Mais un conteneur n’est utile que s’il ne contient rien que vous n’ayez pas le droit de perdre.
Où se trouvent alors vos données
Ne rien écrire sur le disque ne veut pas dire que vos données ne sont nulle part. Elles déménagent vers un petit nombre d’endroits faits pour ça.
- Une base de données, chez nous le plus souvent Postgres, pour vos données et vos sessions. La façon de modéliser ces données est une autre histoire. Nous en avons parlé dans qu’est-ce que l’event sourcing et quand est-ce rentable pour une PME.
- Du stockage objet (object storage) pour les fichiers : contrats, photos, PDF envoyés. Exactement ce qu’il vous faut si vous voulez par exemple traiter des documents avec l’IA.
- De la télémétrie pour les logs, les métriques et les traces. Nous les envoyons à l’extérieur avec OpenTelemetry, au lieu de les écrire dans un fichier de log sur le serveur.
Ainsi, l’application reste remplaçable, et il ne reste qu’un seul endroit à vraiment protéger.
Ce qu’une PME y gagne
Vous voyez la différence à quatre moments.
À chaque mise à jour. Les nouvelles versions passent en production sans que personne ait à se déconnecter. Fini la fenêtre de maintenance le dimanche soir.
Quand quelque chose casse. Vous rétablissez en redémarrant, pas en réparant. Une panne dure quelques secondes au lieu d’une demi-journée.
Quand vous grandissez. Plus de capacité, c’est simplement une deuxième copie à démarrer. Votre logiciel grandit avec votre entreprise au lieu de la freiner.
Pour vos sauvegardes. Comme toutes les données précieuses sont au même endroit, votre stratégie de sauvegarde est assez simple pour être vraiment testée. Une partie de vos devoirs NIS2 est ainsi faite.
Vous n’avez pas besoin d’un hyperscaler pour ça
Cloud native est souvent compris comme « chez Amazon, Microsoft ou Google ». C’est faux, et c’est même parfois l’inverse.
Une application qui repose entièrement sur les services maison d’un seul fournisseur est peut-être moderne, mais vous ne pouvez l’emmener nulle part ailleurs. C’est justement la dépendance à un fournisseur (vendor lock-in) que vous vouliez éviter avec les conteneurs. Une application conteneurisée avec un Postgres ordinaire et un stockage compatible S3, vous la déménagez en une journée. Nous les faisons tourner sur des serveurs européens ; le raisonnement derrière ce choix se trouve dans comment le cloud européen peut aider votre entreprise.
C’est la même chose pour Kubernetes. Un outil magnifique si vous gérez cent services. Pour la plupart des projets de PME, c’est un deuxième problème qui s’ajoute au premier. Des conteneurs derrière un reverse proxy font le même travail, pour une fraction de la maintenance. Nous avons détaillé cet arbitrage dans une PME a-t-elle vraiment besoin de Kubernetes ? Mais une application conçue cloud native passe très simplement d’un simple Docker Compose à Kubernetes, ou l’inverse.
Comment nous abordons cela chez Tandem Studio
Notre configuration standard pour le sur-mesure est volontairement ennuyeuse. Une application en Go, emballée dans un conteneur, avec Postgres pour les données et du stockage objet pour les fichiers. Docker Compose derrière Traefik, la télémétrie via OpenTelemetry, le tout sur des serveurs européens chez Scaleway.
Rien dans l’application ne touche le disque. C’est pourquoi, trois ans plus tard, nous pouvons encore déployer des mises à jour sans souci, sans vous appeler le soir.
La base de données, elle, écrit évidemment sur le disque. C’est le seul volume qui compte, et le seul dont la sauvegarde détermine vraiment votre disponibilité. Qui met Postgres dans un conteneur sans volume l’apprend à ses dépens.
Questions fréquentes
Cloud native, c’est la même chose que Kubernetes ?
Non. Kubernetes est une façon de faire tourner un logiciel cloud native, et pour la plupart des PME, une façon lourde. Le principe tient à la manière dont votre application est construite, pas à la plateforme sur laquelle elle tourne.
Dois-je passer chez AWS ou Azure pour être cloud native ?
Non, et cela peut même jouer contre vous. Plus vous dépendez des services maison d’un fournisseur, plus il est difficile d’en partir. Un conteneur avec un Postgres ordinaire et un stockage compatible S3 tourne tout aussi bien sur une infrastructure européenne.
Peut-on rendre un logiciel existant cloud native ?
Souvent oui, et c’est en général un travail plus limité qu’une reconstruction. La question est chaque fois : qu’est-ce que l’application écrit aujourd’hui sur le disque, et où cela peut-il aller ? Les fichiers envoyés vers le stockage objet, les sessions vers la base de données, les logs vers la télémétrie.
Cela veut-il dire que plus rien n’est stocké sur un disque ?
Non. La base de données écrit bel et bien sur le disque, et c’est exactement le but. L’important, c’est que tout ce que vous ne pouvez pas perdre se trouve à un seul endroit géré, plutôt que dispersé dans chaque conteneur en cours d’exécution.
La façon dont votre logiciel traite les données détermine ce qu’il vous coûtera dans les années à venir, que vous ayez une application existante arrivée à ses limites ou que vous partiez de zéro.
Dites-nous ce que vous avez en tête, et nous verrons ensemble ce qui a du sens dans votre cas.
