Deleting an ECS service

terraform plan – Infrastructure as Code (IaC) with Terraform

To run a Terraform plan, use the following command:

$ terraform plan

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols: + create Terraform will perform the following actions:

  • azurerm_resource_group.rg will be created + resource “azurerm_resource_group” “rg” {
 +id= (known after apply)
 +location= “westeurope”
 + name= “terraform-exercise”
}   
Plan:1to add, 0 to change, 0 to destroy.

Note: You didn’t use the -out option to save this plan, so Terraform can’t guarantee to take exactly these actions if you run terraform apply now.

The plan output tells us that if we run terraform apply immediately, it will create a single terraform_exercise resource group. It also outputs a note that since we did not save this plan, the subsequent application is not guaranteed to result in the same action. Meanwhile, things might have changed; therefore, Terraform will rerun plan and prompt us for yes when applying. Thus, you should save the plan to a file if you don’t want surprises.

Tip

Always save terraform plan output to a file and use the file to apply the changes. This is to avoid any last-minute surprises with things that might have changed in the background and apply not doing what it is intended to do, especially when your plan is reviewed as a part of your process.

So, let’s go ahead and save the plan to a file first using the following command:

$ terraform plan -out rg_terraform_exercise.tfplan

This time, the plan is saved to a file calledrg_terraform_exercise.tfplan. We can use this file to apply the changes subsequently.

terraform apply

To apply the changes using the plan file, run the following command:

$ terraform apply “rg_terraform_exercise.tfplan”

azurerm_resource_group.rg: Creating…

azurerm_resource_group.rg: Creation complete after 2s [id=/subscriptions/id/ resourceGroups/terraform-exercise]

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

And that’s it! Terraform has applied the configuration. Let’s use the Azure CLI to verify whether the resource group is created.

Run the following command to list all resource groups within your subscription:

$ az group list

…

“id”: “/subscriptions/id/resourceGroups/terraform-exercise”,

“location”: “westeurope”,

“name”: “terraform-exercise”,

…

We see that our resource group is created and within the list.

There might be instances when apply is partially successful. In that case, Terraform will automatically taint resources it believes weren’t created successfully. Such resources will be recreated automatically in the next run. If you want to taint a resource for recreation manually, you can use the terraform taint command:

$ terraform taint <resource>

Suppose we want to destroy the resource group as we no longer need it. We can use terraform destroy for that.

2024-08-31 by Building the Python Flask app Cloud Certifications Deleting an ECS service Exams of Cloud Knative architecture 0

terraform init – Infrastructure as Code (IaC) with Terraform

To initialize a Terraform workspace, run the following command:

$ terraform init
Initializing the backend…
Initializing provider plugins…

  • Finding hashicorp/azurerm versions matching “3.63.0”…
  • Installing hashicorp/azurerm v3.63.0…
  • Installed hashicorp/azurerm v3.63.0 (signed by HashiCorp)

Terraform has created a lock file, .terraform.lock.hcl, to record the provider selections it made previously. Include this file in your version control repository so that Terraform can guarantee to make the same selections by default when you run terraform init in the future.

Terraform has been successfully initialized!

As the Terraform workspace has been initialized, we can create an Azure resource group to start working with the cloud.

Creating the first resource – Azure resource group

We must use the azurerm_resource_group resource within the main.tf file to create an

Azure resource group. Add the following to your main.tf file to do so:

resource “azurerm_resource_group” “rg” {
name         = var.rg_name
location = var.rg_location
}

As we’ve used two variables, we’ve got to declare those, so add the following to the vars.tf file:

variable “rg_name” {
type              = string
description = “The resource group name”
}
variable “rg_location” {
type              = string
description = “The resource group location”
}

Then, we need to add the resource group name and location to the terraform.tfvars file.

Therefore, add the following to the terraform.tfvars file:

rg_name=terraform-exercise
rg_location=”West Europe”

So, now we’re ready to run a plan, but before we do so, let’s use terraform fmt to format our files into the canonical standard.

terraform fmt

The terraform fmt command formats the .tf files into a canonical standard. Use the following command to format your files:

$ terraform fmt
terraform.tfvars
vars.tf

The command lists the files that it formatted. The next step is to validate your configuration.

terraform validate

The terraform validate command validates the current configuration and checks whether there are any syntax errors. To validate your configuration, run the following:

$ terraform validate
Success! The configuration is valid.

The success output denotes that our configuration is valid. If there were any errors, it would have highlighted them in the validated output.

Tip

Always run fmt and validate before every Terraform plan. It saves you a ton of planning time and helps you keep your configuration in good shape.

As the configuration is valid, we are ready to run a plan.

2024-07-02 by Cloud Certifications Deleting an ECS service Exams of Cloud Knative architecture Load testing your app on Knative 0

Providing variable values – Infrastructure as Code (IaC) with Terraform

There are a few ways to provide variable values within Terraform:

  • Via the console using -var flags: You can use multiple -var flags with the variable_ name=variable_value string to supply the values.
  • Via a variable definition file (the .tfvars file): You can use a file containing the list of variables and their values ending with an extension of .tfvars (if you prefer HCL) or .tfvars. json (if you prefer JSON) via the command line with the -var-file flag.
  • Via default variable definition files: If you don’t want to supply the variable definition file via the command line, you can create a file with the name terraform.tfvars or end it with an extension of .auto.tfvars within the Terraform workspace. Terraform will automatically scan these files and take the values from there.
  • Environment variables: If you don’t want to use a file or pass the information via the command line, you can use environment variables to supply it. You must create environment variables with the TF_VAR_<var-name> structure containing the variable value.
  • Default: When you run a Terraform plan without providing values to variables in any other way, the Terraform CLI will prompt for the values, and you must manually enter them.

If multiple methods are used to provide the same variable’s value, the first method in the preceding list has the highest precedence for a specific variable. It overrides anything that is defined in the methods listed later.

We will use the terraform.tfvars file for this activity and provide the values for the variables.

Add the following data to the terraform.tfvars file:

subscription_id = “<SUBSCRIPTION_ID>”

app_id= “<SERVICE_PRINCIPAL_APP_ID>”
password=“<SERVICE_PRINCIPAL_PASSWORD>”
tenant=“<TENANT_ID>”

If you are checking the Terraform configuration into source control, add the file to the ignore list to avoid accidentally checking it in.

If you use Git, adding the following to the .gitignore file will suffice:

*.tfvars

.terraform*

Now, let’s go ahead and look at the Terraform workflow to progress further.

Terraform workflow

The Terraform workflow typically consists of the following:

  • init: Initializes the Terraform workspace and backend (more on them later) and downloads all required providers. You can run the init command multiple times during your build, as it does not change your workspace or state.
  • plan: It runs a speculative plan on the requested resources. This command typically connects with the cloud provider and then checks whether the objects managed by Terraform exist within the cloud provider and whether they have the same configuration as defined in the Terraform template. It then shows the delta in the plan output that an admin can review and change the

configuration if unsatisfied. If satisfied, they can apply the plan to commit the changes to the cloud platform. The plan command does not make any changes to the current infrastructure.

  • apply: This applies the delta configuration to the cloud platform. When you useapply by itself, it runs the plan command first and asks for confirmation. If you supply a plan to it, it applies the plan directly. You can also use apply without running the plan using the -auto-approve flag.
  • destroy: The destroy command destroys the entire infrastructure Terraform manages. It is, therefore, not a very popular command and is rarely used in a production environment. That does not mean that the destroy command is not helpful. Suppose you are spinning up a development infrastructure for temporary purposes and don’t need it later. In that case, destroying everything you created using this command takes a few minutes.

To access the resources for this section, cd into the following:

$ cd ~/modern-devops/ch8/terraform-exercise Now, let’s look at these in detail with hands-on exercises.

2024-06-03 by Deleting an ECS service Exams of Cloud Knative architecture Load testing your app on Knative Providing variable values 0

Installing Terraform – Infrastructure as Code (IaC) with Terraform

Installing Terraform is simple; go to https://www.terraform.io/downloads.html and follow the instructions for your platform. Most of it will require you to download a binary and move it to your system path.

Since we’ve been using Ubuntu throughout this book, I will show the installation on Ubuntu. Use the following commands to use the apt package manager to install Terraform:

$ wget -O- https://apt.releases.hashicorp.com/gpg | \

sudo gpg –dearmor -o /usr/share/keyrings/hashicorp-archive-keyring.gpg

$ echo “deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] \ https://apt.releases.hashicorp.com $(lsb_release -cs) main” | \ sudo tee /etc/apt/sources.list.d/hashicorp.list

$ sudo apt update && sudo apt install terraform

Check whether Terraform has been installed successfully with the following command:

$ terraform version

Terraform v1.5.2

It shows that Terraform has been installed successfully. Terraform uses Terraform providers to interact with cloud providers, so let’s look at those in the next section.

Terraform providers

Terraform has a decentralized architecture. While the Terraform CLI contains Terraform’s core functionality and provides all functionalities not related to any specific cloud provider, Terraform providers provide the interface between the Terraform CLI and the cloud providers themselves. This decentralized approach has allowed public cloud vendors to offer their Terraform providers so that their customers can use Terraform to manage infrastructure in their cloud. Such is Terraform’s popularity that it has now become an essential requirement for every public cloud provider to offer a Terraform provider.

We will interact with Azure for this chapter’s entirety and use the Azure Terraform provider for our activity.

To access the resources for this section, cd into the following:

$ cd ~/modern-devops/ch8/terraform-exercise/

Before we go ahead and configure the provider, we need to understand how Terraform needs to authenticate and authorize with the Azure APIs.

2024-02-20 by Building the Python Flask app Cloud Certifications Deleting an ECS service Exams of Cloud Providing variable values Using the Azure Terraform provider 0

Introduction to IaC – Infrastructure as Code (IaC) with Terraform

IaC is the concept of using code to define infrastructure. While most people can visualize infrastructure as something tangible, virtual infrastructure is already commonplace and has existed for around two decades. Cloud providers provide a web-based console through which you can manage your infrastructure intuitively. But the process is not repeatable or recorded.

If you spin up a set of infrastructure components using the console in one environment and want to replicate it in another, it is a duplication of effort. To solve this problem, cloud platforms provide APIs to manipulate resources within the cloud and some command-line tools that can help trigger the APIs. You can start writing scripts using commands to create the infrastructure and parameterize them to use the same scripts in another environment. Well, that solves the problem, right?

Not really! Writing scripts is an imperative way of managing infrastructure. Though you can still call it IaC, its problem is that it does not effectively manage infrastructure changes. Let me give you a few examples:

  • What would happen if you needed to modify something already in the script? Changing the script somewhere in the middle and rerunning the entire thing may create havoc with your infrastructure. Imperative management of infrastructure is not idempotent. So, managing changes becomes a problem.
  • What if someone manually changes the script-managed infrastructure using the console? Will your script be able to detect it correctly? What if you want to change the same thing using a script? It will soon start to get messy.
  • With the advent of hybrid cloud architecture, most organizations use multiple cloud platforms for their needs. When you are in such a situation, managing multiple clouds with imperative scripts soon becomes a problem. Different clouds have different ways of interacting with their APIs and have distinct command-line tools.

The solution to all these problems is a declarative IaC solution such as Terraform. HashiCorp’s Terraform is the most popular IaC tool available on the market. It helps you automate and manage your infrastructure using code and can run on various platforms. As it is declarative, you just need to define what you need (the desired end state) instead of describing how to achieve it. It has the following features:

  • It supports multiple cloud platforms via providers and exposes a single declarative HashiCorp Configuration Language (HCL)-based interface to interact with it. Therefore, it allows you to manage various cloud platforms using a similar language and syntax. So, having a few Terraform experts within your team can handle all your IaC needs.
  • It tracks the state of the resources it manages using state files and supports local and remote backends to store and manage them. That helps in making the Terraform configuration idempotent. So, if someone manually changes a Terraform-managed resource, Terraform can detect the difference in the next run and prompt corrective action to bring it to the defined configuration. The admin can then absorb the change or resolve any conflicts before applying it.
  • It enables GitOps in infrastructure management. With Terraform, you can have the infrastructure configuration alongside application code, making versioning, managing, and releasing infrastructure the same as managing code. You can also include code scanning and gating using pull requests so that someone can review and approve the changes to higher environments before you apply them. A great power indeed!

Terraform has multiple offerings – open source, cloud , and enterprise. The open source offering is a simple command- line interface (CLI)-based tool that you can download on any supported operating system (OS) and use. The cloud and enterprise offerings are more of a wrapper on top of the open source one. They provide a web-based GUI and advanced features such as policy as code with Sentinel, cost analysis, private modules, GitOps, and CI/CD pipelines.

This chapter will discuss the open source offering and its core functions.

Terraform open source is divided into two main parts – Terraform Core and Terraform providers, as seen in the following diagram:

Figure 8.1 – Terraform architecture

Let’s look at the functions of both components:

  • Terraform Core is the CLI that we will use to interact with Terraform. It takes two main inputs – your Terraform configuration files and the existing state. It then takes the difference in configuration and applies it.
  • Terraform providers are plugins that Terraform uses to interact with cloud providers. The providers translate the Terraform configuration into the respective cloud’s REST API calls so that Terraform can manage its associated infrastructure. For example, if you want Terraform to manage AWS infrastructure, you must use the Terraform AWS provider.

Now let’s see how we can install open source Terraform.

2024-01-16 by Building the Python Flask app Cloud Certifications Deleting an ECS service Exams of Cloud Using the Azure Terraform provider 0

Load testing your app on Knative – Containers as a Service (CaaS) and Serverless Computing for Containers

We will use the hey utility to perform load testing. Since your application has already been deployed, run the following command to do the load test:

$ hey -z 30s -c 500 http://py-time.default.35.226.198.46.sslip.io

Once the command has executed, run the following command to get the currently running instances of the py-time pods:

$ kubectl get pod    
NAMEREADY STATUS RESTARTSAGE
py-time-00001-deployment-52vjv 2/2Running044s
py-time-00001-deployment-bhhvm 2/2Running044s
py-time-00001-deployment-h6qr5 2/2Running042s
py-time-00001-deployment-h92jp 2/2Running040s
py-time-00001-deployment-p27gl 2/2Running088s
py-time-00001-deployment-tdwrh 2/2Running038s
py-time-00001-deployment-zsgcg 2/2Running042s

As we can see, Knative has created seven instances of the py-time pod. This is horizontal autoscaling in action.

Now, let’s look at the cluster nodes by running the following command:

$ kubectl get nodes

NAME STATUS AGE gke-cluster-1-default-pool-353b3ed4-js71 Ready 3m17s gke-cluster-1-default-pool-353b3ed4-mx83 Ready 106m gke-cluster-1-default-pool-353b3ed4-vf7q Ready 106m

As we can see, GKE has created another node in the node pool because of the extra burst of traffic it received. This is phenomenal, as we have the Kubernetes API to do what we want. We have automatically horizontally autoscaled our pods. We have also automatically horizontally autoscaled our cluster worker nodes. This means we have a fully automated solution for runningcontainers without worrying about the management nuances! That is open source serverless in action for you!

Summary

This chapter covered CaaS and serverless CaaS services. These help us manage container applications with ease without worrying about the underlying infrastructure and managing them. We used Amazon’s ECS as an example and deep-dived into it. Then, we briefly discussed other solutions that are available on the market.

Finally, we looked at Knative, an open source serverless solution for containers that run on top of Kubernetes and use many other open source CNCF projects.

In the next chapter, we will delve into IaC with Terraform.

2023-11-05 by Deleting an ECS service Exams of Cloud Load testing your app on Knative Providing variable values Using the Azure Terraform provider 0

Building the Python Flask app – Containers as a Service (CaaS) and Serverless Computing for Containers

Deploying a Python Flask application on Knative

To understand Knative, let’s try to build and deploy a Flask application that outputs the current timestamp in the response. Let’s start by building the app.

Building the Python Flask app

We will have to create a few files to build such an app.

The app.py file looks like this:

import os

import datetime

from flask import Flask

app = Flask(__name__)

@app.route(‘/’)

def current_time():

ct = datetime.datetime.now()

return ‘The current time is : {}!\n’.format(ct)

if __name__ == “__main__”:

app.run(debug=True,host=’0.0.0.0′)

We will need the following Dockerfile to build this application:

FROM python:3.7-slim

ENV PYTHONUNBUFFERED True

ENV APP_HOME /app

WORKDIR $APP_HOME

COPY . ./

RUN pip install Flask gunicorn

CMD exec gunicorn –bind :$PORT –workers 1 –threads 8 –timeout 0 app:app

Now, let’s go ahead and build the Docker container using the following command:

$ docker build -t <your_dockerhub_user>/py-time .

Now that the image is ready, let’s push it to Docker Hub by using the following command:

$ docker push <your_dockerhub_user>/py-time

As we’ve successfully pushed the image, we can run this on Knative.

Deploying the Python Flask app on Knative

We can use the kn command line or create a manifest file to deploy the app. Use the following command to deploy the application:

$ kn service create py-time –image <your_dockerhub_user>/py-time

Creating service ‘py-time’ in namespace ‘default’:

9.412s Configuration “py-time” is waiting for a Revision to become ready.

9.652s Ingress has not yet been reconciled.

9.847s Ready to serve.

Service ‘py-time’ created to latest revision ‘py-time-00001’ is available at URL:

http://py-time.default.35.226.198.46.sslip.io

As we can see, Knative has deployed the app and provided a custom endpoint. Let’s curl the endpoint to see what we get:

$ curl http://py-time.default.35.226.198.46.sslip.io The current time is : 2023-07-03 13:30:20.804790!

We get the current time in the response. As we already know, Knative should detect whether there is no traffic coming into the pod and delete it. Let’s watch the pods for some time and see what happens:

$ kubectl get pod -w    
NAMEREADYSTATUSRESTARTSAGE
py-time-00001-deployment-jqrbk2/2Running05s
py-time-00001-deployment-jqrbk2/2Terminating064s

As we can see, just after 1 minute of inactivity, Knative starts terminating the pod. Now, that’s what we mean by scaling from zero.

To delete the service permanently, we can use the following command:

$ kn service delete py-time

We’ve just looked at the imperative way of deploying and managing the application. But what if we want to declare the configuration as we did previously? We can create a CRD manifest with the Service resource provided by apiVersion—serving.knative.dev/v1.

We will create the following manifest file, called py-time-deploy.yaml, for this:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: py-time
spec:
template:
spec:
containers:
image: /py-time

As we’ve created this file, we will use the kubectl CLI to apply it. It makes deployment consistent with Kubernetes.

Note

Though it is a service resource, don’t confuse this with the typical Kubernetes Service resource. It is a custom resource provided by apiVersion serving.knative.dev/ v1. That is why apiVersion is very important.

Let’s go ahead and run the following command to do so:

$ kubectl apply -f py-time-deploy.yaml

service.serving.knative.dev/py-time created

With that, the service has been created. To get the service’s endpoint, we will have to query the ksvc resource using kubectl. Run the following command to do so:

$ kubectl get ksvc py-time

NAME          URL

py-time     http://py-time.default.35.226.198.46.sslip.io

The URL is the custom endpoint we have to target. Let’s curl the custom endpoint using the following command:

$ curl http://py-time.default.35.226.198.46.sslip.io The current time is : 2023-07-03 13:30:23.345223!

We get the same response this time as well! So, if you want to keep using kubectl for managing Knative, you can easily do so.

Knative helps scale applications based on the load it receives—automatic horizontal scaling. Let’s run load testing on our application to see that in action.

2023-10-19 by Deleting an ECS service Exams of Cloud Providing variable values Using the Azure Terraform provider 0

Knative architecture– Containers as a Service (CaaS) and Serverless Computing for Containers

The Knative project combines elements of existing CNCF projects such as Kubernetes, Istio, Prometheus, and Grafana and eventing engines such as Kafka and Google Pub/Sub. Knative runs as a Kubernetes operator using Kubernetes Custom Resource Definitions (CRDs), which help operators administer Knative using the kubectl command line. Knative provides its API for developers, which the kn command-line utility can use. The users are provided access through Istio, which, with its traffic managementfeatures, is a crucial component of Knative. The following diagram describes

this graphically:

Figure 7.2 – Knative architecture

Knative consists of two main modules—serving and eventing. While the serving module helps us maintain stateless applications using HTTP/S endpoints, the eventing module integrates with eventing engines such as Kafka and Google Pub/Sub. As we’ve discussed mostly HTTP/S traffic, we will scope our discussion to Knative serving for this book.

Knative maintains serving pods, which help route traffic within workload pods and act as proxies using the Istio Ingress Gateway component. It provides a virtual endpoint for your service and listens to it. When it discovers a hit on the endpoint, it creates the required Kubernetes components to serve that traffic. Therefore, Knative has the functionality to scale from zero workload pods as it will spin up a pod when it receives traffic for it. The followingdiagram shows how:

Figure 7.3 – Knative serving architecture

Knative endpoints are made up of three basic parts—<app-name>, <namespace>, and <custom-domain>. While name and namespace are similar to Kubernetes Services, custom-domain is defined by us. It can be a legitimate domain for your organization or a MagicDNS solution, such as sslip.io, which we will use in our hands-on exercises. If you are using your organization domain, you must create your DNS configuration to resolve the domain to the Istio Ingress Gateway IP addresses.

Now, let’s go ahead and install Knative.

For the exercises, we will use GKE. Since GKE is a highly robust Kubernetes cluster, it is a great choice for integrating with Knative. As mentioned previously, Google Cloud provides a free trial of $300 for 90 days. You can sign up at https://cloud.google.com/free if you’ve not done so already.

2023-08-05 by Building the Python Flask app Cloud Certifications Deleting an ECS service Exams of Cloud 0

Open source CaaS with Knative – Containers as a Service (CaaS) and Serverless Computing for Containers

As we’ve seen, several vendor-specific CaaS services are available on the market. Still, the problem with most of them is that they are tied up to a single cloud provider. Our container deployment specification then becomes vendor-specific and results in vendor lock-in. As modern DevOps engineers, we must ensure that the proposed solution best fits the architecture’s needs, and avoiding vendor lock-in is one of the most important requirements.

However, Kubernetes in itself is not serverless. You must have infrastructure defined, and long-running services should have at least a single instance running at a particular time. This makes managing microservices applications a pain and resource-intensive.

But wait! We said that microservices help optimize infrastructure consumption. Yes—that’s correct, but they do so within the container space. Imagine that you have a shared cluster of VMs where parts of the application scale with traffic, and each part of the application has its peaks and troughs. Doing this will save a lot of infrastructure by performing this simple multi-tenancy.

However, it also means that you must have at least one instance of each microservice running every time—even if there is zero traffic! Well, that’s not the best utilization we have. How about creating instances when you get the first hit and not having any when you don’t have traffic? This would save a lot of resources, especially when things are silent. You can have hundreds of microservices making up the application that would not have any instances during an idle period. If you combine it with a managed service that runs Kubernetes and then autoscale your VM instances with traffic, you can have minimal instances during the silent period.

There have been attempts within the open source and cloud-native space to develop an open source, vendor-agnostic, serverless framework for containers. We have Knative for this, which the Cloud Native Computing Foundation (CNCF) has adopted.

Tip

The Cloud Run service uses Knative behind the scenes. So, if you use Google Cloud, you can use Cloud Run to use a fully managed serverless offering.

To understand how Knative works, let’s look at the Knative architecture.

2023-06-17 by Cloud Certifications Deleting an ECS service Exams of Cloud Knative architecture 0

Other CaaS services – Containers as a Service (CaaS) and Serverless Computing for Containers

Amazon ECS provides a versatile way of managing your container workloads. It works great when you have a smaller, simpler architecture and don’t want to add the additional overhead of using a complex container orchestration engine such as Kubernetes.

Tip

ECS is an excellent tool choice if you run exclusively on AWS and don’t have a future multi-cloud or hybrid-cloud strategy. Fargate makes deploying and running your containers easier without worrying about the infrastructure behind the scenes.

ECS is tightly coupled with AWS and its architecture. To solve this problem, we can use managed services within AWS, such as Elastic Kubernetes Service (EKS). It offers the Kubernetes API to schedule your workloads. This makes managing containers even more versatile as you can easily spin up a Kubernetes cluster and use a standard, open source solution that you can install and run anywhere you like. This does not tie you to a particular vendor. However, EKS is slightly more expensive than ECS and adds a $0.10 per hour cluster management charge. That is nothing in comparison to the benefits you get out of it.

If you aren’t running on AWS, there are options from other providers too. The next of the big three cloud providers is Azure, which offers Azure Kubernetes Service (AKS), a managed Kubernetes solution that can help you get started in minutes. AKS provides a fully managed solution with event-driven elastic provisioning for worker nodes as and when required. It also integrates nicely with Azure DevOps, giving you a faster end- to-end (E2E) development experience. As with AWS, Azure also charges $0.10 per hour for cluster management.

Google Kubernetes Engine (GKE) is one of the most robust Kubernetes platforms. Since the Kubernetes project came from Google and is the largest contributor to this project in the open source community, GKE is generally quicker to roll out newer versions and is the first to release security patches into the solution. Also, it is one of the most feature-rich with customizable solutions and offers several plugins as a cluster configuration. Therefore, you can choose what to install on Bootstrap and further harden your cluster. However, all these come at a cost, as GKE charges a $0.10 cluster management charge per hour, just like AWS and Azure.

You can use Google Cloud Run if you don’t want to use Kubernetes if your architecture is not complicated, and there are only a few containers to manage. Google Cloud Run is a serverless CaaS solution built on the open source Knative project. It helps you run your containers without any vendor lock-in. Since it is serverless, you only pay for the number of containers you use and their resource utilization. It is a fully scalable and well-integrated solution with Google Cloud’s DevOps and monitoring solutions such as Cloud Code, Cloud Build, Cloud Monitoring, and Cloud Logging. The best part is that it is comparable to AWS Fargate and abstracts all infrastructure behind the scenes. So, it’s a minimal Ops or NoOps solution.

Now that we’ve mentioned Knative as an open source CaaS solution, let’s discuss it in more detail.

2023-05-12 by Deleting an ECS service Exams of Cloud Knative architecture Load testing your app on Knative 0