Get to Know Cloud Run: Easy Deployment From the Cloud

With today’s cloud infrastructures, there is a multitude of deployment options for your code and apps. From virtual servers to container services, you can choose your optimum setup from a wide range of providers and frameworks, many of them open-source.

But setup and maintenance are sometimes not as simple as you might like. Google’s Cloud Run is a fully-managed environment that offers you the simplest possible process to deploy your code. Since it is serverless, it is code agnostic and handles configuration and scaling automatically. It is suitable for a wide range of uses including websites, apps and services, as well as independently running jobs like database migrations or report generation.

In this Cloud Run guide, we’ll explore possible usage scenarios and integrations. We’ll assess its benefits as well as consider what limitations there are to serverless architectures. And we’ll give you a quick run-through on how to get started with using Cloud Run for your own projects.

What is Cloud Run?

Containerisation is one of the biggest developments in code deployment in recent years. It has aided modular applications, integrations, stability and security. But management comes at a cost.

Gone are the days when a long period of development would end in a final deployment of a behemoth application to a dedicated server – along with a heap of teething problems. Nowadays, agile coding practices mean that software and services are released early and often.

Consolidated servers have increasingly been superseded by cloud infrastructures and applications that decompose into container clusters. These isolate discrete functionalities, with bundled dependencies like libraries and configurations. Such infrastructures promote modular architectures, allowing easier scaling, failover and redeployment options.

However, it can be difficult to choose the best platform or container options. Management of container architectures can also be a full-time job in itself. Some developers utilise the power and flexibility of open source systems like Kubernetes, AWS Fargate and Azure Container Instance directly, building rapid deployment into their development pipeline. For larger projects and big software teams, we’ve also seen the rise of DevOps specialists. But can we make things simpler?

Cloud Run aims to be the simplest means of deploying your code to the cloud. It does this by abstracting away all the usual aspects of cloud and container deployment setup, allowing you to run your code directly on any part of Google’s scalable infrastructure. It is often described as ‘serverless‘: what this means is that, as a developer, you need have no concern about how the underlying service provision is structured. Serverless means no provisioning and no cluster management. Containers are created automatically as required, meaning that your code can scale automatically. It also means you pay by usage, rather than for a fixed capacity that you may or may not use.

DevOps Trends to Follow in 2023

Where can I use Cloud Run?

As a serverless environment, Cloud Run abstracts away the dependencies that might otherwise limit your deployment choices. You can use it with any language that can run in a container. If you use Ruby, Go, .NET, Python, Java or NodeJS, you can simply deploy your source code directly and Google’s platform will automatically create containers for you. For other languages, you can create your own containers.

The environment works equally well for service-based or job-based setups. Services are any kind of application that responds to requests. That means Cloud Run’s well-suited to standard hosting requirements like websites and apps, as well as microservices and APIs, whether private or public.

You can also use it to build event-driven architectures or provide streaming services. It automatically manages the traffic needs of your application, using an internal load balancer to distribute requests to available containers. If all existing instances are busy, new containers are added to the cluster automatically. They are also shut down when no longer needed.

Job-based applications are based around defined tasks like report generation, database maintenance work, regenerating search indexes and other scheduled utilities or operational tasks. Cloud Run automatically manages resources here too, allotting parallel containers to speed the processing of array jobs. Of course, this requires your scripts to be capable of splitting into discrete processes, since the containers do not communicate internally.

Cloud Run integrates with a range of Google cloud services covering database operations, file storage and much more. Integrated services include:

• Cloud Storage
• Memorystore
• Firestore
• Cloud SQL
• Cloud Spanner
• AlloyDB

It also provides direct access to Google’s Cloud APIs:

• Speech-to-text API
• Cloud translation API
• Cloud natural language API
• Vision API

Use of KNative with Cloud Run

While Cloud Run is a Google service, it is actually built on top of KNative, an open source serverless container management system. To manage containers, KNative integrates with the popular open source software orchestration platform, Kubernetes, itself originally developed by Google. Kubernetes is used to manage large-scale cloud-based container networks. KNative builds on Kubernetes to simplify deployment configuration and management into a largely automated serverless environment. KNative provides the following benefits:

• Simple abstractions. KNative uses custom resource definitions to simplify YAML config files.
• Progressive rollouts. You can split traffic across different code revisions to allow partial rollouts for beta releases or custom requirements.
• Automatic scaling. Scaling from zero to the required capacity and back again is handled automatically.
• Event handling. KNative allows you to use an event-driven architecture. You can use its APIs to create ‘sinks’ to route events from source to consumer.
• Flexible integrations. You can integrate and extend as required. Kubernetes compatibility means you can also use your own container-based setups and different platforms.

What you can do, and what you can’t do

Cloud Run’s simplicity and automation make it a good choice for many common service and app provision scenarios. With automatic scaling and redundancy, partial deployments as well as the ability to handle custom domains, it’s good for:

• Dynamic or data-driven websites using containerisable frameworks like Django or Ruby on Rails.
• RESTful services and APIs for backend use.
• Event-driven data processing tasks like invoice generation, image processing or conversions.
• Scheduled document generation.
• Scheduled scripts for routine maintenance like archiving or database migrations.
• Business workflows with webhooks.

However, there are some limitations to be aware of:

• Many benefits only apply to code that is decomposable into microservices or parallelisable components. Cloud Run does a lot, but it won’t rewrite your code for you!
• Cloud Run’s containers run as isolated instances and must listen for HTTP requests. That means the containers are stateless since there is no retention of session state between HTTP requests. This aids with modularity and scalability, but if you need to use stateful transactions, you may need to think carefully about implementation.
• Additionally, while Google’s global reach is good, they do not offer as many regions as Amazon or Microsoft.

Cloud Run guide: first steps

Before you get started, you’ll need the following:

• A Google Cloud account with billing enabled.
• gcloud CLI installed for provisioning resources.

You’ll then need to create a target configuration. This identifies where the service will be created. This is the basic format:

<code>apiVersion: deploy.cloud.google.com/v1
kind: Target
metadata:
name: dev
description: development service
run:
location: projects/my-app/locations/us-central1</code>Code language: HTML, XML (xml)

Next you’ll need a skaffold.yaml to specify service deployment, e.g.:

<code>apiVersion: skaffold/v3alpha1
kind: Config
metadata:
name: cloud-run-application
manifests:
rawYaml:
- service.yaml
deploy:
cloudrun: {}</code>Code language: HTML, XML (xml)

Cloud Run service definitions are used by Skaffold to deploy your services. Here’s what a service.yaml file should look like:

<code>apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: [SERVICE_NAME]
spec:
template:
spec:
containers:
- image: [IMAGE_PATH]</code>Code language: HTML, XML (xml)

If you prefer, you can copy your service file from an existing service using gcloud CLI:

<code>gcloud run services describe [service_name] --format=export</code>Code language: HTML, XML (xml)

Now you only have to invoke your delivery pipeline and you’re away:

<code>gcloud deploy releases create RELEASE_NAME --delivery-pipeline=PIPELINE_NAME --region=REGION</code>Code language: HTML, XML (xml)

Of course, this is only an indicative outline. For full instructions, please read the guides on Google Cloud.

Final words

In a sometimes bewildering field of options, Cloud Run offers likely the simplest of deployment environments for your code. Its powerful, serverless architecture draws on the benefits of the open source KNative to offer flexibility and scalability across a wide range of services and tasks. We hope this Cloud Run guide will help you leverage this innovative tool!