DevOps... Little more

This article is in the continuation of my previous article(Fundamentals of DevOps), wherein I have covered some of the basics of DevOps. Here, I will cover DevOps in Cloud and Multi-cloud.

To start with, let's concentrate on the CI-CD part of DevOps. The following image depicts some of the essential steps of CI-CD. Every CI-CD tool will perform all these tasks automatically.

Observability- Before moving further, let's discuss and understand Observability. This would cover, continuous monitoring, logging, and tracing aspects of DevOps/CI-CD.

Tech culture is known for its plethora of buzzwords and jargon. Let's simplify one of them - "Observability".Observability is nothing but the ability to measure the internal states of a system by examining its outputs.?It is not a new concept; it's been ages here. However, in the era of cloud and microservices, "Observability" is all around and became the heart of the overall system's health performance and business useability.

There are three Pillers of Observability.

1- Monitoring 2-Logging 3-Tracing

As we need to visualize all the data/ system states, I have included "Visualization" as well. Numerous tools are getting used for each pillar; however, each cloud service provider has managed services to tackle all four aspects of Observability. Some of the popular tools are Prometheus, Grafana, Jaeger, EKL stack(Elasticsearch, Logstash, Kibana) , in the case of AWS cloud watch etc.

Please have a look at my article for detail observability aspects in DevOps.

DevOps Cloud Services -

Every cloud service provider has its own services for DevOps-related activities, those can be used for specific cloud environments. One can utilize these services for better and faster results and experience, in the case of a single cloud.

Here, let's discuss Azure DevOps a bit- The beauty of Azure DevOps is flexibility. It is platform-agnostic and cloud-agnostic. It does not matter whether you deploy your software to Azure, AWS, or GCP; continuous delivery is supported to all these cloud services.

Azure DevOps introduced new ways to plan smarter with?enhanced collaboration and achieve faster product delivery, backed by modern development services. Key features offered by Azure DevOp are the following.

1-Azure Boards-?is a tool that helps teams plan, track, visualize, and discuss the work that needs to be done. It supports CMMI, Scrum, Agile, and?Basic methodologies.

2-Azure Repos?provides unlimited, cloud-hosted private and public Git repos.

3-Azure Pipelines?is a cloud service that can automatically build, test, and deploy any code project. It is a cloud-agnostic CI/CD platform with support for containers or Kubernetes.

4-Azure Test Plans?provides manual and exploratory testing solutions.

5-Azure Artifacts?lets you create, host, and share packages. It also provides integrated package management with support for Maven, npm, Python, and NuGet package feeds from public or private sources.

Containers-

Containerization is a vital part of the DevOps roadmap. Before talking about containers, let's assume you are creating a web application on your local machine that works fine on your system. But when you try to move the project from the development machine to the testing and production server machine, you face some error — part of the application may not be working as expected in the testing or production/upper environment. It used to be a classic problem, and we used to hear some of the statements like.

The developer will say: “It is working fine on my machine. I am not responsible for this error.”

And the operations team will say: “You must guide us to solve this problem. It was created by you, so rectify it.”

This used to be a frequently occurring issue and to address this problem or bridge this gap between the developers and operations team, Docker was created. By using Docker, we can create a virtual workspace (container) and develop our application (ERP, CRM etc.) inside the Docker container.? Containers are lightweight and only contain application and related dependencies. However, we need to see containers with respect to virtual machines.

Virtual machines (VMs) are an abstraction of physical hardware turning one server into many servers. The hypervisor allows multiple VMs to run on a single machine. Each VM includes a full copy of an operating system, the application, necessary binaries, and libraries — taking up tens of GBs. VMs can also be slow to boot.

On the contrary, Containers are an abstraction at the app layer that packages code and dependencies together. Multiple containers can run on the same machine and share the OS kernel with other containers, each running as isolated processes in userspace. Containers take up less space than VMs (container images are typically tens of MBs in size), can handle more applications, and require fewer VMs and Operating systems.

Other than the above-mentioned issues, one of the prime reasons of popularity of containers is microservices-based implementation. Nowadays, everyone wants to catch the train of microservices and we can not imagine microservice architecture without containers.

Kubernetes-

Orchestration is a way of automating the operational efforts required for managing containerized applications. It is a process that automates applications’ scale-in, scale-out, networking, deployments of containers, etc. All of these operations mentioned above can also be done without an orchestrator if the containerized application to be managed is very small. However, when it comes to microservices applications with hundreds of microservices running thousands of containers, it becomes challenging to manage all these containers, and here comes an Orchestrator to rescue.?

Kubernetes is a powerful open-source orchestration system originally developed by Google to handle containerized applications in a clustered environment. The above image is the high-level architecture of Kubernetes.

A few key terms related to Kubernetes Formation and Kubernetes:

• Container: An executable image that contains a single piece of software and all its dependencies. In our case, it’s a Docker container.
• Node: A virtual or physical machine that is used as a worker for Kubernetes. Kubernetes will abstract its management away in practice. A Kubernetes cluster contains a master node that is used to manage the state of the cluster in real-time and allows user interaction.
• Cluster: A set of nodes that run containers managed by Kubernetes. This is analogous to a Domain in Payara Server.
• Pod: The smallest Kubernetes object. A pod runs a set of containers. Usually, pods have one container each, but in some cases, they may also include additional container services such as one to add logging capabilities, for example.
• Deployment: An object that manages a set of replicated pods. Scaling a microservice involves adding more pods to a deployment.
• Service: An object that describes how to access deployments or groups of pods via a common endpoint. May create things like load balancers to access the resource.
• Label: Labels are added to Kubernetes objects (pods, deployments, services, etc.) in order to be selected together.
• Selector: A selector references a label in order to allow the interaction with a set of objects, like multiple containers for the purposes of load balancing, for example.
• Kubectl: The command-line utility used to interact with the Kubernetes master node.

Kubernetes is not the only player in the market, different?Kubernetes competitors and Kubernetes alternatives?like Amazon ECS, Docker Swarm, Nomad, etc., are also available.?

Here is some comparison among different Kubernetes alternatives.

Google originally developed Kubernetes; after that, it was made open source. Google, AWS, and Azure all have managed services for Kubernetes, GKE, EKS, and AKS, respectively. Here, a high-level feature comparison among those Kubernetes managed services.

Sample CI-CD architecture and Kubernetes steps -

Helm-

"Helm" for Kubernetes is the same thing as Docker for containers. It gives the ability to deploy a complete application with a single command. Kubernetes is an excellent platform for running container applications, however, it lacks application state descriptions using manifest files. The Kubernetes community developed "Helm", which allows us to write manifests and concentrate on the application deployment process.

Helm provides three significant benefits to the process of service deployments to the Kubernetes platform:

Some of the benefits-

1)Deployment speed?– One can deploy any application available at "Helm" chart repository within a single command.

2)Prebuilt application configurations?– Helm allows to install applications (the chart) with ease.

3)Easy rollbacks?– "Helm" allows you to easily rollback your application deployment to the previous version if something went wrong.

Sample Helm and Kubernetes CI-CD pipeline

12 factors of Cloud/Multi-cloud CI-CD

Following are 12 factors of CI-CD, those must be followed. Each factor will utilize its respective tools.

1)Source Code Management - It also covers configuration management-related aspects. Ansible playbook, Chef cookbooks, or shell scripts , are the main tools.

2)Build Management -The pipeline defines the entire lifecycle of an application as code. This can be achieved in many ways, including a Jenkins or Spinnaker pipeline. Spinnaker is a cloud-agnostic that can target any cloud platform and is?YAML file-based. The Harness is another SAAS a cloud-agnostic CD tool that can be used for multi-cloud deployments.

3)Repository management -Artifacts built by Jenkins (other CI servers) are pushed to the repository manager and can be tagged based on environments

4)Quality Management - One example is SonarQube, which can be used. More detail cab be found in article

5)Deployment management -Continues delivery tool, Please follow part 1 for more detail.

6)Container Configuration -It is advisable to have the?same?container for all environments. There are multiple ways of configuring it. I have listed a few of them below:

• Set?the application configuration dynamically via environment variables.
• Map the config files via Docker Volumes.
• Bake configuration into the container.
• If provided as service, then Fetch it from Config Server.

7)Test Automation -A fast User Acceptance Test [UAT] feedback cycle is critical for continuous delivery to be successful. Automated Test-Driven Development [ATDD] is a necessity to establish a speedy feedback loop. With ecosystems like Docker and cloud infrastructure, automated tests that require compute, storage, and network environments get easier. For ATDD, we can use Mockito, Cucumber, or Selenium Grid.

8)Build Infra in Cloud - This is primarily for infrastructure as code. If it is a single cloud provider, based on the provider, we can use templates; for AWS, we have Cloud Formation Template, for Azure, we can use Azure Resource Manager, and for Google, it will be Google Cloud Platform Template.

Terraform is cloud-agnostic and allows a single configuration to be used to manage multiple providers. It can even handle cross-cloud dependencies. This simplifies the management and orchestration of the infrastructure, helping operators build large-scale multi-cloud infrastructures.

9)Log Management -As mentioned Observability section. Please follow article for more details and respective tools.

10)Monitoring Management- As mentioned Observability section. Please follow article for more details and respective tools.

11)Container Cluster Management - Choosing the right container orchestration tool. The detail is the Kubernetes section.

12)Docker Management- The Docker daemon running on the CI server is going to build an image based on the DockerFile as a source code and will push it to the Docker registry. It can be DockerHub, AWS ECR, Google Container Registry, Azure Container Registry, or even a private registry. However, it is always to good to use cloud vendor-agnostic tools.

Some of the CI-CD pipeline examples -

Azure - Terraform - AKS-Helm-

Here we can see, Terraform is used as an infrastructure as a code tool and creating and provisioning the environment. Azure DevOps is used for CI-CD pipeline, AKS is used as Kubernetes platform, Helm charts are also used. From an Observability point of view - Azure Monitor and Insight are also used. KeyVault is used for storing keys.

AWS -Terraform-ANSIBLE- Sample CI-CD

AWS- ECR - EKS - Sample CI-CD architecture

• Local Development Environment.
• CI Tools. (Gitlab, Github, etc.)
• CD Tools. (Jenkins, etc.)
• Container Registry. (AWS ECR, Gitlab Registry, etc.)
• Kubernetes Cluster. (AWS EKS, On-Premise Kubernetes Cluster, etc.)

AWS-Fargate - Sample CI-CD architecture

Fargate is a compute engine for AWS ECS and EKS that allows you to run containers without having to manage servers or clusters. There is no provisioning, patching, cluster capacity management or any infrastructure management required.

DevSecOps and Sample Aws Pipeline -

Identifying the vulnerabilities during the initial stages of the software development process can significantly help reduce the overall cost of developing application changes, but doing it in an automated fashion can accelerate the delivery of these changes. DevSecOps is the answer to all this.

DevSecOps pipeline is critical to building a successful software system, including continuous integration (CI), continuous delivery and deployment (CD), continuous testing, continuous logging and monitoring, auditing and governance, and operations.

As we can see in this reference AWS-based architecture, includes all the following relevant services and tools essential for DevSecOps.?

Continuous testing tools-

?OWASP Dependency-Check?– A Software Composition Analysis (SCA) tool that attempts to detect publicly disclosed vulnerabilities contained within a project’s dependencies.

?SonarQube (SAST)?– Catches bugs and vulnerabilities in your app, with thousands of automated Static Code Analysis rules.

?PHPStan (SAST)?– Focuses on finding errors in your code without actually running it. It catches whole classes of bugs even before you write tests for the code.

?OWASP Zap (DAST)?– Helps you automatically find security vulnerabilities in your web applications while you’re developing and testing your applications.

One can use the static code review tool?"Amazon CodeGuru"?for static analysis as well

Continuous logging and monitoring services-AWS CloudWatch Logs?,AWS CloudWatch Events?Auditing and governance services-AWS CloudTrail?,AWS Identity and Access Management?,AWS Config? Operations services-AWS Security Hub?,AWS CloudFormation?,AWS Systems Manager Parameter Store?

I have covered some of the cloud vendor-agnostic details of DevSecOps in the my article

Multi-Cloud Deployments-

The multi-cloud approach is a new norm; there are multiple reasons for going with the Multi-cloud approach, such as vendor lock-in, price lock-in, better services availability, and so on. What so over the reason/s or even You may not have a current need to move to multi-cloud. However, defining the software build and deploy practices that are cloud agnostic will always pay in the long term.

Spinnaker-

As mentioned above, for the multi-cloud deployments, one can use some tools like "Spinnaker". It is a sample pipeline with Spinnaker and Docker and Kubernetes.

Let’s look at each step of the workflow:

1. Developers commit/push code to a centralized repository.
2. The completed code triggers Jenkins to test and build a container.
3. This container gets pushed to a container registry.
4. Spinnaker listens for a new image in the container registry and triggers the delivery pipeline for deployment.
5. The Spinnaker pipeline creates the necessary configurations (application configs, instances, scaling, etc.) and deploys the container in a target Kubernetes cluster after manual review.

Let's take a brief look at its components and their functions. There is one component called "Cloud-Driver" that is responsible for multi-cloud deployments.

Spinnaker was originally developed by Netflix however later on it became open source.

Sample Cloud-native pipeline -

Cloud-native is the Key in multi-Cloud, where you are not dependent on one cloud provider. It is a sample CI-CD pipeline that can be used in multi-cloud senerios.

One can get a complete list of cloud-native tools here,

Continues Deployment with Harness - Harness is one of the prime SAAS-based continues Deployment systems. It has the same kind of functionality as Spinnaker however it is a little easy to use and has some extra features. However, It is not open-source as Spinnaker.

It is a high-level architecture of Harness-

Serverless framework-

The serverless framework (https://lnkd.in/d3uqNdH7) is designed to write a code and deploy it to multiple cloud providers / many FaaS providers. Not to mention The "serverless framework" is different from serverless functions. Performing all deployments using the Serverless Framework from the beginning of the project may prove the most efficient way to proceed.

A primary job of the Serverless Framework is to abstract away all the infrastructure concerns of deploying an app to multiple clouds. Using a manifest-based approach, the Serverless Framework can deal with all deployment issues, allowing deployment to be automated as needed.

The framework gives a template where plumbing code is already pre-done. It knows how to deploy it on serverless functions for various cloud providers like AWS-Lambda, Azure and GCP cloud functions.

From the development point of view,?It creates and uses a "serverless.yml" file used by the framework to create infrastructure as a code for a cloud provider.

Summing up -

One of the fundamental cultural aspects of DevOps is communication and collaboration. DevOps tooling and automation focus on creating collaboration by combining the processes and efficiencies of development and operations. As pointed out in part-1, DevOps is evolving and covering system reliability aspects as well.

Resources -

https://harness.io/

https://blog.devgenius.io/what-are-companies-shifting-to-a-devops-culture-e6656274eff5

https://spinnaker.io/

https://www.dhirubhai.net/pulse/devsecops-establishing-culture-alok-sharma/?published=t

https://medium.com/@xenonstack/spinnaker-multi-cloud-continuous-delivery-platform-8ec1ca95f0d6

https://www.alibabacloud.com/blog/cloud-native-is-here-but-not-evenly-distributed_597096

https://dzone.com/articles/twelve-factor-multicloud-devops-pipeline

https://thenewstack.io/meet-spinnaker-ultimate-multi-cloud-deployment-tool/

https://dzone.com/articles/new-way-of-cicd-in-kubernetes-with-jenkins-and-spi

https://www.dhirubhai.net/pulse/serverless-functions-multicloud-jay-saraiya/?trk=articles_directory

https://www.flentas.com/kubernetes-rolling-deployment

https://dzone.com/articles/gitlab-cicd-pipelines-integrated-workflow-oci-kubernetes-and-registry

https://dzone.com/articles/cicd-with-kubernetes-and-helm

https://cloudtweaks.com/2019/05/devops-secure-and-scalable-ci-cd-pipeline-with-aws/

https://www.bmc.com/blogs/kubernetes-spinnaker-continuous-delivery/

https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RWGydG

https://docs.microsoft.com/en-us/azure/architecture/example-scenario/serverless/serverless-multicloud