When moving to the Cloud it helps to be aware of the various Cloud technologies, approaches, and applications. In this blog I will focus on Cloud Native.
- The first part is about definitions and what Cloud Native means
- The second part is about the Cloud Native journey, so how to shift towards more Cloud Native solutions
- The third part is about monolith and microservices
What is a Cloud Native?
Cloud Native is when a tool, application, service or platform is specifically designed to run on cloud (micro)services on a cloud provider. This can be on a public or private cloud provider.
So, what is a Cloud Native approach?
A Cloud Native approach is building and running applications that take full advantage of the cloud service model. Using technologies like containers, services, microservices, immutable infrastructure, and declarative APIs to empower organizations.
Why use this approach?
Cloud Native applications can thrive in a cloud environment using cloud native architecture. When using managed services and PaaS (Platform as a Service) infrastructure. Applications treat underlying infrastructure as disposable and provisioned in minutes, scaled or deployed in demand using automation. Which can bring new ideas to market faster and respond sooner to customers demands.
Official definition
According to the Cloud Native Computing Foundation
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.
For constructing optimized applications in cloud native environments, the Twelve-Factor Application principles and practices can be used.
The Cloud Native Journey
There isn’t a one-size-fits-all strategy, however using processes for guidance can help.
The 5 Rs
In the illustration “Figure-2” below the five Rs of rationalization are displayed. Which can help you with the transition to the Cloud.
The ‘Cloud rationalization’ process uses the five Rs. A great way to label a potential future state for any workload that’s being considered as a cloud candidate. This labelling process should be put into the correct context before you attempt to rationalize an environment.
More information can be found in the Cloud rationalization article, which is a chapter of the Microsoft Cloud Adoption Framework for Azure.
The 5 Rs explained
- Rehost
- “Lift and shift” or “Greenfield” with no-code changes or backend changes;
- Refactor
- You can refactor an application enabling it to use PaaS solutions (combining IaaS with PaaS solutions is also possible). Like IaaS VM using Azure SQL, Azure files etc;
- Rearchitect
- Applications can be Cloud Enabled. It can be cost efficient to rearchitect in to a cloud-native application;
- Rebuild
- When an application is unsupported within current business processes, a new code base with fully managed cloud services may be a solution;
- Replace
- Solutions are typically implemented by using the best technology and approach available at the time. Sometimes software as a service (SaaS) applications can provide all the necessary functionality for the hosted application.
Design decisions
Within the Cloud Native transformation, it is important to have design decisions in place. So, a DevOps team can move on without to much delay.
For example, a design decision which states: “Use managed services | SaaS before PaaS and PaaS before IaaS“
This is a clear decision which helps an IT department to make decisions regarding choosing solutions. Of course, there will be discussions within the department, just make sure business procedures don’t delay what must be done.
From Monolith to Microservices
Monolith
Monolithic applications are composed of a layered architecture (tiers), multiple components are combined into one large application. Consequently, they tend to have large codebases, which can be cumbersome to manage over time.
Microservices
Within microservices architecture each component can be developed, deployed, scaled and operated without affecting other services. Communication is initiated via APIs.
Specific problems are solved with services which have specific capabilities.
Resources
- The Twelve-Factor App (12factor.net)
- What is Cloud Native? | Microsoft Learn
- Stages in Azure Pipelines – Azure Pipelines | Microsoft Docs
- What are Microservices? | AWS (amazon.com)
- CNCF_TrailMap_latest.png (7653×8869) (raw.githubusercontent.com)
- What are Cloud Native Applications? | VMware Tanzu
- Cloud rationalization – Cloud Adoption Framework | Microsoft Learn
- Candidate apps for cloud native | Microsoft Learn
- Cloud-Native Applications | Microsoft Azure