Is “Cloud Native” just another buzzword or does it actually mean something? This is a question I asked myself, I wanted to understand what it meant from a technical prospective so thought i’d share my thoughts via a blog post…
It seems that “cloud native” is difficult to describe succinctly and it means different things to different people depending on their role. A developer will talk about an app following the principles described in the 12-factor app, an operations manager will often use the ‘Pets vs Cattle’ analogy to help explain what cloud native means to them and a CIO will talk about agility or describe the properties of a cloud native app such as scalability, portable, resilient etc… Even if you Google “Define: Cloud Native” it brings no official definition!
It is obviously a combination of the above, but if I were to take a step back, at a very basic level I would say that for an application to be cloud native there is a need for
A clear separation between the application and the infrastructure on which it runs
- Recover from failure without human intervention
- Seamlessly move your app onto a different IaaS provider?
- Can you change a backing service without changing your app code?
- Release new features multiple times a day?
- Easily scale your app?
Often traditional monolithic applications are tightly coupled with the infrastructure on which it runs on meaning that if a VM crashes then so does the application. A cloud native application is “ready” for infrastructure to fail – but how is this possible? It requires applications to be built in a specific way, some examples include
- Apps should never assume dependencies will already be in place i.e. when an app is deployed everything that is required to run the app should be either deployed with it or connected to on startup
- App processes should be disposable so in the event of a failure or requirement to scale the app will gracefully restart and quickly restart
- Externalise all configuration, this means read configuration variables (for example URLs, ports, usernames, passwords etc) at runtime. Code to use config won’t change, it will just use a different parameter so read this at runtime to prevent code changes between environments.
- All services (e.g. databases, messaging systems etc) should all be treated in exactly the same way so in the event of needing to change one (e.g. replace a local MySQL with one running in the cloud) the app will continue to operate in exactly the same way but just using a new config that has been provided
These are some examples of the 12-factor app (there’s more so check out the site) that I referenced above, but it’s not just about an application having the right attributes to run within a cloud environment, obviously this is critical but you also need the environment around it in order to maximize the benefits.
Cloud native encompasses people, process and technology – to enable a cloud native “approach” you should consider continuous delivery (i.e. always having a deployable piece of software – you may not choose to continuously deploy it but you have something you COULD deploy at any time), this is generally enabled by taking a cultural shift (…ready for another buzzword !) by implementing or adopting “DevOps methodologies” and in order for this to be truly successful a microservices architecture is needed. This breaks down large enterprise applications into small pieces of functionality (bringing many benefits including easier to deploy, scale, update, easier for new dev’s to get on-board, adds resiliency and more!) and it’s containers that underpin this architecture.
So in my opinion the concept of cloud native encompasses many attributes and requires a fundamental shift not just in how applications are written but also how teams are structured, what tools are available and what policies / procedures are in place and how these are evolving to match new technology capabilities.