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
ApplicationorExternalApplicationmanifest.
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-apiwill be marked for destruction. - Create: A new Google Cloud Run v2 Service for
user-reports-apiwill be marked for creation.
Once this change is approved and merged, the platform will handle the transition seamlessly and automatically:
- It will provision the new Cloud Run service.
- It will reconfigure the service mesh and load balancers to seamlessly shift traffic to the new Cloud Run instance.
- 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.