Cloud Native Architecture

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. [...].

Characteristics of Cloud Native Architecture

• High level of automation

• Self healing

• Scalable

• Cost-Efficient

• Easy to maintain

• Secure by default

Autoscaling

The autoscaling pattern describes the dynamic adjustment of resources based on the current demand. CPU and memory are the obvious metrics to decide on when to scale applications as load increases or decreases, but other methods based on time or business metrics can also be considered to scale your services up or down.

Typically, when we talk about autoscaling we’re talking about horizontal scaling, which describes the process of spawning new compute resources which can be new copies of your application process, virtual machines, or - in a less immediate way - even new racks of servers and other hardware.

Vertical scaling on the other hand describes the change in size of the underlying hardware, which only works within certain hardware limits for bare metal, but also for virtual machines. Virtual machines and processes can be easily scaled up by allowing them to consume more CPU and memory, the upper limit is defined by the compute and memory capacity of the underlying hardware. The hardware itself can be scaled up, for example, by adding more RAM, but only until all RAM slots are occupied.

Contrary to what the term "serverless" suggests, servers are of course still required as the basis for your applications. Cloud providers suggest that it is very easy to deploy applications, but require that you prepare and configure several resources like a network, virtual machines, operating systems and load balancers to run a simple web application. The idea of serverless computing is to relieve developers of these complicated tasks. In a nutshell, you can just provide the application code, while the cloud provider chooses the right environment to run your application.

Open standards help and complement other systems like Kubernetes, which is the de facto standard platform for orchestrating containers. A few standards that will discover in the following chapters are:

• OCI Spec: image, runtime and distribution specification on how to run, build an distribute containers

• Container Network Interface (CNI): A specification on how to implement networking for Containers.

• Container Runtime Interface (CRI): A specification on how to implement container runtimes in container orchestration systems.

• Container Storage Interface (CSI): A specification on how to implement storage in container orchestration systems.

• Service Mesh Interface (SMI): A specification on how to implement Service Meshes in container orchestration systems with a focus on Kubernetes.

Cloud Native Roles

• Cloud Architect

• DevOps Engineer

• Security Engineer

• DevSecOps Engineer

• Data Engineer

• Full-Stack Developer

• SRE

A lot of open source projects that are seen as industry standard by many are hosted and supported by the Cloud Native Computing Foundation (CNCF).

The CNCF has a Technical Oversight Committee (TOC) that is responsible for defining and maintaining the technical vision, approving new projects, accepting feedback from the end-user committee, and defining common practices that should be implemented in CNCF projects.

At the same time, the TOC does not control the projects, but encourages them to be self-governing and community owned and practices the principle of “minimal viable governance”.

There is a maturity level assigned to each CNCF initiative. Projects proposed to the CNCF should specify their preferred degree of maturity. A project must receive a two-thirds supermajority in order to be approved as incubating or graduated. Any graduated votes are considered as votes to join as an incubating project if there is not a supermajority of votes to do so.

Levels:

• Sandbox Stage

• Incubating Stage

• Graduation Stage