This chapter aims to familiarize ourselves with various compute solutions and how to implement them.
We are going to cover the following main topics:
- Cloud Run
- Cloud Functions
- Infrastructure as Code
- Marketplace solutions
We will start with IaC, a stateless computing service where we can run containerized code. The next topic will be IaC, where we will learn about running code in response to events without provisioning or managing servers. Lastly, we will look at Infrastructure as Code (IaC), what benefits we can get by implementing it, and how to use IaC to deploy solutions.
Cloud Run, a managed serverless compute platform, offers easy microservice deployment without service-specific configuration. It provides a simple and unified developer experience and uses container images as the unit of deployment. With scalable serverless execution, microservices automatically scale based on incoming requests, eliminating the need for Kubernetes cluster management. Additionally, Cloud Run supports code written in any language, thanks to its container-based architecture.
Before using Cloud Run, we must learn how it works, the use cases, and its benefits.
Cloud Run is a stateless computing environment where customers can run their containerized code on Google Cloud infrastructure. Cloud Run is a regional offering that benefits us with higher resiliency and availability. If one zone fails, Cloud Run could still provide the service. Higher availability is reflected by a service SLA of 99.95% a month.
Traffic to the services is automatically load-balanced across zones within a region, and container instances are automatically scaled up and down to meet incoming traffic.
To learn more about Cloud Run zonal redundancy, go to https://cloud.google.com/architecture/disaster-recovery#cloud-run.
Cloud Run services
The main component of the Cloud Run architecture is called a service. Each service is in a specific Google Cloud region where you use Cloud Run. Each service exposes a unique endpoint and automatically scales the Cloud Run infrastructure to handle load and requests.
A service is used to run code that responds to web requests or events. Some workloads that run extensively as Cloud Run services are as follows:
- Websites and web applications
- APIs and microservices
- Event-driven architectures and streaming data processing
The following diagram shows the Cloud Run services architecture:
Figure 7.1 – The Cloud Run services architecture
A Cloud Run service includes an internal load balancer, which distributes requests to containers.
A service includes the following features by default:
- HTTPS endpoint: Every Cloud Run service has an HTTP endpoint and unique subdomain from the .run.app domain that supports custom domain configuration. It includes a TLS certificate and supports WebSockets, HTTP/2, and gRPC. All of these are end-to-end.
- Autoscaling: Cloud Run has built-in autoscaling, which allows the service to scale up from one to thousands of containers. If the service demand is decreased, the service scales down by removing idle containers. It is possible to limit the maximum number of instances.
- Traffic management: Every service deployment creates a new immutable version. Built-in traffic management allows you to route whole traffic to the latest revision, roll back a previous revision, or split traffic into multiple revisions. It allows you to test the new version and reduce the risk of deploying new, untested revisions.