Cloud Native is Nice and All, but How Do We Get There?

And you may ask yourself
What is that beautiful house?
And you may ask yourself
Where does that highway go to?
And you may ask yourself
Am I right?…Am I wrong?
And you may say to yourself yourself
My God!…What have I done?!
– Once in a Lifetime, Talking Heads 1980

We spend a lot of time in this industry chasing the bright and shiny, hoping for a silver bullet we can buy to transform ourselves into digital paragons. But the truth is, IT is hard. Change is Hard. Change is about people. One of the latest buzzwords doing the rounds is Cloud Native. Some smart people have taken a stab at defining it.

“There is a rough consensus on many Cloud Native traits. Containers as an atomic unit, for example. Micro-services as the means of both construction and communication. Platform independence. Multiple language support. Automation as a feature of everything from build to deployment. High uptime. Ephemeral infrastructure (cattle not pets). And so on.

Bigger picture, the pattern Cloud Native platforms have in common is that they are a further abstraction. Individual compute instances are subsumed into a larger, virtual whole, what has been referred to here as a fabric.”

Or

“Cloud Native is about unifying a new generation of tools under a single brand.

The industry will undergo accelerated change if end users and vendors can rally around a simple concept. In the 1990s that concept was “The Web” – remember when every business realised it needed a web site? More recently, “The Cloud” and “Big Data” have played a similar role for changes in on demand compute and data analysis respectively. And so Cloud Native is a way to describe a revolution in which businesses make applications central.”

But as per the Talking Heads lyric above, often times it’s the journey rather than the destination that is so important. Just how do we get there, or how will we get there? After all, as I have said change is hard, hard enough to threaten more than one multibillion dollar industries.

The Cloud Foundry community was the first to really aggressively adopt Cloud Native as a rallying cry, so it shouldn’t surprise there is some maturity in thinking emerging from the community. And with maturity it seems, comes maturity models. This morning James Watters of Pivotal shared this chart.

https://twitter.com/wattersjames/status/664044293250641920

I really like that a financial services company is not asking what they can buy to make everything ok, but rather what’s the journey they need to undertake in order to make a digital transformation. Interestingly the model maps pretty well to our current move up the stack from Infrastructure as a Service (IaaS) to Platform As A Service (IaaS).

Terms like Design For Failure are pretty scary for traditional IT shops, but without designing for failure you set yourself up to fail. Distributed systems break, so deal with it. Web companies expect things to break, and design accordingly. Netflix for example has open sourced a toolset called Chaos Monkey that break things on purpose to force a mode upon you. Cloud Native is about learning from the web though. This is the kind of somewhat counterintuitive thinking we need to embrace on the road to Cloud Native.

I’d be interested to know what you think of the model above. Feedback would be very welcome.