Skip to main content

Migrating a Service to Cloud Run

One of the most powerful features of the Infrastream platform is its ability to abstract the underlying compute infrastructure from your application. This guide provides a practical example of this concept by walking you through migrating an existing service from GKE to the serverless Cloud Run platform for cost optimization.

For a deeper dive into the architectural concepts and strategic benefits of this feature, please read the Architectural Overview first.

The Strategic Benefit: Cost Optimization

Many services do not need to run 24/7. Development tools, internal dashboards, or low-traffic APIs might sit idle for hours, but on a platform like GKE, you pay for the underlying nodes whether they are used or not.

By migrating such a service to Cloud Run, you can take advantage of its scale-to-zero capability. Cloud Run automatically scales the service down to zero instances when it's not receiving traffic and only starts it up when a request comes in. For intermittently used applications, this can lead to dramatic cost savings.

Because Infrastream manages the deployment logic, this migration can be accomplished with a single line change and without any modifications to your application's container image.


Prerequisites

  • You have an existing containerized application running on a non-serverless platform like GKE or a Compute VM, defined by an Application or ExternalApplication manifest.

Step 1: The "Before" State - An Application on GKE

Let's assume you have an existing application, user-reports-api, that is currently running on GKE. Its manifest file would be located at ../application/user-reports-api.yaml and would look something like this:

# File: ../application/user-reports-api.yaml

apiVersion: lowops.manifests.v1
kind: Application
metadata:
name: user-reports-api
application-set: reporting-apps
release-track: standard-release
organizational-unit: retail-banking
organization: fincorp
spec:
source: user-reports-api-build
# The application is currently running on Kubernetes.
target: KUBERNETES

Step 2: The Migration Action - Change the target

To migrate this service to Cloud Run, you only need to make a single change to its manifest file.

Edit the ../application/user-reports-api.yaml file and change the value of the spec.target field from KUBERNETES to CLOUDRUN.

# File: ../application/user-reports-api.yaml

apiVersion: lowops.manifests.v1
kind: Application
metadata:
name: user-reports-api
application-set: reporting-apps
release-track: standard-release
organizational-unit: retail-banking
organization: fincorp
spec:
source: user-reports-api-build
# This is the only change needed for the migration.
target: CLOUDRUN

The core definition of the application—its build source—has not changed. You are simply telling Infrastream to run the exact same container on a different, more cost-effective platform.

Step 3: Commit, Review, and Merge

Commit this one-line change and open a pull request. The "plan" generated by Infrastream will now clearly show the proposed changes:

  • Destroy: The Kubernetes Deployment, Service, and other resources related to the GKE deployment of user-reports-api will be marked for destruction.
  • Create: A new Google Cloud Run v2 Service for user-reports-api will be marked for creation.

Once this change is approved and merged, the platform will handle the transition seamlessly and automatically:

  1. It will provision the new Cloud Run service.
  2. It will reconfigure the service mesh and load balancers to seamlessly shift traffic to the new Cloud Run instance.
  3. Once all traffic is safely routed, it will decommission the old GKE deployment.

Your application is now running in a serverless model, and you are only paying for the compute you actually use, achieving a zero-downtime migration.