It is really is hard to ignore the mass migration to cloud computing. Today, over 50% of US enterprises are utilizing the public cloud to some degree, and this trend is set to accelerate, with Infrastructure as a Service (IaaS) growth at 40%. It seems that all enterprises are reinventing themselves through “digital transformation.” The low cost and easy setup have enabled companies to focus on differentiating their business, rather than setting up infrastructure. We are now at the point where organizations across every industry are looking to stay competitive by introducing bimodal IT strategies, where the need to run the business (mode 1) has to coexist with the fast-changing and innovative initiatives (mode 2). Mode 2 is based on best practices that have been gleaned from companies such as Facebook, Netflix and Twitter, and are using continuous delivery, immutable containers and microservices to help achieve the elastic scaling capabilities needed to cater for an unpredictable competitive landscape. The sense of urgency is palpable: adapt, and adapt quickly or die.
So how do you go about transforming your software architecture to take advantage of cloud computing? Netflix is a great example of a successful transition to using public cloud (AWS) to help transform their business. Yury Irrailevsky, VP of cloud and platform engineering at Netflix, wrote a great blog post about this in 2016 when Netflix had completed their cloud transition.
The driver for Netflix was resilience, having just had a massive database corruption which prevented them from doing business for three days. They looked in earnest to adopt a new architecture that could utilize the horizontal scaling capabilities of a public cloud.
The term “cloud native” first started appearing in presentations at conferences around 2010. Netflix was one of the first to use the phrase to describe the concepts required to migrate existing data center-based applications to cloud environments. As architects and engineers looked to take advantage of the cloud, the concepts behind cloud environments evolved too - but three remain fundamental:
Resilience - You cannot assume that machines you deploy to, or the network you use are going to be permanent - they can and will disappear - and your applications may not get any warning to allow for a graceful shutdown. This means you have to architect for failure and assume that any services you interact with could disappear at any given time.
Discovery - Any services your applications interact with need to be found, usually from a runtime registry.
Scalability - You might be able to deploy your applications to the cloud, but they will not be cloud native if they cannot take advantage of one of the key benefits of the cloud - horizontal scalability.
As the software and architecture evolved, so has the core concepts that define what cloud native means today. The Cloud Native Computing Foundation defines the core concepts for cloud native to be the following:
Container Packaged - A standard way to package your applications, that is resource efficient - you can densely pack more of your applications if you use a standard container format - this excellent Codeship blog, explains why .
Dynamically Orchestrated - You need a standard way to discover, deploy, scale up and scale down your containerized applications. There used to be a few different orchestration platforms competing, but now there is one which is the clear leader , being adopted by all the major public clouds: Kubernetes . A later blog post will go into detail about why Kubernetes changed everything.
Microservices-Oriented - To take advantage of cloud environments, and leverage horizontal scalability, you really need to decompose your application into modular, independent services that interact through well-defined service contracts.
We have defined what cloud native is, but to take full advantage of deploying to the cloud and giving your business the agility it needs to compete, you need to be thinking about a continuous delivery solution that is Kubernetes native. We will be talking about that in a later blog, too.
Rob Davies
CloudBees