Foussier est un spécialiste français de la quincaillerie, avec plus de 1 700 collaborateurs, plus de 80 magasins et 100 000 clients. Son activité repose sur un modèle de vente fortement multicanal, entre site web, commerciaux terrain, boutiques et téléphone. Toute interruption du système d’information risque d’affecter directement ses différents canaux de vente.
Il y a quelques années, Foussier avait migré ses applications sur Kubernetes, déployé sur un cluster managé Azure AKS et un second cluster sur ses infrastructures. Les équipes de développement maîtrisaient pleinement leur cœur de métier, mais l’exploitation des clusters exigeait une expertise spécifique avec des enjeux opérationnels conséquents sur Kubernetes et les nombreux middleware utilisés. La facture cloud, de son côté, restait difficile à anticiper.
Le groupe cherchait donc un partenaire capable de reprendre l’exploitation complète de ses plateformes avec un support en 24/7. C’est ce que nous proposons avec notre solution Secure Managed Kubernetes (SMK) : un Kubernetes non seulement managé, mais aussi infogéré, avec un accompagnement de proximité.
Reprendre l’existant avant de le transformer
La collaboration ne commence pas par une migration, mais par une prise en main de l’existant. Nous avons d’abord audité l’environnement en place et pris en charge l’exploitation des deux clusters Kubernetes déjà en production.
En deux semaines, nos équipes mettent les environnements sous supervision, sécurisent les accès distants et reprennent leur infogérance en l’état. Foussier bénéficie ainsi rapidement d’une exploitation externalisée et réactive, sans attendre la construction de la future architecture.
Ce n’est qu’ensuite que débute le projet de transformation. Pour remplacer le cluster AKS sur Azure et pour moderniser le Kubernetes vanilla installé chez Foussier, nous avons proposé de rester sur une architecture hybride mais de reconstruire les deux environnements autour de notre service Secure Managed Kubernetes, tout en capitalisant sur les infrastructures déjà disponibles.
SMK, une même solution Kubernetes sur deux infrastructures
Une première plateforme SMK est hébergée sur nos datacenters Enix sur un socle de virtualisation Proxmox VE déployé en haute-disponibilité, distribuée sur 3 datacenters en Île-de-France (aussi bien le plan de contrôle Kubernetes que les nœuds). Cette plateforme héberge essentiellement les workloads qui étaient sur le cloud public Azure.
La seconde plateforme SMK est déployée directement chez Foussier, sur l’infrastructure VMware que l’entreprise possède déjà. Elle héberge les mêmes applications du SI que la plateforme initiale mais de manière industrialisée et plus sécurisée. Les deux environnements sont interconnectés avec un tunnel VPN site-to-site sécurisé.
C’est l’un des principes clés de SMK : nous opérons le même type de cluster Kubernetes, quel que soit le socle d’infrastructure sous-jacent. Chez Foussier, il s’agit de Proxmox d’un côté et de VMware de l’autre. L’entreprise bénéficie ainsi d’un niveau homogène de service, d’exploitation et de sécurité sur ses deux plateformes, tout en capitalisant sur son infrastructure existante, sans avoir à la déplacer intégralement chez son prestataire.
Cette approche permet également de limiter la dépendance à une technologie ou à un fournisseur de cloud particulier. Kubernetes et les composants utilisés restent fondés sur des standards et des technologies ouvertes, avec une architecture que Foussier pourrait faire évoluer ou reprendre sur un autre environnement si ses besoins devaient changer.
Talos, la sécurité par la sobriété
La sécurité, le « S » de SMK, repose sur les bonnes pratiques de sécurité et l’utilisation de composants spécialisés, notamment d’un socle Talos, un système d’exploitation immuable entièrement conçu pour les environnements Kubernetes.
Les mises à jour s’effectuent en réinstallant automatiquement le système, ce qui garantit une configuration homogène sur l’ensemble des serveurs. Talos n’embarque que les composants strictement nécessaires : moins de logiciels, donc moins de vulnérabilités potentielles et une surface d’attaque réduite. Il supprime par exemple l’accès SSH, cette connexion à distance utilisée habituellement par les administrateurs pour intervenir sur un serveur, mais qui constitue aussi une porte d’entrée fréquente pour les attaquants.
Les différents services sont également cloisonnés afin qu’un éventuel incident sur l’un d’eux ne se propage pas aux autres. Une exigence importante pour ne pas mutualiser les risques opérationnels entre les différents canaux de vente. La nouvelle architecture s’appuie sur des middleware standards que nous maîtrisons, comme PostgreSQL, Redis ou encore RabbitMQ. Ceux-ci sont déployés dans le cluster Kubernetes via des opérateurs et eux aussi supervisés avec une stack cloud native de monitoring.
Deux nouvelles plateformes Kubernetes opérationnelles en 2,5 mois
Après avoir repris l’exploitation de l’existant, nous avons consacré environ un mois à la construction des deux nouvelles plateformes SMK, sur les infrastructures VMware de Foussier et sur notre socle de cloud privé Proxmox hébergé dans nos datacenters. Un mois supplémentaire a permis de migrer les applications et leurs données vers ces nouveaux environnements. Les Helm charts et le packaging des applications ont été repris par leurs équipes pour les adapter aux bonnes pratiques cloud natives.
Au total, 2,5 mois après le début du projet, les nouvelles plateformes Kubernetes étaient en production, hébergeaient l’ensemble des workloads et étaient entièrement infogérées par nos équipes.
La migration avait été préparée et testée en amont afin de réduire au minimum son impact sur l’activité. La bascule a été réalisée en soirée, sur un créneau de faible affluence, avec une interruption de service limitée à une heure pour les utilisateurs.
Des coûts maîtrisés, une meilleure marge de manœuvre
Au début du projet, le prix n’était pas le critère principal de Foussier. Pourtant, l’hébergement sur mesure et l’infogérance réunis se sont révélés plus économiques que l’ancienne plateforme en cloud public Azure.
Cette économie a surtout permis à Foussier de gagner en capacité sans augmenter son budget. L’entreprise est passée de trois à quatre clusters et dispose désormais d’une plateforme de développement dédiée à chaque environnement avec des serveurs plus performants et des nœuds Kubernetes disposant de davantage de ressources.
Un autre avantage de ce type de déploiement sur des infrastructures dédiées et pré-provisionnées (plutôt que sur du cloud public Azure ou équivalent) est le fait que les coûts sont prévisibles et cadrés dès le début de la collaboration.
Une relation qui s’inscrit dans la durée
Pour nous, un projet ne s’arrête pas à la construction des plateformes et à la migration : notre expertise s’exprime aussi, et surtout, dans leur exploitation au quotidien. Il s’inscrit toujours dans une relation de long terme, portée par une équipe resserrée d’ingénieurs expérimentés qui gère l’exploitation et qui accompagne ensuite les évolutions de la plateforme.
La proximité et la réactivité recherchées par Foussier se concrétisent notamment par un canal de messagerie dédié, qui permet à ses équipes d’échanger directement avec nos ingénieurs seniors en charge des plateformes.
Au fil des semaines, la confiance s’est installée des deux côtés, jusqu’à nous ouvrir les portes de l’usine du groupe pour une découverte passionnante du savoir-faire de Foussier.
Une nouvelle étape est désormais engagée : migrer les services de stockage encore présents sur Azure vers du stockage objet sur Ceph Enix. Foussier poursuit ainsi le mouvement engagé avec SMK : réduire sa dépendance au cloud public tout en gagnant en maîtrise, en prévisibilité et en liberté de choix sur son infrastructure.
Cette story a été initialement publiée sur Silicon.fr.
