Convergence to Kubernetes

Standardisation to Scale

I asked our CTO, as part of preparing this content for a conference presentation, about what he thought was interesting about our use of Kubernetes and he replied:

Teams don’t realise how much they haven’t had to do.

His comment was inspired from having recently read Factfulness : it’s harder to notice smaller but continual improvements and we consequently fail to recognise the progress we’ve made.

Our move to Kubernetes is significant though.

We have close to 30 teams that run some or all of their workloads on our clusters. Approximately 70% of all HTTP traffic we serve is generated from applications within our Kubernetes clusters. It’s probably the single largest convergence of technology since I joined (as a result of uSwitch’s acquisition by Forward ) in 2010 when we moved from .NET and physical servers to AWS, and from a monolithic system to micro-services .

It’s been one of the quickest changes I’ve seen. In late 2017 all teams ran all their own AWS infrastructure. They were responsible for configuring load-balancers, EC2 instances, ECS cluster upgrades and more. In a little over a year that’s changed for all teams.

Kubernetes has been so useful, and our convergence so fast, because it helped overcome a real organisational problem: the ever growing cloud and organisational complexity, and the difficulties of scaling teams. We didn’t change our organisation because we wanted to use Kubernetes, we used Kubernetes because we wanted to change our organisation.

Engineering staff may not recognise the change but our data does. More on that in a bit.