In the Cloud Done Right webinar I hosted last year, the concept of cloud-native cropped up.
So what? you might think.
Well, it came as some surprise that my co-presenters and I had different takes on what cloud-native means. Considering it’s a term that we use day-in-day-out, we should really have a shared understanding of it. Yet frustratingly, we couldn’t find a consistent definition anywhere.
More recently, I’ve had the pleasure of working with Kamal Arora from Amazon Web Services to co-author a blog about cloud-native in practice. His book Cloud Native Architectures eschews a cut-and-dried definition in favour of a model portraying cloud-native as an evolving state. It’s an interesting way to depict cloud-native, and probably the best method I’ve come across to date.
So, with Kamal’s permission, I’m sharing the model here. If you like it as much as I think you will, you can find his book on Amazon and explore it in more detail.
Where the journey began, and why it matters
Before I get into the model, it’s worth considering why you should care.
2018 Accelerate: State of DevOps (run by DORA and sponsored by every big name in the industry) includes some important findings about the cloud. It reveals a predictive link between the way organisations implement cloud infrastructures and high-performance IT. This is important, because IT’s highest performers are over 1.5x more likely to exceed goals for growth, profitability and market share. Get cloud right, and your business wins.
DORA’s research shows the link between cloud and high-performance is underpinned by the five essential characteristics of cloud computing defined by the National Institute of Standards in Technology in 2011. Eight years on, this seems like a pretty basic list. Any hyperscale provider easily ticks all the boxes now. But it’s often the case that not all capabilities are made available to product or delivery teams building systems in the cloud. They’re blocked by legacy processes put in place to protect the business. However, teams that do use these capabilities are a staggering 23x more likely to be in the ‘elite performance’ group defined by DORA. As such, they have a better chance of exceeding organisational goals.
Surprisingly, being cloud-native was only found to have a 1.8x predictive link to elite performance. But this brings us back to the absence of a consistent industry-wide definition. DORA refers to a cloud-native service or application as one which was ‘originally designed to run in the cloud’. This is a fair interpretation. But it sets the bar low, when cloud-native can be so much more.
That’s where my quest to discover what cloud-native really means began.
What’s so great about Kamal’s definition?
Instead of putting a restrictive definition on cloud-native, Kamal (and team) describe a maturity model. This is way more useful, because it means you can start thinking about cloud-native as a journey: you decide when to start, then keep on going. As you put more work put into progressing the journey, you go further and unlock more benefits.
The model doesn’t preclude existing applications being migrated to the cloud or rewritten after a migration. It doesn’t even exclude vendor-built applications (although they’ll have limited potential without the vendor doing some work). Most importantly, it emphasises the ongoing nature of the cloud-native journey. As platform services and architectural practices continue evolving, so too can the model.
The Cloud Native Maturity Model
The model’s triple-axis design represents ‘cloud-native services’, ‘application-centric design’ and ‘automation’ as fundamental, interconnected components. Their degree of sophistication influences the relative maturity of a given system.
Clearly, being cloud-native demands the adoption of cloud services. But the nature of these and the way they’re incorporated, from basic building blocks like Amazon EC2 and S3 to advanced services like AWS Lambda, has an impact.
When it comes to design or migration patterns, the model takes an application-led approach. Instead of working from the ground up, the starting point is an application’s long-term role and requirements. Design decisions are then shaped by factors such as operability, the balance of stateful / statelessness and the use of microservices. This ensures decision-making accommodates the need for continual evolution.
While cloud services and application-centric design are vital, they don’t cover all bases. Lasting security and scalability rely on operational automation, which in turn requires Infrastructure as Code. Operational automation enables internal teams to focus on application-specific design, while the cloud vendor handles the undifferentiated heavy lifting of resource deployment.
There is a spectrum to automation. Early phases focus on environment buildout, resource configuration and application deployments. As a solution matures, it evolves to include more advanced monitoring, scaling and performance. In time, this goes further to encompass auditing, compliance, governance and optimisation of the full solution.
Is it worth it?
It would be naïve to think that every application merits a full cloud-native rewrite. But there’s a lot to be said for applying this model to applications that have a bearing on core value-creation.
Returning to DORA’s findings, the strongest link between high-performance IT and cloud sits with NIST’s five essential characteristics. If the people building application functionality can’t tick all five of those boxes, you will need to address organisational constraints before giving too much attention to technology.
This is a vast and complex subject. But once you establish the organisational capability to leverage cloud technologies at scale, Kamal’s model provides a very useful framework to understand the dynamics of your cloud-native journey.