作为Virta基础架构团队的软件工程师，我的工作重点是让我的队友尽可能高效地完成影响最大的工作。一家快速扩张的科技公司不断变化的需求意味着，这项工作的很大一部分涉及评估和更换我们的工具和服务，以更好地满足这些需求。
2015年，我们推出了远程持续护理平台的技术部分，HIPAA兼容的容器编排平台被调用Aptible．当时，对于Virta这样的小型医疗初创公司来说，这是一个正确的选择。apitable具有内置的遵从性，并抽象了许多我们当时不需要担心的基础设施决策。apitable还提供了一个易于使用的界面，这样我们的开发人员就可以花时间来构建我们的产品，而不是担心它是如何运行的。然而，随着我们的小型创业公司成长为一家成熟的企业，技术复杂性不断增加，我们开始失去apable的简单性所提供的有用性。当我在2020年6月加入Virta时，我们已经决定将工作负载迁移到谷歌云平台(GCP)管理谷歌Kubernetes引擎(GKE)服务。
从apable到GKE的转换有几个主要动机。在早期，apable的托管平台很好地解决了我们的复杂问题。但随着我们的发展，我们的系统变得越来越复杂，我们越来越需要自己管理这种复杂性。搬到GCP给了我们:
我们的主要目标是建立能够成功部署和运行所有工作负载的新系统，同时最大限度地减少功能开发人员学习新系统的负担。为了成功地实现我们的目标，我们首先需要设计和构建一个新系统，它类似地抽象到旧系统。一旦建立，我们必须确保这个系统被涉众完全测试和验证。最后，一旦一切就绪并开始运行，我们就需要一种安全、直接、良好的方法来将流量切换到新系统。
我们决定使用模板工具舵将我们的应用程序部署为Kubernetes对象，这有助于一致地编码Kubernetes对象。该设置有效地包括三个部分:
对于我们的应用程序，我们决定对所有应用程序使用一个Helm图(模板部分)，并完全依赖于值。Yaml文件来定义任何特定于应用程序的内容。这是有帮助的，因为我们希望从开发人员那里抽象出尽可能多的Kubernetes方面的考虑，我们不希望开发人员对Kubernetes有深入的了解。的值。yaml文件provides them with a simple interface containing all of the information specific to their application’s implementation. This design also nets us some security benefits, since only a small group of infrastructure engineers has direct code access to the Helm chart and thus the ability to create and modify objects in our infrastructure. Finally, a single Helm chart also enables us to roll out any infrastructure changes quickly, as we need to make the changes in only one place.
一开始我觉得这个项目相当艰巨。根据我之前的经验，我认为我们必须为不同的应用程序使用单独的图表，而且我们有几十个非常不同的微服务。然而，当我仔细观察后发现，大多数应用程序都不需要Kubernetes对象的特殊组合。
我们的掌舵图有3个关键特征的基线:
在Helm图中还有许多其他配置，但它们对于本文的目的并不重要。
随着特定应用程序出现更复杂的用例，这些解决方案通常适用于所有应用程序。因此，我们可以轻松地迭代和扩展图表，以推出广泛的改进。例如，我们意识到Kubernetes默认的部署升级策略会导致部署期间关键服务的容量减少，这是不可接受的，因此我们添加了一个更严格的部署升级策略豆荚中断预算，这确保我们总是有足够的服务副本。因为我们使用了单一的Helm图表，我们自动为每个应用程序获得了更严格的pod中断预算，并具有智能默认值，这可以保护我们在未来避免类似的问题。
一旦我们有了赫尔姆图表和初始值。yaml文件s added wherever necessary, we added steps to our CICD pipelines to deploy each application to our GKE stage & production clusters, in addition to our current working setup. We soon had relatively functional copies of our full system running in GKE. I say “relatively” for a reason — up to this point the infrastructure team had been doing most of the work. Like many infra teams, we don’t have particularly deep knowledge of the inner workings of our applications. We tend to rely on our feature teams for the various idiosyncrasies of configuration, which don’t always fully make it into documentation.
虽然我们的整个工程团队都知道这个迁移，但直到我们有了一个完整的副本，并需要他们的帮助进行微调时，我们才把功能团队带进来。首先，我们成立了一个工作组，每个专题小组都有一名代表，并每周举行培训和反馈会议。这些会议提供了重要的双向信息流，旨在使每个人的迁移更容易。
在培训方面，功能工程师熟悉新系统是很重要的。虽然我们很好地抽象出了kubernetes特定的应用程序构造细节，但开发人员仍然需要学习如何与系统交互以进行测试和故障排除。这包括熟悉谷歌云控制台和CLI，以及了解apable中的各种概念和功能如何映射到GCP中的等效概念和功能。在迁移之前开发这些技能对于确保平稳过渡和最小化对开发人员体验的破坏是至关重要的。
在反馈方面，作为基础设施工程师，我们没有有效测试和调试许多服务所需的应用程序的经验。特性工程师的深入知识有助于理解测试什么，因为有许多特定的工作流程已经超出了文档和自动化测试中有效覆盖的范围。在特性团队的帮助下，我们能够在这些工作流程中识别出我们甚至不知道检查的问题。一旦发现了问题，特性团队的工程师就能更好地提出解决方案。例如，如果网页的某个部分没有正常加载，那么很可能是连接到另一个微服务的连接问题。
在几个星期的过程中，我们的工作组将阶段和生产GKE集群打造成与旧系统并行运行的完全功能和测试状态。然后是割接。我们坚持我们的转换过程是渐进的，可逆的，并有良好的仪器来提供全面的遥测。作为一家医疗保健公司，在对面向用户的工作流程进行更改时，我们必须一丝不苟，因为我们的用户既是患者，也是提供者。如果我们的应用程序下降，就会危及病人的护理，从而危及安全。
为了达到我们的交接要求，我们决定放一个特使代理在主要外部端点的前面。Envoy的轻松集成蜂窝(我们的可观测性工具)为我们提供了关于进入我们系统的流量的丰富遥测数据。Envoy还允许我们设置简单的路由规则，以确定发送到一个系统或另一个系统的随机流量的百分比。最后，Envoy还能够非常快速地更改这些规则，只需一个CLI命令。
最初，我们将Envoy Proxy设置为无操作，默认情况下100%的流量路由到我们的旧系统。这允许我们仔细检查我们从代理中获得的数据，并在蜂巢中设置仪表板和查询，我们需要为切换做好准备。一旦一切就绪，在对新系统的功能进行最后检查之后，我们就发出命令。
开始时，我们只将5%的流量发送到GCP系统，持续15分钟。然后我们将其翻转回来，并花时间仔细分析来自流量的相关指标，如500速率、延迟差异和弹出的任何错误哨兵(我们的异常处理工具)一旦我们确信没有发生任何不愉快的事情，我们就把它提高到流量的15%。然后25%，然后50%。在每次流量测试后，我们会将100%的流量返回给apable，以便我们有时间解决出现的任何问题。起初，偶尔会有配置缺陷或缩放问题需要修复，但经过大约两周的严格测试后，我们有信心将100%的流量转移到GCP。我们在寒假前完成了项目的最终里程碑，所有流量都过渡到GCP。尽管我们不能亲自在一起，但我们设法以真正的远程优先方式庆祝，virta赞助的Drizly交付和真正值得的团队Zoom庆祝活动!
这显然不是我们移民故事的结尾，也不是全部。我们在apable中存储的所有数据都必须迁移到GCP中。其他工具，如RabbitMQ，也需要同样小心的迁移。Envoy代理托管在apitable中，所以最终不得不删除。然后我们必须处理删除指向apitable的引用和CICD步骤，以及弃用任何现在不相关的工具。甚至在这项工作结束之前，我们就已经从迁移中获益了。
例如，我们的RabbitMQ实例在过去是一个故障点，我们自己托管它使我们能够实现更详细的配置。现在，我们已经能够实施一些可靠性措施来加强这些系统。在我们拿下Envoy代理之后，我们强调了从谷歌Cloud Logging导出等效日志到Honeycomb，这样我们就可以维护和构建对流量模式的改进洞察。
更重要的是，我们已经在使用谷歌的一些托管服务，迁移到GCP使集成更加容易。谷歌的身份识别代理是我们用于内部应用程序的身份验证和授权系统的关键组件。我们现在也在努力利用这个身份平台进行托管外部授权。我们越来越多地使用云计算功能开始利用无服务器应用程序，以及发布/订阅作为RabbitMQ的替代方案。
作为一家医疗保健技术公司，我们特别兴奋云医疗API，并不断地将越来越多的工作负载转移到FHIR商店。我们坚信并支持FHIR标准作为互操作性的未来。我们坚持围绕FHIR开发的原则，而不是事后操纵我们的数据以适应。云医疗API为我们提供了开箱即用的功能齐全、合规且经过验证的FHIR存储，因此是我们迁移的关键激励因素。总的来说，我们对转移到GCP后所获得的服务收益感到非常满意。
接下来是什么?我们现在正在计划通过运行GCP进行进一步的基础设施投资。其中包括实现Anthos服务网改善和简化我们的网络，使自动驾驶仪优化我们的集群扩展和使用云运行扩展我们的无服务器实现。就我个人而言，我最兴奋的是实施更复杂的扩展政策，这样Virta的技术就可以继续以高增长公司的速度扩展。
