Why a Cloud Native Application Platform

July 05, 2019

The last 18 months technology teams from investment banks to start-ups in garages, know that Kubernetes is the answer to innovation. The CNCF is expanding rapidly, both sponsors and projects, Kubecon is doubling every six months, and forum and meetup attendance is through the roof. Read Steve George's take on why Kubernetes is everywhere.

Related posts

GigaOm - Voices in DevOps with Steve George

Kubernetes - The Fast and Furious?

The Journey to Kubernetes

Mostly we live in our own heads, but every so often it's valuable to be jolted out of your reality. Chatting to an industry observer yesterday he asked:

"I see Kubernetes everywhere, but why?"

The sentiment "Kubernetes everywhere" feels right, and it's not just in my own head! In the last 18 months technology teams everywhere, from large investment banks through to start-ups in garages, know that Kubernetes is the answer. The CNCF is expanding rapidly, both sponsors and projects, Kubecon is doubling every six months, and forum and meetup attendance is through the roof. I no longer explain the what or the why of cloud native to prospective tech teams since they just sit there waiting for me to get the point - it's a given.

Great, but why?

In one sentence - we need a new application platform because cloud native application development is revolutionising how teams develop and run software. Today vast numbers of applications being written are using containers and microservices. In fact, if you were starting on a Web application today you'd have to ask why not Cloud Native. This is an industry wide change that will be as big as the move to virtualization.The super trend is that Cloud Native applications bring together a set of patterns such as microservices and DevOps/SRE that impact the environment needed to run them. It follows then that the 'platform' is a new runtime and environment for operating cloud native applications reliably, securely and at scale.

Kubernetes is the defacto choice for orchestration, but an environment is far more than this - we can say that Kubernetes is the kernel of this platform, but not the entirety as we move to a new model of abstraction. We've had platforms before but with Kubernetes we're really talking about a complete runtime as the abstraction is a complete distributed system.

Great, but why are teams moving to cloud native development?

There have been a long-running set of changes in the development and operations system designed to drive speed and agility, without sacrificing reliability or security. At heart these remove the idea of separate phases of 'development' and 'operating' for a continuous loop of incremental improvement. This in-turn is driven by the fact that for many teams continuously running and improving their services is the reality. Contemporary practises apply agile and distributed to reduce interconnectedness and complexity. In summary, they are about reducing the development-deployment cycle time and increasing developer productivity.

Alright, but why are technology teams trying to reduce the cycle and increase developer productivity?

The first is easy to understand, for a while we've known that every company is a software company. As this has happened, it's put new focus on the speed with which we can deliver new features into the hands of users: our market agility is defined by our technology agility. Being able to continuously deploy new features is a market advantage: that's why it's an area that we've focused on at Weaveworks.

The second is that the focus area for productivity has steadily shifted to development rather than operations. Previously, it made sense to spend human cost reducing the technology cost of operations: swathes of system administrators spent their time reducing the cost of operating bandwidth and servers. Now for most teams the cost and limitation have switched to the development side, quite simply it's better to spend money to make your development teams more productive. Developers themselves are a scarce resource and optimising the process and the environment to account for this is a valuable use of money.

The second reason is developer hiring and retention. Every survey that asks CTO's about their worries will tell you about the importance of hard metrics like cost - that's what they report to their boards. But, talk to CTO's at any length and you'll discover that their number one long-term pain is hiring and retaining developers: you can't build without builders. Providing development teams with a great developer experience is an important part of retention when they're constantly being recruited. That means tooling that helps to focus on solving interesting problems and removing friction so they feel productive and empowered.

There you have it, the big leap forward is that cloud native applications increase business agility and speed. This will require a new platform and we're in the midst of determining what that runtime platform will look like.


Related posts

GigaOm - Voices in DevOps with Steve George

Kubernetes - The Fast and Furious?

The Journey to Kubernetes

Find out more and download: 6 Reasons to Start the Cloud Native Transition