I'm Firas Chbiki

Moving a production AKS fleet to arm64

Context. A production Kubernetes platform on Azure, running the workloads of a company whose cloud spend was growing faster than its traffic. ARM nodes offered a real price-performance win — the question was reaching it without anyone noticing.

The constraint. No degradation, no big bang, and a fleet that stayed mixed for as long as the migration took, so every decision had to work for both architectures at once.

What it actually took. Right-sizing and reserved instances were considered and dropped — neither changed the underlying unit cost the way ARM did. The real work sat in the build chain, not the cluster: multi-arch images became a mandatory CI step, dependencies and native code were inventoried before the migration rather than during it, and mixed-architecture scheduling was made explicit with taints rather than left to chance.

What changed. The migration ran on non-critical stateless workloads first, both architectures live in parallel long enough to compare under real traffic, nothing moved until it had held up. The platform came out of it with a build chain that produces multi-arch by default.

The lesson. The gain is real, but it's earned in the CI pipeline far more than in the cluster.

Retiring an archived MongoDB operator across a live fleet

Context. A fleet of MongoDB replica sets on AKS was running on an archived, unmaintained operator. Years of manual changes had left each environment differently broken — some "replica sets" were single instances with no failover, disks sat on whatever storage class had been the default, and the server was frozen on an old major version. None of it could go offline to fix.

The constraint. The supported operator can adopt an existing resource without a dump-and-restore, so the swap itself was a control-plane handover, not a data migration. Everything after that was real change on a live system — growing a single instance into a genuine replica set, moving its data, and climbing several major versions member by member without losing quorum.

What it actually took. The first environment crash-looped on a hardcoded future version in its config; fixing the version exposed a second failure where that member's disk had been half-corrupted by the earlier attempt. I wiped just that disk, resynced it from a healthy peer, and hashed every collection across nodes before trusting it. That incident meant nothing in the next environment's config went unchecked against the live cluster either — which is exactly what caught a provisioning file claiming a 30Gi disk where the real one was 500Gi, before the migration script ever ran.

What changed. Both environments finished on the supported operator, running a current MongoDB release as a genuine multi-node replica set on proper storage. The rest of the fleet now inherits migration tooling that's already had its sharp edges found twice.

The lesson. Configuration that's been correct for years stops being trustworthy the moment automation starts acting on it.

Building a self-hosted cloud-ops platform on PowerShell alone

Context. A large organisation's internal Azure estate — dozens of SQL Servers, Kubernetes split across AKS and k3s, Key Vaults and VMs across dev, pre-prod and production — needed governance and self-service tooling that matched how the operations team actually worked, not a rip-and-replace.

The constraint. The real constraint was institutional, not technical: the team's deepest fluency was in PowerShell, not Python or Terraform. Any new platform had to stay something they could read, extend and debug themselves, while still delivering a browser UI, governed access to production databases, and a move off shared passwords.

What it actually took. Azure Automation and a commercial cloud-management platform were both tried and dropped — one had no real UI story, the other meant vendor lock-in and someone else's workflow. So I built the platform up instead: a lightweight, PowerShell-native web framework, one script per browser tab sharing a common library for Azure, SQL and Key Vault access, became two internal portals. The flagship piece was an AI assistant wired in through a governed MCP server, so non-technical staff can ask plain-English questions about cloud spend instead of writing SQL — backed by a homegrown scheduler and a managed-identity agent for distributed task execution.

What changed. Routine Azure work — tagging, access audits, moving databases into elastic pools — moved from raw CLI commands run by whoever held the credentials to a self-service workflow safe enough for less-senior staff. Database auth moved from passwords to managed identities, closing a real security gap.

The lesson. Modernising an internal platform doesn't require abandoning the stack a team already knows well.

An Ansible platform for PostgreSQL on Azure — and pricing what runs on it

Context. PostgreSQL was being run by hand on Azure Ubuntu VMs — every install, upgrade and disk change a manual sequence, done slightly differently each time. Nothing enforced idempotency, disk paths weren't stable across reboots, and a bad version upgrade had no way back. It needed to become a platform, not a habit.

The constraint. Every operation had to be idempotent — a second run against a converged host reports zero changes — and nothing could ever touch a data or backup directory destructively. Azure adds its own trap: disk device names shift across reboots, so anything addressed by raw path is an outage waiting to happen.

What it actually took. One lifecycle operation at a time — install, upgrade, add-replica, extend-disk, backup, monitoring, security — each idempotent and safe to re-run on its own. The heaviest piece was the major-version upgrade: staged on an external disk, stale-cluster detection so a half-finished upgrade is never mistaken for a clean one, and a rollback validated against deterministic test data rather than checked by eye. Disks are addressed by LUN-persistent path and mounted by UUID, so a reboot can't silently remount the wrong one.

What changed. A manual runbook became a set of modular playbooks that install, upgrade, back up and monitor a PostgreSQL fleet with no human in the loop for the routine cases. Monitoring became a cost signal too: per-database Prometheus metrics feed a Grafana view and a PowerShell tool that turns raw usage into a per-database cost share — output as a formula rather than a fixed price, so it runs unattended on a monthly cron and whoever holds the invoice applies the numbers.

The lesson. Automating a stateful system is mostly about the failure paths, not the happy path — the upgrade nobody trusts is the one without a tested rollback.

Load-testing a streaming platform at millions of concurrent users

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.

Self-managed Kubernetes or OpenShift: choosing an orchestration standard

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.

"Try & Learn": an interactive DevOps lab platform

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.