What is Cloud Native ?
Answering this question is important as everyone talks about Cloud Native but very few are aware of all the attributes of Cloud Native applications and architecture.
For example, many associate cloud native to the use of the containers only. which is not correct. As there are other attributes that also an important part of cloud native software architecture, so just the use of containers does not qualify an application to be cloud native.
Then there is a common misconception that containers and microservices are one and the same thing. which is not true.
Hence, this article aims to clarify all these concepts related to cloud native in a simple and easy manner.
It is important to know these attributes as all the future IT and Telco applications that are supposed to run in cloud are being evolved to cloud native software architecture.
When it comes to the Telco industry, it is a big paradigm shift. NFV was originally developed with VNF in mind which is one large piece of monolithic software on a virtual machine, whereby the latest trend is the transition to cloud native CNFs which are lightweight, agile, and containerized. Therefore it is important to know about cloud native in general.
And who else is better to look for definition of cloud native than the CNCF body ( Cloud Native Computing Foundation).
Here I have made the text bold which are the necessary components of cloud native and moving forward we define them one by one.
Cloud Native Definition according to CNCF
“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 changes frequently and predictably with minimal toil“
I made the important attributes are made bold here and converted them to seven major attributes for easy reference so that you know , what is cloud Native
What is Cloud Native? The Seven Attributes
Virtual Machines are good. But containers are better.
VMs let you isolate applications from each other on the same server without the need to buy a server for each application. However this comes with one caveat- each VM uses a lot of system resources.
This is because it makes a virtual copy of everything including the operating system. Think of it as running one Linux instance ( Operating system for VM) on another Linux instance ( host operating system).
And when one starts adding VMs in cloud, the solution becomes expensive.
On the other hand, multiple containers can share the same host operating system ( Linux kernel). This makes containers lightweight, portable and fast to start up. This makes them very stuitable to be deployed in cloud and hence the name cloud native.
One famous and most popular container example is Docker.
A microservice is a way to build applications as small pieces of software.
Today’s applications are big monolithic pieces of software For example think of it as an EPC (Evolve packet core) made as one big monolithic application. It is difficult to upgrade the software of such an application considering the software pieces are tied together as one big piece and with so many moving parts, it is a complex task to evolve and upgrade the software of such application by the developers.
On the other hand microservices work as small applications ( each called a microservice) that are loosely coupled. This creates a pluggable application architecture. each microservice communicate with each other through REST APIs.
Each microservice can evolve independently, has autonomous life cycle. There is no need to wait for quarterly releases to be deployed. upgrades can be rolled out quickly. Each microservice can scale on its own without waiting for the other services to scale. This is the true essence of being a cloud based application.
Are microservices and containers one and the same thing ?
You don’t need a container to run a microservice. Instead, you may run each microservice in a separate virtual machine. But would that be an efficient solution ?
Each VM has assoicated overhead of an indpendent operating system. This makes it inefficient and very heavy to run many microservices in multiple VMs.
On the other hand a container is much suitable to run a microservice i.e one microservice per container.
That is the reason that when we say a microservice, we usually mean the containers and vice versa.
Docker create images and run containers.
However when talk about hundred and thousands of containers, we need a good management tool.
This is done with a special program called container orchestrator or simply an orchestration tool.
No environment can be truly cloud native without an efficient orchestration tool. Of late, Kubernetes has become a def-facto standard for containers orchestration.
Orchestration tools deploy, operate and scale hundreds and thousands of containers and thus responsible for life cycle management of containers.
4. Continuous Integration/Continuous Delivery ( CI/CD)
CI/CD ( also sometimes refered as Devops) is an essential part cloud native architecture.
The whole concept of microservices is having software agility and CI/CD can achieve that objective efficiently.
CI/CD is set of tools and practices that support accelerating software development cycles. CI/CD tools automate stages of the software release cycle. Small incremental changes are made to applications.
Then there is a process of continuously integrating and testing these changes in small increments.
As each microservice can be evolved and upgraded separately than other microservices, there is a less risk of rolling out upgrades to the network continuously. This is called continuous integration and continuous delivery of new code and hence brings software agility.
5. Declarative APIs
Microservices communicate through APIs. There are two kind of APIs
- Imperative APIs
- Declarative APIs
Imperative APIs tell the system on the exact steps of how to perform an operation. Declerative APIs just leave an intent or wish on what it is expecting from the system and leaves it to the system on how to perform it.
A good example would be if I tell someone to cut the grass in the garden and then tell him the exact steps, tools etc on how to cut the grass ( imperative API)
I just tell him to cut the grass and leave it to him to follow his way ( Declarative API)
The modern applications work with declarative APIs and that is the recommended approach in cloud native architecture. The advantage with the declarative APIs is that one microservice does not need to understand the details of the operation it wants from a second microservice. This makes the integration quick , easier and developer friendly.
Mutable is defined as anything that’s capable of being changed. Traditionally servers are mutable, as they are continually updated, their configurations are tweaked.
However here is a question, in a cloud like environment, do you really need mutable infrastructure, as this means there will be a challenge to keep the configurations updated and more importantly consistent across clusters.
On the contrary, a better way is to just kill the server and bring up a new server when there is a need to upgrade the server. Which by the way, can be done faster these days. This gave birth to the concept of immutable infrastructure. This refers to servers or VMs which are never modified after deployment. Instead of updating the server, we just replace it with a new version. For any updates or modifications, you will build up a new server from a common image and then decommission the old server.
The biggest benefit of immutable infrastructure is consistent and configuration across all environments ( dev, test, production). Deployments are simpler and predictable and testing the infrastructure is much easier. This greatly simplifies the operation and maintenance of infrastructure in the cloud environment.
This is the last attribute of a cloud native environment.
With hundreds of microservices deployed, there is an increase in service to service communication. Service meshes manage this complex web of service communication in a fast and reliable way.
To understand the concept of service mesh, consider the following example
A user comes to buy something on an eCommerce website. He visits the catalog of products, adds a product to cart, proceeds to checkout. At that stage, he is given the option to upsell, which may take him back to the cart. There is a lot of communication between different services here.
This was a simple example. In practice, there are a huge number of microservices. A better approach is to have a service mesh, which can manage service to service communication avoiding as service to talk to any other service directly.
Conclusion-What is Cloud Native?
So that’s it, these were the seven attributes of cloud-native according to CNCF and hopefully, it should clarify “what is cloud Native”.
Now let me know in the comments section, if you have any questions or think I missed something important that should be an attribute for cloud Native.