Cloud Native Application Delivery

Every application starts its lifecycle with code that is written.

With services getting smaller and deployments getting more frequent, a logical and important step was the automation of the deployment process. The DevOps movement has highlighted the importance of frequent and rapid deployments. In traditional setups, a deployment would include developers and administrators, a lot of error-prone manual steps and the constant fear that something would break.

Automation is the key to overcoming these barriers, and today we know and use the principles of Continuous Integration/Continuous Delivery (CI/CD), which describe the different steps in the deployment of an application, configuration or even infrastructure.

Continuous Integration is the first part of the process and describes the permanent building and testing of the written code. High automation and usage of version control allows multiple developers and teams to work on the same code base.

Continuous Delivery is the second part of the process and automates the deployment of the pre-built software. In cloud environments, you will often see that software is deployed to Development or Staging environments, before it gets released and delivered to a production system.

Every time a new revision of your code is ready to be deployed, the pipeline starts to execute scripts that build your code, run tests, deploy them to servers and even perform security and compliance checks.

GitOps

GitOps takes the idea of Git as the single source of truth a step further and integrates the provisioning and change process of infrastructure with version control operations.

If code was branched and should be merged back into the main branch, you can create a merge or pull request that can be reviewed by other developers before actually merging it. This has been a best practice for a long time in software development, and also includes running a CI pipeline for every change that should be made. In GitOps, these merge requests are used to manage infrastructure changes.

There are two different approaches how a CI/CD pipeline can implement the changes you want to make:

• Push-based: The pipeline is started and runs tools that make the changes in the platform. Changes can be triggered by a commit or merge request.

• Pull-based: An agent watches the git repository for changes and compares the definition in the repository with the actual running state. If changes are detected, the agent applies the changes to the infrastructure.

Two examples of popular GitOps frameworks that use the pull-based approach are Flux and ArgoCD. ArgoCD is implemented as a Kubernetes controller, while Flux is built with the GitOps Toolkit, a set of APIs and controllers that can be used to extend Flux, or even build a custom delivery platform.

Kubernetes is particularly well suited for GitOps, since it provides an API and is designed for declarative provisioning and changes of resources right from the beginning.

The network that enables communication and networking between pods in Kubernetes is called the pod network. It allows pods to communicate with each other regardless of the node they are running on, facilitating seamless networking within the cluster.