Running multiple versions of Python in Cloud Run

On this edition of Serverless Toolbox, we take a look at how to deploy multiple versions of Python in Cloud Run.

Check out the video version of this blog post.

Running multiple versions of Python in Cloud Run - Serverless Toolbox (YouTube.com)

As new versions of Python are released, trying to choose between the new and shiny or the old and stable can be an issue. But if you are deploying on Cloud Run, you don't have to choose between the two, you can run both.

Imagine this hypothetical scenario: you are an SRE for a company with a custom storefront, maintaining a fleet of virtual machines running various components, all with their own versions of Python. To improve reliability, you can upgrade all the components to use one version of Python, and move away from virtual machines, and into something more scalable, like serverless.

This upgrade won't happen overnight, and the storefront must keep running in the meantime. So your plan is multi-step: migrate from virtual machines to serverless first, then make the language upgrades. But before migrating the existing systems, a new service coming online could be deployed serverless first, skipping the virtual machine all together.

When choosing which serverless platform to upgrade to, limitations may exist on the languages available. For example, a service which uses Python 3.8's assignment operators would not be able to run on Cloud Functions, which currently only supports Python 3.7.

$ python37 recommendations.py  File "recommendations.py", line 42    while (chunk := stream.read(256)) != '':                 ^SyntaxError: invalid syntax

However, the newest serverless offering from Google Cloud -- Cloud Run -- doesn't have this limitation. Cloud Run defines runs services as container images, which are defined by Dockerfiles, and can specify any base image. There is an entire repository of official Python images on Docker Hub which you can source from, by specifying the base image in the FROM line of your Dockerfile.

FROM python:2.7...

FROM python:3.8...

As you migrate each service from its original virtual machine, you can set the exact version of Python it was originally running. You can also upgrade each service in isolation, as your team has time and resources.

And if, unfortunately, you find you have a dependency on a package that doesn't support Python 3, you can ensure only that service runs the most recent patch version of Python 2.7. Note: since recording this episode, the final Python 2.7.18 version was released, thus completing the sunset of Python 2.

Once your dependencies have been upgraded and you want to test your service, you can deploy your new revision to only a limited amount of users, using the Traffic Splitting feature of Cloud Run. You can set your new revision to serve, say, only 5% of requests, so if there is something wrong, only some of your users are affected, and you can quickly rollback if there are any issues.

By migrating each service in turn, you are able to control each service in isolation, allowing for a more incremental upgrade process, and a more reliable environment.

By being able to specify the exact version of Python being used in your project, you can run multiple services each with their own isolated Python environment, which allows you more time to upgrade each service to supported versions of Python.

It also allows you to try the newest versions of Python -- such as the Python 3.9 alpha releases -- as soon as their images are available on Docker Hub.

About Serverless Toolbox

Serverless Toolbox is a fun and cheeky video series that looks at what serverless means and how to build serverless apps with Google Cloud. See the full playlist at serverlesstoolbox.com.

Follow these hosts on Twitter at @glasnt and @martinomander.