I’ve seen this emerge a few times:

1. I want a thing
2. Eek – too many things – I need a thing manager
3. I don’t care about things, just do the thing for me

Applying the pattern to Kubernetes:

1. I want a Kubernetes
2. Eek – too many Kubernetes – I need a Kubernetes manager
3. I don’t care about Kubernetes, just run my distributed app for me

If I look at some recent industry announcements:

1. VMware’s next generation of vSphere with Project Pacific will have Kubernetes baked in
2. VMware’s Tanzu is a ‘Mission Control’ for Kubernetes.
3. Google’s Cloud Run is a ‘serverless’ service with Kubernetes underneath, but hiding all the gory details.

I’m not making a value judgement on Google being in some way ahead of VMware here – they’re skating to different pucks being played by different customers; because technology diffusion curves.

Mapping to ‘design for…’

When I talk about DevOps I usually talk about the shift from design for purpose, to design for manufacture, to design for operations. I can see some broad, but imprecise alignment between those three stages and these.

Needs change

Pat Kerpan first brought this to my attention with his observations from Cohesive Networks:

1. I need an overlay network (and I must manage it myself, because part of my whole threat model is that I don’t want to entirely trust the underlying cloud service provider)
2. Eek – too many networks to manage, give me a manager of managers (Cohesive created ‘Mothership’, now VNS3:ms)
3. I don’t want to manage my own networks any more, just run them for me as a service

NB that at stage 3 the control requirement that was present at stage 1 has evaporated.

Pat also observed that shifts from one stage to the next normally coincided with people changes at the customers. The engineers who bought a technical solution at 1 gave way to managers who needed to scale at 2 gave way to new managers who just wanted simplicity at 3.