问题陈述：
Rinki在StoreCraft(Say)担任站点可靠性工程师，她随时待命维护其自定义店面。 StoreCraft的系统是使用Python内部开发的，并且已经在虚拟机上运行了多年，这种设置随着StoreCraft的业务发展而发展。这些虚拟机使用的Python版本略有不同。这给Rinki和她的团队造成了额外的痛苦和工作。 Rinki正在寻找一种方法来减轻这种痛苦，方法是将所有组件更新为当前的Python，并从虚拟机迁移到更具可扩展性的内容(如无服务器)。 StoreCraft即将启动一个新的推荐引擎，该引擎使用Python 3.8(2020年的最新版本)编写。但是，它依赖于sweet-ldap软件包，该软件包尚不支持Python 3。
Rinki知道此升级将需要时间。她的团队需要确保现有系统保持运行。 Rinki将如何在GCP上解决此问题?
解决方案：
她意识到可以通过两步完成升级来最好地实现这一目标。首先，转向无服务器，然后进行语言升级。由于StoreCraft即将启动一个新的推荐引擎，该引擎使用Python 3.9编写。 Rinki认为，通过完全跳过虚拟机，这是部署无服务器的理想人选。通过查看Google Cloud上的可用选项，Rinki看到尽管可以在Cloud Functions上进行部署，但是她只能使用特定版本的Python。但是，她发现Google Cloud的最新无服务器产品Cloud Run没有此限制。
因此，她选择部署在那儿。通过在Cloud Run上创建此服务，Rinki可以完全控制容器。通过使用Docker集线器上的官方Python映像，她可以通过在Dockerfile的第一行中指定基本映像，来选择所需的确切Python版本(即Python 3.8)直至补丁程序级别。由于每个Cloud Run服务都基于自己的容器映像(每个容器映像均由自己的Docker文件定义)，因此Rinki可以完全控制设置中每个部分所使用的语言。
由于每个Cloud Run服务都具有这种隔离级别，因此Rinki可以一次将每个服务移至Cloud Run。她还能够维护在原始虚拟机上运行的服务，直到团队可以升级为止。
这对甜LDAP包，它还不支持Python 3的Rinki能够保持通过指定的最新版本的Python 2在泊坞窗文件对现已弃用运行的Python 2.7的服务如下图所示的相关性：
$ cat sweet-ldap/setup.py
...
classifiers = [
'Programming Language : : Python : : 2.7'
]
...
$ head Dockerfile
From python : 2.7.18 #finalsweet-ldap软件包具有Python 3支持后，Rinki可以通过使用Cloud Run的流量拆分功能逐步推出该服务的新修订版来测试此新版本。
她可以将计数服务的新修订版设置为仅服务5％的访问者，这样只有她的一些客户最终会使用新代码。如果她发现某些事情没有按预期进行，则可以轻松地回滚到旧版本。通过依次迁移每个服务，Rinki能够隔离地控制它们，从而实现了更多的增量升级过程和更可靠的环境。