The Automation Journey
When starting with autoamtion, the most imported thing is just to start!
Blog Structure
- Definitions - What Cloud Native means.
- The Cloud Native Journey - How to shift towards Cloud Native solutions.
- Monolith vs. Microservices - Understanding architectural differences.
What is 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.
What is a Cloud Native Approach
A Cloud Native approach involves building and running applications that fully leverage the cloud service model, using technologies like:
- Containers
- Services
- Microservices
- Immutable infrastructure
- Declarative APIs
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 (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.
The Cloud Native Pillars
Azure SQL Database
The Cloud Native Journey
When shifting from on-premises (traditional) infrastructure platform to the Cloud, for modernizing legacy apps it can be useful to apply a strategy. Even when workloads/applications are already in the Cloud, these can be further optimized to be Cloud Native and take more advantage of cloud service model. For this there are processes available that can assist you with this transition. There isn’t a one-size-fits-all strategy, however using processes for guidance can help.
The 5 Rs of Cloud Rationalization
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.
The Cloud rationalization process categorizes workloads into five Rs, aiding in the transition to Cloud Native:
- Rehost – “Lift and shift” with no code or backend changes.
- Refactor – Modify applications to use PaaS solutions (e.g., Azure SQL, Azure Files).
- Rearchitect – Enable cloud-native capabilities for cost efficiency.
- Rebuild – Create a new code base using fully managed cloud services.
- Replace – Opt for SaaS solutions when they meet business needs.
More information can be found in the Cloud rationalization article, which is a chapter of the Microsoft Cloud Adoption Framework for Azure
Design Decisions
A structured approach to Cloud Native transformation requires predefined design decisions. So, a DevOps team can move on without to much delay. For example:
“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.