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 ( as per CNCF) 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.
27 thoughts on “What is Cloud Native? Understand the Easy way !”
Very nicely explained. We need these kind of tutorials which makes things easy to understand.
Looking forward for more such articles
Thanks, Asad khan, great that you are liking the articles.
Thanks for sharing this Faisal. Did you check https://www.youtube.com/watch?v=-K4xx7-DcTw&t ?
Your 7: containers, microservices, CI/CD, declarative APIs, Immutable infra, Service Mesh
Hope CI/CD includes, “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“
My simple definition: cloud-native = taking full advantage of the unique capabilities of the cloud
As you may have noticed, cloud definition by NIST is quite broad. Many think the cloud is only VMs and for VMs, whereas cloud definition can have VMs, containers, ….
Anyway, great post, as always.
Thanks Anuradha for sharing your ideas. Yes you nailed it, CI/CD is all about making changes frequently and pushing them to production. I checked your webinar, it was very informative.
Always amazing articles.
Thank you Faisal.
Thanks Rizos Panagiotopoulos !
gr8 roundup Fisal on cloud native!
Thanks Georgios Kalpaktsoglou
Very nicely and simply explained Faisal sb. A must read for all guys working in telco industry and are still trying to understand the buzz about cloud-native networks.
Thanks Aamir, For regularly coming back and reading my blog…
Amazing as always , great article faisal !
Thanks Ajay, for revisiting and liking the article
Well done Faisal, excellent summary, thank you for sharing it
Thanks a lot Milan
Really an impressuve article on Cloud Native. I will contact you if I need more explanation. Well done
Thank you shamim sahib
Perfect read for me to clarify so many aspects of telco cloud. Everything was puzzled in my mind and this made it very clear. Do you plan to write anything about telco cloud security? It’s been realized as an important part of cybersecurity.
Thanks Saifuddin for reading and giving your feedback on what topics you want !
Excellently articulated demystification of cloud-native concept, understanding which is essential to comprehend further advancement in the cloud computing era. It is indeed a good primer for the cloud-native concept.
Pls keep posting such insightful and guiding articles.
Have a great year ahead!
Thanks a lot Rajesh ! I am glad that you liked it.
Your latest post on legacy vnf to cloudnative vnf is not opeing.
url : https://telcocloudbridge.com/blog/from-legacy-vnf-to-cloud-native-vnf/
seems, it is resolved now. might be down temp.
That is good to know, Nizar ! Nice meeting you
Hey Faisal thanks for putting this together. I’d like to also invite you to our [weekly meetings](https://github.com/cncf/cnf-wg#recurring-meetings) where we discuss CNF best practices and uses cases. Regarding the seven attributes, I’m not sure about the first one… we had a long discussion about it [here](https://github.com/cncf/cnf-wg/pull/171) resulting in a new term called [Containerized Network Functions](https://github.com/cncf/cnf-wg/blob/main/doc/glossary.md#cnf-wg-specific-definitions) to distinguish them
Hello Victor, thanks for your comments. This is very interesting comment. I used the word “containers” from the definition from CNCF here
Do you mean, you are doing away with the word containers for another word ” containerized network functions” ?
Well, the discussion was mostly centered in not restricting uniquely the scope of CNF definition to the implementation of containers, which can lead to bad practices and/or misused of technologies. Saying that, a CNF could be implemented in bare-metal servers using on-demand and autoscaling cloud approaches and delegating the VNF definition to the transition from physical specialized servers to commodity hardware. Anyway, there is still a blurry line there.