I design, run and cost-optimise production Kubernetes platforms.
Work with me Read the case studiesI'm Firas Chbiki, a Senior DevOps / Platform Engineer with eight years in production environments — six of them on Kubernetes.
Today I lead the DevOps team at Suez Smart Solutions, where I own the build, the run and the cost of a production Kubernetes platform on Azure. Before that, I built the large-scale load-testing capability for the M6 Group streaming platforms at Bedrock, and deployed Orange's telecom services across the MEA region at Sofrecom.
What that means day to day: designing and operating Kubernetes clusters, industrialising the delivery chain with Terraform and Helm, making observability useful rather than noisy, keeping the platform hardened and audit-ready, and bringing the cloud bill down without degrading service.
I'm also CKA-certified and a Microsoft Certified Trainer. I train teams on Kubernetes, Azure and DevOps practices — in my experience that's where adoption is won or lost, far more than in the tooling.
Based in Île-de-France. Open to freelance missions and permanent roles.
I own the build, the run and the cost of a production Kubernetes platform on Azure, and I lead the DevOps team that keeps it running.
• Operating a fleet of AKS clusters in production: architecture, version upgrades, consistency across environments, incident handling.
• Leading the DevOps team day to day — work allocation, technical review, skills development, and the interface with the development teams.
• Industrialising the delivery chain on Azure DevOps: infrastructure as code with Terraform, application packaging and deployment with Helm, pipelines standardised across applications.
• FinOps: continuous optimisation of Azure consumption at constant service level — sizing, node architecture, drift tracking.
• Observability: metrics, centralised logging, alerting and dashboards the teams actually use.
• Security and compliance: cluster hardening, RBAC, secret management, audit preparation and follow-through.
• Operating the platform's databases, relational and NoSQL: availability, backups, monitoring.
• Automating operations, including in-house PowerShell tooling that replaces recurring manual work on infrastructure and applications.
Azure · AKS · Kubernetes · Azure DevOps · Terraform · Helm · PowerShell · Prometheus · Grafana · Linux
Bedrock is the technology arm of the M6 Group — the streaming platforms 6play, Salto and Videoland. My job was to build the large-scale load-testing capability, and to run it through to production.
• Designing the load-testing platform: technology and target architecture chosen with the Dev, Infra and DevOps teams.
• Modelling realistic test scenarios from actual usage, then industrialising their execution.
• Running campaigns of up to several million concurrent virtual users on AWS, with Artillery Pro and AWS Fargate.
• Feeding results back to the product and infrastructure teams and following the optimisations through.
• Building AWS Lambda functions for monitoring and alerting on the client-facing critical APIs.
• Day-to-day operations alongside the Dev, DevOps and Infra teams: incident resolution, infrastructure and application upgrades, deployment automation for new components.
AWS (EKS, Fargate, Lambda) · Kubernetes · Terraform · Artillery Pro · GitHub Enterprise · GitHub Actions · Prometheus · Grafana · New Relic
Deploying Orange's telecom services across the MEA region, and industrialising the Lab's DevOps practice.
Product deployment and support
• Installing the product for Orange's new MEA subsidiaries, and version upgrades for existing ones.
• Technical and application support for clients, plus contributions to optimisation work and new features alongside the development team.
Cloud migration and orchestration
• Containerising and orchestrating a production Orange project to guarantee its availability.
• Benchmarking a self-managed Kubernetes cluster (KubeSpray) against Red Hat OpenShift, then implementing the platform we retained.
• Automating integration, test, build and deployment.
"Try & Learn" — a DevOps e-learning platform
• Designing and operating a platform of interactive labs for real-time practice, as micro-services on Kubernetes.
• Building an in-house SDK that launches and manages Docker containers through an API, plus the admin, learner and trainer interfaces in Node.js and Angular.
• Auto-scaling and service checks for availability, configuration through configMaps, secrets for sensitive data, Swagger documentation.
Internal DevOps community
• Leading the Lab's DevOps community: migrating internal projects to DevOps, running upskilling workshops, sharing practice with Orange's other innovation Labs.
OpenStack · Flexible Engine · VMware · Azure · Docker · Kubernetes · OpenShift · KubeSpray · Ansible · Terraform · GitLab CI · RHEL / CentOS / Ubuntu · Shell · Python · Node.js · Angular · ELK · Prometheus · Grafana
Final-year internship, continued as a full-time role on the same scope: joining the Lab's DevOps team and taking on its toolchain — GitLab CI, Ansible, Terraform, OpenStack. Project detail is under the role above.
Product engineering, and taking e-commerce startups through their move to DevOps.
Afflo — a dynamic e-commerce site generation platform
• Developing the platform's micro-services.
• Unit and functional testing to guarantee code quality and integrity before release.
• Deploying the micro-services across Dev, Staging and Production, hosted on an AKS cluster on Azure.
Partner startups
• Migrating their projects to DevOps within an agile team, from design through to production.
• Building the automation pipelines they asked for: compilation, build, tests.
• Deploying across environments — Kubernetes or Docker Compose depending on context.
• Training their developers, writing the documentation and supporting adoption.
Azure (AKS) · OVH · DigitalOcean · Docker · Kubernetes · GitLab CI · GitHub Actions · Bitbucket · Node.js · JavaScript · MochaJS · Shell · Ubuntu · ELK · Prometheus · Grafana
Building a training website on a serverless architecture on AWS.
• Developing the site's interfaces in JavaScript and Angular.
• Building the backend on AWS serverless functions.
• Automating AWS resource deployment with the Serverless framework and AWS pipelines.
AWS · Serverless · JavaScript · Angular · Shell · Ubuntu · GitHub · AWS CodePipeline · AWS CodeDeploy
I've spent eight years on systems that break in front of real users. That shapes every choice I make — I optimise for the day something goes wrong, not for the demo.
Anything done twice by hand becomes a pipeline or a script. Anything that can't be automated gets written down, so the next person doesn't rediscover it under pressure.
FinOps isn't a separate project handed to finance. It's a design constraint, like latency or availability, and it belongs in the architecture conversation.
The best platform nobody uses is a failure. I spend as much time training teams and removing friction as I do building — which is why I became a Microsoft Certified Trainer.
Designing and operating production Kubernetes clusters on Azure and AWS — from cluster architecture and upgrade strategy to the daily run.
Infrastructure as code with Terraform, application packaging with Helm, CI/CD pipelines standardised across applications. Deploying should be a non-event.
Metrics, centralised logging, alerting that fires for good reasons. Cluster hardening, RBAC, secret management, and getting you through the audit.
Understanding the bill, then bringing it down at constant service level. Sizing, node architecture, drift tracking — treated as engineering, not accounting.
Microsoft Certified Trainer. Hands-on sessions on Kubernetes, Azure and DevOps practices for teams that need to own their platform, not just use it.
Evaluating platforms and de-risking migrations — real benchmarks over feature checklists, and moves that don't interrupt the people already depending on the system.
Check Certificate
Check Certificate
Check Certificate
Check Certificate
Context. A production Kubernetes platform on Azure, running the workloads of a company whose cloud spend was growing faster than its traffic. ARM-based nodes offer a materially better price-performance ratio than their x86 equivalents. The question was never whether the gain existed — it was whether we could reach it without anyone noticing.
The constraint. No degradation, no big bang, and a fleet that would stay mixed for as long as the migration took. Which meant every decision had to work for both architectures at once.
What we considered, and set aside. Right-sizing alone would have delivered a fraction of the gain and hit a floor quickly. Reserved instances lock in spend without changing the underlying economics, and they don't help a platform whose shape is still moving. ARM was the option that changed the unit cost rather than the invoice.
What it actually took. The work turned out to sit almost entirely in the build chain, not in the cluster. Images first — anything not built multi-arch stops at the first scheduling attempt, so multi-platform buildx became a mandatory CI step rather than something to add later. Then third-party dependencies: official images almost all follow, community charts and proprietary sidecars follow much less, and that inventory has to happen before the migration. Then native code — anything that compiles native at build time needs verifying. Then scheduling: a mixed amd64/arm64 cluster without nodeSelectors or taints is a lottery, so we tainted the ARM node pools and let workloads come to them explicitly.
What changed. The migration ran on non-critical stateless workloads first, with both architectures live in parallel long enough to compare under real traffic. Nothing moved until it had held up. Beyond the cost gain, the platform came out with a build chain that produces multi-arch by default — a permanent capability, not a one-off migration.
The lesson. The gain is real, but it's earned in the CI pipeline far more than in the cluster.
Context. Bedrock Streaming runs the M6 Group's streaming platforms — 6play, Salto, Videoland. Audiences on a French broadcaster's platform don't arrive gradually; they arrive when a programme starts. My job was to build the capability to know, before that moment, whether the platform would hold.
The constraint. A load test that lies is worse than no load test at all — it produces confidence, and confidence is exactly what fails you at peak. The hard part was never generating load, it was generating load that resembled reality.
What we considered, and set aside. Off-the-shelf SaaS load-testing services are quick to start and expensive to scale to millions of concurrent users, with limited control over scenario shape. We built on Artillery Pro with AWS Fargate instead — more setup, but full control over scenarios and a cost curve that survived the scale we needed.
What it actually took. The technology and target architecture were chosen together with the Dev, Infra and DevOps teams. Scenarios were modelled from real usage patterns, then their execution was industrialised so a campaign became a repeatable step. Campaigns ran up to several million concurrent virtual users on AWS. Alongside, I built AWS Lambda functions for monitoring and alerting on the client-facing critical APIs.
What changed. Results went back to the product and infrastructure teams, and I followed the resulting optimisations through — a load test that produces a graph has failed, one that produces a decision has worked.
The lesson. Scale is the easy half. The difficulty is modelling honestly, and building enough trust in the numbers that teams act on them.
Context. At Orange Labs, an internal project running in production needed to move to containers and orchestration to guarantee its availability. The choice wouldn't only affect that project — it would set the reference other teams reached for next.
The constraint. Availability was the requirement, but the real constraint was durability of the decision. Picking the platform that worked for one project and broke for the next would be worse than picking the slower option.
What we compared. A self-managed Kubernetes cluster built with KubeSpray, against Red Hat OpenShift. The criteria that mattered weren't feature checklists — operational cost over time, the upgrade path, how much the existing team could actually own, and integration with the OpenStack and Flexible Engine estate already in place.
What it actually took. Building a real benchmark rather than a comparison table — running the project on both, and measuring what each cost to operate rather than what each promised. Then implementing the platform we retained, and automating the integration, test, build and deployment work around it.
What changed. The project got its availability. More usefully, the other teams got a documented decision with the reasoning attached, so the next project didn't have to redo the analysis.
The lesson. The output of a platform choice isn't the platform — it's the written argument that lets someone else trust it, or challenge it, two years later.
Context. Orange Labs had an internal DevOps community and a familiar problem: people were being taught DevOps in slide decks. What they needed was somewhere to break things safely, in real time, without waiting for anyone to provision an environment.
The constraint. Labs had to start on demand, stay isolated from each other, and survive dozens of learners hitting them at once — including the ones who would try to break them on purpose.
What it actually took. The platform was built as micro-services on Kubernetes, with separate interfaces for administrators, learners and trainers in Node.js and Angular. The interesting part was the SDK: rather than pre-provisioning environments, I built an in-house SDK that launches and manages Docker containers through an API, so a lab exists only while someone is using it and the platform's cost tracks its actual use. Availability came from auto-scaling and service checks; configuration went through configMaps, sensitive data through secrets, and the API was documented with Swagger.
What changed. The community got somewhere to practise rather than watch. I also ran the workshops around it and shared the practice with Orange's other innovation Labs — the platform and the teaching were the same job.
The lesson. The best argument for a set of practices is letting people use them for twenty minutes. Every hour spent on the platform saved several spent explaining.
I'm open to freelance missions and permanent roles — Île-de-France or remote. If you're running Kubernetes in production and something isn't working the way it should — the platform, the delivery chain, the bill, or the team's confidence in it — that's the conversation I'm interested in.