AWS Fargate vs Google Cloud Run

In this article, we will do a comparison of AWS and Google Cloud services with respect to the following concerns regarding cloud applications:
Some concerns while developing cloud applications:

Container image storage
Serverless containerized app deployment

Q) What are some of the most used services on Amazon AWS?

Some of the most commonly used AWS services include:

Amazon EC2 (Elastic Compute Cloud): Virtual servers in the cloud, allowing users to run applications and services.
Amazon S3 (Simple Storage Service): Object storage service for storing and retrieving data.
Amazon RDS (Relational Database Service): Managed relational database service supporting multiple database engines.
AWS Lambda is a serverless computing service that lets us run code without provisioning or managing servers.
Amazon VPC (Virtual Private Cloud): Networking service that allows you to create isolated sections of the AWS Cloud where you can launch resources.
Amazon CloudFront: Content delivery network (CDN) service that securely delivers data, videos, applications, and APIs to customers globally.
Amazon IAM (Identity and Access Management): Service for securely controlling access to AWS services and resources.
Amazon Route 53: Scalable domain name system (DNS) web service designed to route end-user requests to globally distributed endpoints.
Amazon ECS (Elastic Container Service): Container orchestration service for Docker containers.
Amazon DynamoDB: Fully managed NoSQL database service for applications that need consistent, single-digit millisecond latency.
Amazon SQS (Simple Queue Service): Fully managed message queuing service that enables decoupling of the components of a cloud application.
Amazon CloudWatch: Monitoring and observability service for AWS resources.
AWS Elastic Beanstalk: Platform as a Service (PaaS) for deploying and managing applications.
Amazon Kinesis: Real-time streaming data service.
AWS Glue: Fully managed extract, transform, and load (ETL) service.

Q) EC2 vs ECS comparison?

Deployment Model:

EC2: It provides virtual machines (EC2 instances) that we can configure and manage as per our requirements. We have full control over the underlying infrastructure and need to manage the operating system, runtime, middleware, and application.

ECS: It is a container orchestration service that allows us to run and scale Docker containers. ECS abstracts the underlying infrastructure, and we only need to manage the containerized applications, while AWS takes care of the underlying EC2 instances.

Resource Management:

EC2: Requires manual management of instances, including scaling, patching, and monitoring. We can install containers, virtual machines, or any other software on EC2 instances.

ECS: Manages the underlying infrastructure for us. It automatically places containers on the available instances, handles scaling, and integrates with other AWS services for monitoring and logging.

Scaling:

EC2: Requires manual scaling, either vertically (by changing instance types) or horizontally (by adding or removing instances from an Auto Scaling Group).

ECS: Provides built-in support for auto-scaling based on the desired task count

Q ) What is a security group in AWS?

In Amazon Web Services (AWS), a security group is a fundamental component of the networking infrastructure that controls inbound and outbound traffic to instances (virtual machines) within an Amazon Virtual Private Cloud (VPC). It acts as a virtual firewall for our instances, allowing us to define traffic flow rules.

Q) What are tasks and services?

Tasks represent the individual containers and their configurations, while services manage the deployment, scaling, and orchestration of these tasks within the ECS environment. ECS services provide a higher-level abstraction for running and maintaining tasks, ensuring that the specified number of tasks are always running and handling tasks’ lifecycle events.

If our containers are added to the same AWS ECS task, they will run on the same machine.

Q) What is AWS Cloudwatch?

1. CloudWatch Container Insights provides monitoring and troubleshooting capabilities for containerized applications orchestrated by Amazon ECS (Elastic Container Service) and Kubernetes.

2. CloudWatch collects and stores data in the form of metrics. Metrics represent a time-ordered set of data points and can be related to various AWS resources such as EC2 instances, RDS databases, S3 buckets, and more.

Q) What is a cluster in AWS?

In Amazon ECS (Elastic Container Service), a cluster is a logical grouping of container instances or tasks within a specified region. It acts as a container management environment where we can deploy, manage, and scale containerized applications. ECS clusters provide a way to organize and isolate our containerized workloads.

How does Google Cloud Run differ from AWS Fargate?

Similarities:

Google Cloud Run and AWS Fargate are serverless computing services, so developers can focus on writing code without worrying about the underlying infrastructure.
Both services use containerization to package and deploy applications.
Both services support Docker containers as the deployment format.
Both services can automatically scale up or down based on demand.

Differences:

With AWS Fargate, users need to configure and manage the container orchestration, such as Kubernetes, whereas, with Google Cloud Run, container orchestration is managed by the platform.
Google Cloud Run is a standalone service, while AWS Fargate is the provisioning service for container services, either Amazon ECS or Amazon EKS.
In AWS, a combined integration of AWS Fargate and the orchestration service, such as Amazon ECS or Amazon EKS, is required to deploy the serverless containerized environment. In Google Cloud, we can use only Cloud Run.

There is only one container image per service in the cloud run. Cloud Run copies and stores the container image locally to ensure that containers on Cloud Run start reliably and quickly.

Autoscaling

Cloud Run automatically increases capacity when necessary to ensure it handles all incoming requests. Every service has an internal load balancer that distributes requests over the group of available containers. It adds or shuts down containers as demand fluctuates
Cloud Run will route a maximum number of requests at the same time (concurrently) to the same container. We can visualize this with request ‘slots.’ Cloud Run does not send a new request to the container if all slots are in use until a slot frees up. When no requests come to the service for a while, Cloud Run shuts down all containers. A fresh container will start on-demand as soon as a new request comes in. This process is attractive for economic reasons because we are not paying for idling containers.
Cloud Run charges for usage, startup, and shutdown: Idle containers do not incur charges. We are charged for container time, not request time.
The lifetime of a container is only guaranteed while the container is handling requests. When a container handles no requests, the CPU is throttled to nearly zero. This means that our application will run at a languid pace. Because Cloud Run shuts down and throttles idle containers, we should complete all work before we return the HTTP request.
Cloud run is built using the following open-source project:

GitHub - knative/serving: Kubernetes-based, scale-to-zero, request-driven compute
Kubernetes-based, scale-to-zero, request-driven compute - GitHub - knative/serving: Kubernetes-based, scale-to-zero…github.com

Differences

Q) How do to store, organize, and rapidly deploy our application code in Google Cloud?

In AWS, we can use AWS CodeCommit. In Google Cloud, the answer is Cloud Source Repositories.
Suppose we have already got our code in GitHub or BitBucket repositories. In that case, we can bring that into our cloud project and use it just like any other repository, including browsing and diagnostics.
We can monitor and report repository activity through Cloud Logging. Repository activity is automatically logged.

Q) Cloud Functions vs AWS Lambda ?

A function in AWS Lambda can have multiple triggers. A function in Cloud Functions can only have one trigger, but multiple functions can have the same trigger.

Q) What is the Difference between cloud events and triggers?

Cloud events are things that happen in our cloud environment. These could be changes to data in a database, files added to a storage system, or a new virtual machine instance being created.

Events occur whether or not we choose to respond to them. Creating a response to an event is done with a trigger. A trigger is a declaration that we are interested in a particular event or set of events. We create triggers to capture events and act on them.

The fine-grained, on-demand nature of Cloud Functions makes it a perfect candidate for lightweight APIs and webhooks.

Cleaning up

While Cloud Run does not charge when the service is not in use, we might still be charged for storing the built container image.