The Cloud Native Journey in(to) the Cloud

The Cloud Native Journey in(to) the Cloud

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.

Figure-1

For constructing optimized  applications in cloud native environments, the Twelve-Factor Application  principles and practices can be used.

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

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

Figure-2

The 5 Rs explained

In “Figure-2” from left to right starting from “Existing apps & services (workloads) On-premises”
 
  • 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 servicesSaaS 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.

Share:
LinkedIn
Robert Knoester

Written by:

Get in touch with us.

Interested in taking the next step for your career? Let’s get to know each other.