避免不完全的云原生（五）：目标和收益

在以前的文章中&＃xff0c;我们已经明确了云原生的“什么”和“如何”。可是&＃xff0c;还有一个更大、更根本的问题还没有解决。为什么大家要关心这个问题呢&＃xff1f;有了前两篇文章的背景知识&＃xff0c;我们现在可以探索“为什么”并看看云原生的好处&＃xff0c;先从它对业务的意义开始&＃xff0c;然后再讨论它对 IT 的意义。

云原生方法的好处

从业务角度看云原生方法的目标和收益

让我们面对现实吧&＃xff0c;IT 潮流一直在发展变化。许多业务团队试图超越这些潮流&＃xff0c;让 IT 人员自己走自己的路——毕竟&＃xff0c;应用服务器或语言运行时的选择通常对业务的运作方式没有太大影响。云原生有什么特别之处&＃xff1f;为什么业务部门应该支持向云原生迁移&＃xff1f;为了理解这个问题&＃xff0c;我们需要从一开始就考虑几乎所有企业都必须关注的三件事&＃xff1a;增长、降风险和降成本。我们认为&＃xff0c;使用云原生方法构建应用程序有可能为所有这些方面带来好处。

市场增长

市场增长的关键在于发展新客户并保持他们的兴趣。为了赢得新客户&＃xff0c;而又不损害边缘客户的利益&＃xff0c;你必须能够比竞争对手更快地把好的、新的想法推向市场。诸如采用精益方法和通过管道自动化简化生产环境部署等因素&＃xff0c;使团队更快地将业务想法带到生产环境。这缩短了上市时间&＃xff0c;帮助 IT 部门按照业务的速度推出新特性。不过&＃xff0c;新特性本身并不能保证市场增长。你必须能够剔除那些对客户留存和客户获取产生负面影响的新特性&＃xff0c;同时保留那些对这两个指标产生积极影响的新特性。真正关键的是确保创新就绪&＃xff1b;让企业可以大胆而迅速地将颠覆性的想法带入生活&＃xff0c;从而获得新的细分市场&＃xff0c;在竞争中保持领先&＃xff0c;同时制定适当的衡量标准&＃xff0c;让你能够根据经验来判断哪些想法好&＃xff0c;哪些想法不好。

降风险

然而&＃xff0c;新特性并不是业务需求的全部。如果一个企业能够通过不断提供新的、令人惊叹的功能来取悦它的客户&＃xff0c;那么我们的工作就会简单许多。现实更为复杂和困难&＃xff0c;但也非常重要。客户需要信任你的企业。当然&＃xff0c;这在监管严格的行业&＃xff08;如金融服务或医疗保健&＃xff09;最为明显&＃xff0c;但对所有企业而言都很重要。你提供的解决方案需要有适当的弹性和安全性&＃xff0c;让客户可以相信&＃xff0c;他们需要的时候你能提供服务&＃xff0c;他们信任你&＃xff0c;将资金、数据或生活都托付给了你。

正如我们在前一篇文章中所介绍的&＃xff0c;写得好的云原生解决方案会利用抽象将自己与底层物理基础设施解耦&＃xff0c;从而提供隐式的弹性。此外&＃xff0c;其组件还遵循零信任模型&＃xff0c;因为它们必须假定组件可以部署到任何云环境中。然而&＃xff0c;我们越是关心风险&＃xff0c;就越有可能设置变革障碍&＃xff0c;这不利于市场增长。在这里&＃xff0c;云原生可以通过高度自动化且一致的方式将特性投入生产&＃xff0c;从而帮助降低风险&＃xff0c;通过部署信心减少对更改的担忧。

然而&＃xff0c;云原生方法本身并不能神奇地降低风险。像特性标识和金丝雀测试这样的技术可以让业务人员做一些他们之前可能会因为风险太大而拒绝做的事情&＃xff0c;但为了发挥这些技术的价值&＃xff0c;需要 IT 与业务人员密切合作。我们必须与业务合作&＃xff0c;更新他们度量和控制风险的方式&＃xff0c;使其与引入的方法和流程兼容。

降低成本

没有企业可以忽视成本。不管你的市场份额多大&＃xff0c;或者你的客户多信任你&＃xff0c;如果你不能控制成本&＃xff0c;就不能指望获得稳定的利润。企业是由人来经营的&＃xff08;至少如今是这样&＃xff09;&＃xff0c;而雇人需要花钱。我们需要确保人尽可能少&＃xff0c;而回报尽可能高&＃xff0c;对于那些技能水平最高的人来说更是如此。构建云原生解决方案的平台应该标准化&＃xff0c;并尽可能地自动化软件构建、部署和管理等日常任务。这有助于充分发挥高价值员工的作用&＃xff0c;让他们可以专注于直接增加业务价值&＃xff0c;而不是陷入日常运营。当然&＃xff0c;这些平台及其底层基础设施也需要付费。幸运的是&＃xff0c;按照设计&＃xff0c;云原生解决方案只使用它们需要的资源&＃xff0c;因此&＃xff0c;你应该利用平台提供的弹性成本模型&＃xff0c;让自己能够利用这种成本效率。

从 IT 角度看云原生方法的目标和收益

到目前为止&＃xff0c;关于云原生对业务的影响&＃xff0c;我们的讨论还停留在比较高的层次上。为了让业务人员理解云原生的好处&＃xff0c;我们必须将我们讨论过的 IT 收益翻译成相应的业务收益。接下来&＃xff0c;我们将展示上面描述的每项关键业务收益与我们之前介绍的云原生要素的对应关系。

敏捷性和生产力&＃xff08;市场增长&＃xff09;

每个业务都想从 IT 那里获得更多的特性——他们还希望 IT 能更快&＃xff0c;而且要更准确地反映他们的需求。云原生如何帮助实现这一点呢&＃xff1f;

更快的组件交付

加速交付是云原生方法最常见的目标&＃xff0c;其核心包括三个方面&＃xff1a;云平台、敏捷方法和微服务。借助弹性分配和组件编排等技术&＃xff0c;云平台使我们可以通过自动化来简化大部分的日常操作&＃xff0c;专注于构建业务功能。通过减少体力活&＃xff0c;让团队专注于价值更高的工作。敏捷方法使我们能够缩短需求和实现之间的距离&＃xff0c;并改进与业务目标的一致性。这意味着返工会更少&＃xff0c;并且能够更快地发现和纠正错误。微服务之类的设计方法使我们能够以增量的方式交付功能&＃xff0c;减少依赖关系&＃xff0c;因此速度也更快。

可以自由创新的自治团队

细粒度的离散组件带来的其中一个结果是&＃xff0c;为创建它们的团队提供了更多的自主权。只要遵循我们前面描述的关键解耦规则&＃xff0c;接收平台就可以在很大程度上将组件视为“黑盒”。虽然应该鼓励跨团队协作和公共实践&＃xff0c;但是团队可以自由地使用任何语言运行时和框架来满足他们的需求。这种创新的自由让团队可以“跳出固有的思维模式”&＃xff0c;更快地向业务交付解决方案&＃xff0c;而且交付的解决方案在业务方面更具创新性。这种自治的一个关键是&＃xff0c;业务必须是自治团队的一部分。产品负责人和发起用户&＃xff08;Sponsor User&＃xff09;这两个概念对构建高效的创新型团队至关重要。

对不断变化的商业环境的快速响应

早些时候&＃xff0c;我们讨论了如何创新&＃xff0c;以及如何通过具体的经验性指标来确定创新是否有价值&＃xff0c;这对于确保 IT 团队和业务保持同步至关重要。在这方面&＃xff0c;其中一个关键是业务和 IT 通过假设驱动开发共同工作的能力。简单地说&＃xff0c;假设驱动开发是将企业经营理念作为科学假说来表述&＃xff0c;可以被证明或证伪。云原生开发只有在业务参与整个开发周期时才会给业务带来好处。

一种主要的参与形式是借助 A/B 测试——如果你制定了适当的指标&＃xff0c;比如清空购物车的百分比&＃xff0c;或者在浏览后点击“购买”的客户百分比&＃xff0c;那么你就可以根据经验来比较不同的想法。你可以引导一些客户使用体现新理念的新方法&＃xff0c;而另一些客户使用现有方法&＃xff0c;然后随着时间的推移比较两种方法之间的指标差异。这里的关键是&＃xff0c;需要业务根据可度量的差异来思考问题。就像一个科学假说如果不能被证伪就不能成为假说一样&＃xff0c;业务假设也是如此。业务必须帮助确定一个可量化的衡量标准&＃xff0c;通过它可以比较两种不同的想法或方法。也就是说&＃xff0c;他们必须参与整个过程&＃xff0c;不仅帮助确定哪些想法需要接受测试&＃xff0c;而且帮助确定如何测试&＃xff0c;以及成功的定义是什么。云原生非常适合赋能这种响应行为。它是敏捷方法的重要组成部分&＃xff0c;而且&＃xff0c;使用细粒度、良好解耦的组件添加新功能更安全&＃xff0c;不会影响现有的功能。此外&＃xff0c;服务网格之类的通用机制可以用来选择性地在被测想法之间路由请求&＃xff0c;还可以简化假设评估的数据收集。

弹性和扩展性&＃xff08;降低风险&＃xff09;

云平台&＃xff0c;特别是容器&＃xff0c;从其底层基础设施继承了许多抽象。这就为支持非功能需求&＃xff08;如可用性、健壮性、性能和安全性&＃xff09;提供了通用且风险较低的方法。下面是一些典型的例子。

细粒度的弹性伸缩和弹性

写得好的云原生解决方案是用细粒度、轻量级、状态最小化的组件构建。这使得云平台能够根据需要快速复制和清除组件&＃xff0c;从而提供固有的健壮性和可伸缩性。得益于容器化&＃xff0c;我们可以用一种标准化的方式提供&＃xff0c;从而大幅简化操作。此外&＃xff0c;容器编排平台能够跨多台物理服务器、多个区域分发容器实例&＃xff0c;进一步提高了可能的弹性水平。

一致的环境和可逆的部署

为了实现上文讨论的敏捷性和生产力&＃xff0c;我们需要能够自信地将新代码交付到环境中&＃xff0c;安全地重新路由流量&＃xff0c;并且在必要时以最小的代价逆转那些部署。在理想情况下&＃xff0c;云原生代码应该在包含所有依赖项的不可变镜像中交付&＃xff0c;并包括完整的声明式部署指令。这可以确保部署过程和工件在所有环境中都是相同的&＃xff0c;从而消除了环境漂移的风险。此外&＃xff0c;云平台的特性&＃xff0c;如路由器和服务网格&＃xff0c;使代码能够在全面推出之前进行金丝雀测试&＃xff08;少量负载通过新代码&＃xff09;。这也简化了版本的回滚&＃xff0c;因为我们可以简单地恢复到上一个版本的镜像和部署指令。这种简单性对业务来说很重要&＃xff0c;因为它向业务人员保证&＃xff0c;如果结果不符合预期&＃xff0c;就可以快速安全地回退。

软件运行时的持续采用

敏捷方法规定&＃xff0c;通往生产环境的路径必须尽可能地自动化&＃xff0c;这包括构建、测试和部署等方面。这些管道通常被称为持续集成/持续交付&＃xff08;CI/CD&＃xff09;&＃xff0c;由于对源代码的更改而触发。然而&＃xff0c;由于声明式部署也是代码&＃xff0c;底层运行时版本的改变也会触发新的构建/测试周期——这就是“GitOps”的一个例子。假设我们对自动化测试有足够的信心&＃xff0c;我们就能够保持底层运行时版本比如今大多数应用程序的都新&＃xff0c;这不仅能确保我们可以利用最新的特性&＃xff0c;而且可以保证我们不会暴露在已知安全漏洞造成的风险中。同样&＃xff0c;这对企业来说应该也是有价值的&＃xff0c;因为它降低了客户数据或资产丢失的信用风险。

优化和效率&＃xff08;降低成本&＃xff09;

基于云的计算使我们能够共享资源&＃xff1a;硬件、软件&＃xff0c;甚至人。通过跨应用、跨组织域、甚至跨组织共享这些资源&＃xff0c;我们有机会降低运营成本。云原生可以确保编写的应用程序能够从这些优化中获得最大收益。

一致的基础平台技能

在那些显而易见的特性&＃xff08;轻量级可伸缩组件&＃xff09;之外&＃xff0c;容器还有一个更难能可贵的地方。长期来看&＃xff0c;它们最大的好处可能是运营一致性。使用完全相同的技能来构建、部署&＃xff0c;提供高可用性、伸缩性、监控、诊断和安全&＃xff0c;而不需要考虑一组已经编排好的容器中的运行时&＃xff0c;这是一个巨大的飞跃。至少&＃xff0c;这意味着技能集可以跨以前孤立的 IT 领域通用。在理想情况下&＃xff0c;操作自动化会减少运行特定基础设施所需的人员数量&＃xff0c;并提高其可靠性。然而&＃xff0c;由于这些技术都是新的&＃xff0c;个人和公司必须经历一个陡峭的学习曲线&＃xff0c;才能使这些好处成为现实。

优化基础设施的使用和许可

可以说&＃xff0c;“云”的最基本定义是对底层物理基础设施的抽象。虚拟机为我们提供了第一级的间接层&＃xff0c;我们因而不再被绑定到物理机器中的特定硬件上。如果将容器与云原生要素&＃xff08;如最小化状态、不可变部署等&＃xff09;结合起来&＃xff0c;我们就能走得更远。云原生使我们能够在无形之中将组件分布在多个数据中心的许多机器上&＃xff0c;为实现规模经济提供了更大的机会。当然&＃xff0c;软件许可需要有新的模型以及可能更复杂的动态计量来迎接这个挑战。

资源和能力的快速自助配置

自助配置是云技术的关键承诺之一&＃xff0c;它允许我们快速请求虚拟计算、内存、存储、网络等资源。容器平台对此做了进一步的抽象&＃xff0c;它允许在部署时对资源进行声明式请求&＃xff0c;并设置策略&＃xff0c;定义如何在运行时根据负载对它们进行更改。只需一次单击&＃xff0c;就可以创建全新的环境&＃xff0c;并通过软件定义网络与其他环境隔离。为了充分利用这一切&＃xff0c;应用程序就需要采用一种不同的编写方式。应用程序需要是无状态的、可抛弃的、细粒度的&＃xff0c;实际上&＃xff0c;我们在本系列中已经讨论了所有这些内容。

总结

云原生&＃xff0c;就像大部分方法方面的重大变革一样&＃xff0c;需要一定程度的投入才能实现目标。正如我们所看到的&＃xff0c;这需要许多不同的要素都准备到位。对于许多&＃xff08;也许是大多数&＃xff09;组织来说&＃xff0c;他们可能无法从一开始就把所有这些要素都安排到位&＃xff0c;所以成功的关键是确定优先级。

选择对你而言最重要的好处。我们希望本系列文章可以帮助你确定&＃xff0c;应该优先专注于发展哪种要素。

- END -

往期回顾

◆避免不完全的云原生&＃xff08;四&＃xff09;&＃xff1a;技术和基础设施角度

◆避免不完全的云原生&＃xff08;三&＃xff09;&＃xff1a;架构和设计角度

◆避免不完全的云原生&＃xff08;二&＃xff09;&＃xff1a;人员和流程要素

◆避免不完全的云原生&＃xff08;一&＃xff09;&＃xff1a;云原生到底意味着什么&＃xff1f;