How we migrated from GKE to CloudRun and saved Infra costs

GKE to CloudRun

Little Background about our Application

  1. Set up own Kubernetes cluster in VM’s (Similar to production and UAT environments).
  2. Leverage CloudRun as the runtime for our containers.

Migration Strategy

  1. Evaluation
  2. Deployment
  3. Routing
  4. Validation
  5. Automation
  1. Technical feasibility
  2. Will it really give cost saving
  1. It cannot support websockets
  2. Persistent memory is not available.
  1. Average number of parallel requests
  2. Peak load and average load
  3. Response time of requests (90 percentile and average)
  4. CPU utilization of the services in GKE cluster
  1. Use NGINX or Apache web server to route the requests based on patterns
  2. Use API gateway
  1. Apigee
  2. Cloud Endpoints
  1. Install OpenESP image on cloud run and migrate to ESPV2 beta as detailed in the link here
  2. Create a YAML file confirming OpenAPI version 2. You might need to provide the cloud run endpoint of the OpenESPV2 created in the above step. Configure each service corresponding to the request pattern and map them to the appropriate cloud run backend.
  3. Deploy the configuration in the cloud endpoint by giving the command and providing the YAML file. Note that, even after the deployment as well, you might get URL patterns not matching. Fix it by following all the three steps (i.e service deploy, new image building and deploying the new image)as mentioned in this link
  1. Created a new subdomain and pointed the subdomain to the cloud endpoint URL
  2. Test the new subdomain
  3. Once all the functionality is working, we can make changes to the CNAME record to point to the new endpoint. Cloud run gives a detailed tutorial on using custom domains. That can also be followed to configure the cloud run specific to the Open ESPV2 to use the new custom domain name. In case if updating CNAME is not possible, then map the old domain to a static IP. In the static IP run a webserver (Apache or Nginx). In the webserver, you can have the request forward and redirect rules.

Results

Is Cloud Run suitable for all Needs

Is Cloud Run suitable only for Lower environments?

  1. Runtime and network architecture of your lower environment is different from prod. I would recommend having at least one environment (e.g UAT or Performance) with similar architecture like prod so that issues seen in production or which are likely to happen in production can be caught early.
  2. Note that CICD pipeline for dev cannot be used for other environments. If your higher environment CICD scripts just take the image from the repository and deploy it, then it should not be an issue. If it is doing something more, then note that you do not have any lower environment to test them in case of any changes to the CICD pipeline.

Few things which could have been better

  1. CloudEnpoints does not provide a web interface to create a new mapping or atleast to view the mappings currently deployed. This could have been done to make quick PoC’s and validation easier. Though I could understand that Google wanted to enforce script and configuration driven setup from day 1, UI at least to view the mappings can help in troubleshooting. From this perspective, I like the Azure API gateway.
  2. Though the cloud endpoints list the services, the operational metrics (number of requests, response time, response codes etc) are not displayed in CloudEndpoints page.They are available only in the cloudrun dashboard of the service corresponding to Open ESP2.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store