在软件工程和应用程序开发方面，云原生已经成为许多团队的常用术语。当人们调查云原生的世界时，他们经常会得出这样的观点：云原生的整个过程都是针对大型企业应用程序的。几年前，情况可能确实如此，但随着 Kubernetes 等系统周围工具和服务的进步，进入门槛已大大降低。即便如此，对由少量微服务组成的应用程序采用云原生实践会有什么不同吗？

随着云原生变得司空见惯，左移运动已深入到许多组织的流程中。左移意味着从项目一开始就专注于应用程序交付，软件工程师对交付过程的关注程度与编写应用程序代码的关注程度一样。左移意味着软件工程师了解部署模式和技术，并在 SDLC 的早期阶段实施它们。

使用云原生和微服务开发进行左移听起来像是一个包含一串当代流行语的定义，但将这些密切相关的主题结合起来确实可以带来好处。

培育部署优先的文化

流程在任何组织中都必不可少。流程被分解为多个团队可管理的任务，目的是为组织制定实现目标的有效途径。不幸的是，组织可能会迷失在流程中。团队和个人专注于尽可能好地完成任务，有时甚至过于专注于完成任务，以至于忘记了流程所定义的目标。

软件开发生命周期 (SDLC) 流程也不能幸免于此问题。团队和个人专注于尽可能好地完成任务。然而，在任何给定的组织中，如果询问应用程序开发团队的个人如何看待他们的目标，他们的回答可能包括：

• “完成故事”
• “及时了解最新的技术栈更新”
• “确保其组件符合安全标准”
• “编写全面的测试”

大多数答案都表明了对流程的承诺，这很好。但是，目标是什么？ SDLC 的目标是构建软件并部署它。无论是内部还是 SaaS 应用程序，部署软件都有助于组织实现目标。当听到 SDLC 的目标是交付和部署软件的说法时，几乎所有参与该过程的人都会说，“嗯，当然是。”团队经常忽视这个“明显”的指令，因为他们远离实际的部署过程。对该过程的战略投资可以弥补这一差距。

云原生抽象为 SDLC 中的跨学科带来了共同的领域和对话。Kubernetes 是利用云原生抽象的良好基础。Kubernetes 的实用性不仅涵盖各种形状和大小的应用程序，而且在 SDLC 方面，Kubernetes 还可以成为从本地工程工作站到整个交付周期再到生产等系统上使用的环境。将部署平台一路“左”移到工程师的工作站，让流程中的每个人都使用相同的语言，并且从流程开始就将部署作为重点。

SDLC 中的各种团队可能会对“Kubernetes Everywhere”持怀疑态度。Kubernetes 在减少边缘设备等系统占用空间方面所做的工作使得在工作站上运行 Kubernetes 变得非常容易管理。通过自动化将 Kubernetes 引入团队使他们能够迭代地吸收该平台。最重要的是建立部署优先的文化。

规划您的部署工件

当所有团队和个人都专注于尽可能高效、有效地将应用程序投入生产时，应用程序开发的演变将如何转变？这种转变是微妙的。在左移思维下，不一定有很多新任务，因此转变是任务在整个过程中发生的位置。当从第一行代码开始详细讨论应用程序部署时，现有流程可能需要更新。

构建过程

如果软件工程师要部署到他们个人的 Kubernetes 集群，他们是否能够构建和部署足够多的应用程序，以至于不依赖于在工作站之外的系统上运行的代码？除了应用程序代码之外，还有更多需要考虑的因素。是否需要数据库？应用程序是否使用缓存系统？

审查现有构建流程并重构以供工作站使用可能具有挑战性。可能需要重新审查 CI/CD 构建流程，以考虑如何在工作站上调用它。对于大多数应用程序，重构构建流程可以这样完成：既满足本地构建和部署的目标，又在现有 CI/CD 管道中使用重构的流程。

对于新项目，首先要设计工作站的构建流程。然后可以将构建流程添加到 CI/CD 管道中。本地构建和 CI/CD 构建流程应努力共享尽可能多的代码。这将使整个团队了解应用程序的构建和部署方式。

构建工件

构建过程的主要可交付成果是构建工件。对于云原生应用程序，这包括容器映像（例如 Docker 映像）和部署包（例如 Helm 图表）。当工程师在其工作站上执行构建过程时，工件可能需要发布到存储库，例如容器注册表或图表存储库。

构建过程必须了解上下文。现有流程可能已经了解其上下文，并针对从测试和准备到生产的各种环境设置了上下文。工作站构建成为额外的上下文。鉴于上下文的了解，构建过程可以将工件发布到特定于工作站的注册表和存储库。对于云原生开发，为了与本地工作站范例保持一致，容器注册表和图表存储库将作为工作站 Kubernetes 集群的一部分进行部署。随着流程从构建转移到部署，维护构建上下文包括访问当前上下文中的资源。

参数化

整个流程的核心是，构建和部署流程定义的关键组件不能基于运行时环境而重复。例如，如果容器镜像在本地工作站上以一种方式构建和发布，而在 CI/CD 管道中以另一种方式构建和发布。它们需要多长时间才会分道扬镳？

最有可能的是，它们会比预期更早出现分歧。构建过程中的分歧将导致环境之间的分歧，从而导致团队分歧，并导致部署优先文化的侵蚀。这听起来可能有点夸张，但只要任何代码分叉——没有精心计划合并分叉——代码最终就会变得无法合并。

需要对构建和部署过程进行参数化，以维护一组构建和部署组件。参数定义构建上下文，例如要使用的注册表和存储库。参数还定义部署上下文，例如要部署的 pod 副本数或资源限制。在创建流程时，倾向于过度参数化。将参数维护为常量比从现有流程中提取参数更容易。

图 1.本地开发集群

云原生微服务开发实际应用

除了部署优先的文化之外，云原生微服务开发还需要工具支持，这些支持不会妨碍工程师执行的日常任务。如果可以向工程师展示一种新的开发模式，使他们在对新概念只有最低到中等程度的理解的情况下提高工作效率，同时仍然使用他们最喜欢的工具，那么工程师就会接受这种模式。虽然工程师可能会反对或怀疑新流程，但一旦对其生产力的影响是切实的，他们就会积极采用新模式。

让开发团队轻松参与流程

改变文化就是让团队接受新的做事方式。下一步是执行。左移要求软件工程师从设计和编写应用程序代码转变为成为整个构建和部署过程设计和实施不可或缺的一部分。这意味着学习新工具并探索他们可能没有太多经验的领域。人性倾向于抵制变化。软件工程师可能会看着整个过程，想：“我如何在努力保持进度的同时吸收这个新流程和这些新工具？”这是一个合理的问题。然而，软件工程师通常很乐意采用一种新的开发工具或流程来帮助他们和团队，而不会严重打乱他们的日常工作。

无论是开始一个新项目还是重构一个现有项目，采用左移工程流程都需要引入新工具，以便软件工程师在迭代学习新工具的同时保持高效。这首先要自动化和记录新开发环境（本地 Kubernetes 集群）的构建。它还需要倾听团队的顾虑和建议，因为这将是他们的日常环境。

开发容器

开发容器规范是一项相对较新的进步，它基于支持开发环境的现有概念。许多工程团队都利用了虚拟桌面基础架构 (VDI) 系统，其中开发人员的工作站托管在虚拟化基础架构上。实施 VDI 环境的公司喜欢对环境进行集中控制，软件工程师喜欢预先打包的环境，其中包含开发、调试和构建应用程序所需的所有组件。

软件工程师不喜欢 VDI 环境的原因是网络问题，导致他们的 IDE 运行缓慢，使用起来令人沮丧。开发容器利用与 VDI 环境相同的概念，但将其带到本地工作站，允许工程师在远程连接到正在运行的容器时使用本地安装的 IDE。这样，工程师在连接到正在运行的容器时就可以体验本地开发。开发容器确实需要支持该模式的 IDE。

使用开发容器如此吸引人的原因在于，工程师可以连接到 Kubernetes 集群中运行的容器并访问为实际部署配置的服务。此外，开发容器支持一流的开发体验，包括开发人员期望在开发环境中可用的所有工具。从更广泛的角度来看，开发容器不仅限于本地部署。当配置为访问时，云环境可以提供相同的一流开发体验。在这里，容器化编排层提供的部署抽象确实大放异彩。

图 2.使用开发容器配置的微服务开发容器

云原生开发的协同演进仍在继续

左移、云原生和微服务开发之间存在协同作用。它们提供了一种可供任何规模的团队采用的应用程序开发模式。工具不断发展，使参与应用程序交付过程的所有人都能够实际使用云原生环境中涉及的技术。这是一种文化变革，需要在学习新流程和技术的同时改变思维方式。重要的是，团队不会背负一系列手动流程的负担，因为他们会觉得生产力正在下降。自动化有助于让团队轻松采用模式和技术。

与任何其他组织变革一样，提前规划和准备非常重要。让团队参与计划也同样重要。当个人在变革中拥有发言权时，所有权和采纳就会成为自然而然的结果。