Clouds. Love or hate them, but they are here to stay. Private, Public, Hybrid, Multi-Cloud. So many buzz words abound in this particular technology space that you could have two games of bingo going at the same time and still have concepts to spare. IaaS, PaaS, SaaS, DRaaS, DaaS, in fact, more aaS’s than you can see at a donkey sanctuary. The latest buzzword is Cloud-native. But what is Cloud-native?
In this article, we will attempt to answer what at first glance appears to be a simple question, what is Cloud-native?
As a starting point, we will look at the official definition of Cloud-native by those you would think should know exactly what it, is the CNCF, the Cloud-native Computing Foundation. And of course, cloud-native is becoming mainstream (according to them).
Cloud-native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact
Well, there is a suitable amount of fluff in that statement to say anything to everyone, or more to the point more wiggle room than when you wave a matchstick in the Albert Hall.
If you are a virtual-machine-based vendor your version of Cloud-native will mean AMIs ARMs or Google Images to deploy your VM’s. If your applications run on containers, then Docker images and Kubernetes will define your Cloud-Native stance and so we go on further up the stack and down into Functions and serverless.
The fact is you can go down so many rabbit holes with the concept of Cloud-Native, but at its core, it is about agility and speed. It is about how quickly you can get your application to market and in front of your users to enable it to start creating the value that your investment was supposed to deliver on.
The crux of Cloud-Native is Business Value.
So for we have looked at whether Cloud-native is IaaS or ?aaS, it is not, nor is it Containers or Kubernetes. Being born in the cloud although an indicator of Cloud-Native, is not a unique identifier, it is a method of creating Applications that are both Agile (quick to be deployed) to increase the business value derived from the development and implementation time. Yes, that is correct the concept of Cloud-Native is once again a procedural matter, and its meaning has been hijacked by vendors trying to sell manna from heaven again.
Many people will think of cloud-native as Netflix, Facebook, Google, Uber, etc. They will be correct. They are born in and off the cloud. All their applications run in an agile manner, they deploy new versions at a whim, can scale or collapse at need, can survive outages at scale from a single process to a full region outage without service interruption (yes there are exceptions, but there will be only a single exception as the root cause of the outage will be investigated and the failure identified and engineered out).
These companies have built their business around the concepts of Cloud-native. These are Agility, Speed Scale, and Resilience.
I have legacy environments, am I cloud-native?
The short answer to that question is yes you can, the long answer is as follows. Cloud-native is about Agility, Speed, Scale, and Resilience. So how would you go about designing a Cloud-native application? The concepts of Cloud-native applications and DevOps are joined at the hip.
Pets vs Cattle is a very good primary design decision. Most people understand this concept now, traditional locally installed legacy applications were installed on physical or virtual machines, wrapped in cotton wool and nurtures, being patched, and monitored for issues, triaged, and nursed back to health. Given nice names and are Stateful. effectively treated as a favorite pet, modern cloud-based applications are treated more like cattle on a farm. Failing or sick instances are culled and replaced by a new instance to maintain the health of the herd this is easy because they are stateless not loved and seen from an industrial level rather than a personal level.
Cloud-Native as a process very much like DevOps has redefined the way applications are designed and delivered and a widely accepted method for constructing Cloud-native applications is called the 12-factor app. 12-factor is quite an old concept but the tenets still hold true today.
The following table highlights the Twelve-Factor methodology:
| Factor | Explanation | |
| 1 | Codebase | Maintain a single code base for each service or module, which is stored in its own repository and tracked under version control, this can then be deployed to multiple environments (QA, Staging, Production). |
| 2 | Dependencies | Each service will be isolated and packaged with its own dependencies, this enables a change to be made to individual services without impacting the entire system. |
| 3 | Configurations | All configuration information is moved out of the service and managed through a configuration management tool or process outside of the core code. This will enable the same deployment to be propagated across multiple environments with the relevant correct configuration applied. |
| 4 | Backing Services | All ancillary resources for example data stores, caches, or message brokers should be exposed via an addressable URL. This will enable the decoupling of the resource from the application thereby creating a stateless application layer enabling it to be interchangeable. |
| 5 | Build, Release, Run | Each release iteration must enforce a strict separation across the build, release, and run stages. They should be tagged with a unique identifier and support the ability to roll back. |
| 6 | Processes | Each service should execute in its own individual process and be isolated from other running services and any required state is externalized to a backing service such as a distributed cache or data store. |
| 7 | Port Binding | Each microservice should be self-contained with its interfaces and functionality exposed on its own individual port. This enhances the mantra for isolation from other microservices. |
| 8 | Concurrency | All Services should scale out across many small identical processes (Horizontally) as opposed to scaling up to a single large instance on the most powerful machine available (Vertically). |
| 9 | Disposability | Every Service instance should be disposable, leaning toward a fast start-up to increase scalability and a graceful shutdown to leave the system in a correct state. |
| 10 | Dev/Prod Parity | Keep your environments as similar as possible across the development lifecycle, Infrastructure as Code and Containerization are your friends here. |
| 11 | Logging | any logs generated by services are treated as an event stream. They should be processed using an event aggregator and the resultant data propagated to a data-mining or log management tool and eventually on to long-term archival. |
| 12 | Admin Processes | Run administrative/management tasks as one-off processes. Tasks can include data clean-up and pulling analytics for a report. Tools executing these tasks should be invoked from the production environment, but separately from the application. |
These original 12 factors have been expanded to 15 by Kevin Hoffman in his book Beyond the 12 Factor App. Which can be downloaded from the VMware site here:
| Â | New Factor | Explanation |
| 13 | API First | Everything should be a service. Your working assumption is that code will be consumed by a front-end client, gateway, or another service. |
| 14 | Telemetry | When you are working on a workstation, you have visibility into your application and its behaviour. In the cloud, you cannot guarantee the same level of access. Make sure your design includes the collection of monitoring, domain-specific, and health/system data. |
| 15 | Authentication/ Authorization | Implement identity from the start. Consider RBAC (role-based access control) features available in public clouds. For example IAM in AWS |
So it is with these 15 concepts in mind that we can start to define cloud-native and so finally we come to answer our original question What is Cloud-Native?
Summary
To summarize, Cloud-Native is a methodology of designing an application that works at scale, it has the capability to be self-healing. Cloud-Native applications are defined by being modular, stateless, and driven by an API first mentality, deployment is driven by DevOps principles with infrastructure as Code and application configuration managed by a configuration manager through an infinity loop development cycle. Oh, and did I say the applications are stateless.
