Foussier is a French hardware supply specialist with more than 1,700 employees, over 80 stores and 100,000 customers. Its business relies on a strongly multichannel sales model, spanning its website, field sales reps, stores and phone. Any outage of its information system can directly hit its sales channels.
A few years ago, Foussier moved its applications to Kubernetes, running on a managed Azure AKS cluster and a second cluster on its own infrastructure. The development teams fully mastered their core business, but running the clusters required specific expertise, with significant operational stakes around Kubernetes and the many middleware components in use. The cloud bill, for its part, remained hard to forecast.
The group was therefore looking for a partner able to take over the full operation of its platforms with 24/7 support. That is exactly what we offer with our Secure Managed Kubernetes (SMK) solution: Kubernetes that is not only managed but fully operated for you, with hands-on, close support.
Taking over the existing setup before transforming it
The collaboration did not start with a migration, but with taking charge of what was already there. We first audited the existing environment and took over the operation of the two Kubernetes clusters already in production.
Within two weeks, our teams put the environments under monitoring, secured remote access and took over their day-to-day operations as they stood. Foussier quickly benefited from responsive, outsourced operations, without waiting for the future architecture to be built.
Only then did the transformation project begin. To replace the AKS cluster on Azure and modernize the vanilla Kubernetes installed at Foussier, we proposed keeping a hybrid architecture but rebuilding both environments around our Secure Managed Kubernetes service, while making the most of the infrastructure already in place.
SMK: one Kubernetes solution across two infrastructures
The first SMK platform is hosted in Enix datacenters, on a highly available Proxmox VE virtualization layer spread across 3 datacenters in the Paris region (both the Kubernetes control plane and the nodes). This platform mainly hosts the workloads that used to run on the Azure public cloud.
The second SMK platform is deployed directly at Foussier, on the VMware infrastructure the company already owns. It hosts the same business applications as the original platform, but in an industrialized and more secure way. The two environments are interconnected through a secure site-to-site VPN tunnel.
This is one of SMK’s key principles: we operate the same kind of Kubernetes cluster whatever the underlying infrastructure. At Foussier, that means Proxmox on one side and VMware on the other. The company thus gets a consistent level of service, operations and security across both platforms, while making the most of its existing infrastructure, without having to move all of it to its provider.
This approach also limits dependence on any particular technology or cloud provider. Kubernetes and the components used remain based on open standards and technologies, with an architecture that Foussier could evolve or move to another environment should its needs change.
Talos: security through minimalism
Security, the “S” in SMK, relies on security best practices and on purpose-built components, in particular a Talos foundation: an immutable operating system designed entirely for Kubernetes environments.
Updates are performed by automatically reinstalling the system, which guarantees a consistent configuration across all servers. Talos only ships the strictly necessary components: less software means fewer potential vulnerabilities and a smaller attack surface. For example, it removes SSH access, the remote connection administrators usually use to work on a server, but also a common entry point for attackers.
The various services are also isolated from one another so that an incident on one of them cannot spread to the others. This was an important requirement to avoid pooling operational risks across the different sales channels. The new architecture relies on standard middleware that we know inside out, such as PostgreSQL, Redis and RabbitMQ. These are deployed in the Kubernetes cluster through operators and are also monitored with a cloud native monitoring stack.
Two new Kubernetes platforms in production in 2.5 months
After taking over the existing setup, we spent about a month building the two new SMK platforms, on Foussier’s VMware infrastructure and on our Proxmox private cloud hosted in our datacenters. One more month was needed to migrate the applications and their data to these new environments. Foussier’s teams reworked the Helm charts and application packaging to align them with cloud native best practices.
All in all, 2.5 months after the start of the project, the new Kubernetes platforms were in production, hosting all workloads and fully operated by our teams.
The migration had been prepared and tested beforehand to keep its impact on the business to a minimum. The cutover took place in the evening, during a low-traffic window, with a service interruption limited to one hour for users.
Controlled costs, more room to maneuver
At the start of the project, price was not Foussier’s main criterion. Yet tailor-made hosting and managed services combined turned out to be cheaper than the former Azure public cloud platform.
Above all, these savings allowed Foussier to gain capacity without increasing its budget. The company went from three to four clusters and now has a dedicated development platform for each environment, with more powerful servers and Kubernetes nodes with more resources.
Another advantage of this kind of deployment on dedicated, pre-provisioned infrastructure (rather than on Azure or an equivalent public cloud) is that costs are predictable and agreed on from the very start of the collaboration.
A long-term relationship
For us, a project does not end once the platforms are built and the migration is done: our expertise shows just as much, if not more, in running them day to day. It is always part of a long-term relationship, carried by a small team of experienced engineers who handle operations and then support the platform as it evolves.
The closeness and responsiveness Foussier was looking for take shape in particular through a dedicated messaging channel, which lets its teams talk directly with the senior engineers in charge of the platforms.
Over the weeks, trust grew on both sides, to the point that the group opened the doors of its factory to us for a fascinating look at Foussier’s know-how.
A new phase is now under way: migrating the storage services still running on Azure to object storage on Enix Ceph. Foussier is thus pursuing the move it started with SMK: reducing its dependence on the public cloud while gaining control, predictability and freedom of choice over its infrastructure.
This story is a translation of an article originally published in French on Silicon.fr.
