通常，围绕云原生的对话会直接潜入诸如容器化和微服务之类的技术选择中。这些绝对是云原生项目的潜在组成部分，但绝对不是全部。在本系列文章中，我们将从几个不同的角度探讨本机云，当然包括技术和基础架构，还包括架构，设计，以及可能最被忽略的人员和流程。用最简单的术语来说，云原生意味着不仅要迁移到云，还要充分利用云基础架构和服务的独特性来快速交付业务价值。
在该术语本身开始使用之前，就已经存在云原生概念。从某种意义上说，云原生始于公共云供应商开始提供对弹性计算能力实例的轻松且负担得起的访问。问题就变成了，如何利用该新基础架构的灵活性来编写应用程序，以及由此带来的业务收益?
在过去十年中，云原生方法和技术发生了很大变化，并且仍在不断发展，但是云原生应用程序要实现的核心技术和业务目标却保持不变。这些包括：
- 敏捷性和生产力：实现以业务指标为指导的快速创新。降低维护风险，并使环境保持最新状态。
- 弹性和可伸缩性：以自我修复和无停机的持续可用性为目标。提供弹性缩放和无限容量的感知。
- 优化和效率：优化基础设施和人力资源的成本。启用位置和提供者之间的自由移动。
当我们回顾云原生的“为什么”时，我们将在后面的文章中进一步细分这些目标，但是希望即使是从这个简单的定义来看，也应该清楚的是，云原生的范围比仅仅向新的类型迁移还广。基础设施。但是，尽管这些目标是准确的，但很难看出它们专门适用于本机云。我们需要做更多的工作来定义云原生的真正含义。
与云原生相关的流行参考点(例如微服务)和较早的清单(例如12factor应用)可能会让您得出结论，云原生是对体系结构样式的描述，其他选择也随之而来。毫无疑问，云原生架构确实存在。但是，为了在云原生平台上取得成功，公司必须采取更全面的看法。除了架构和基础架构决策外，还存在组织和流程决策。这导致我们实现了一个关键的实现：
单凭技术无法取得业务成果
下图显示了这些决策如何相互作用。
单凭技术无法取得业务成果
我们的文章“避免使用不完整的云原生采用”中描述了如何将这些方面相互链接以及有关链接断开时发生的警告的一个很好的示例。在本系列文章中，我们将展示云原生的成功如何与这三个关键领域的变更协调相关联，以便成功进行协调：架构与设计，技术与基础架构，人员与流程。让我们更详细地探讨每一个。
技术与基础设施：在“云原生”的背景下，“云”是什么?
十年或更早之前，“云”一词主要是关于位置的。它通常指的是位于可通过Internet访问的其他人的数据中心中的基础结构。但是，今天的“云”更多地说明了您如何与该基础架构进行交互。确实，位置元素几乎消失了，因为现在很常见的是在您自己的数据中心中运行类似云的设施-“私有云”，以及可能涉及在两者之间运行的服务和工作负载的混合解决方案。
因此，今天的云更多地与您如何与基础架构互动有关，至少必须提供以下内容：
- 自我配置：即时获取新的虚拟资源(服务器，存储，网络)。
- 弹性：根据需求自动向上和向下扩展资源(及其相关的成本)。
- 自动恢复：资源旨在从故障中恢复而无需干预，并且对服务可用性的影响最小。
但是，随着云平台和概念的日趋成熟，云原生云实际上也意味着对基础架构的更大抽象。
- 不变的部署-例如基于容器映像的部署
- 声明式配置-提供基础状态的“基础架构即代码”
- 与运行时无关—平台将组件(例如容器)视为黑盒，而无需了解其内容
- 组件编排—通过通用的声明性策略和配置启用管理(监视，扩展，可用性，路由等)。
在云原生的早期，这些功能通常是高度专有的，但是现在，这种功能几乎以容器和容器编排功能(例如Kubernetes)的形式无处不在。因此，上面的列表非常特定于容器的词汇表，但是值得认识到还有其他选择，例如无服务器/作为服务的服务会进一步从基础结构中抽象出来，并且将来可能会变得更加突出。
我们可以包括更多内容，例如构建自动化，服务网格，日志记录，跟踪，分析，软件定义的网络和存储等。但是，我们随后将涉足云平台当前更具专有性的方面。希望随着时间的流逝，这些也将变得更加标准化。因此，在这种情况下，“云”实际上表示具有上面列出的特殊属性的基础架构和技术。
架构与设计：“云原生”中的“原生”是什么意思?
“原生”是指我们将构建的解决方案不仅要“在云上运行”，而且要特别利用云平台的独特性。应用程序不仅神奇地继承了底层云基础架构的优势，还必须教会他们如何操作。
在这里，我们需要非常小心地使用语言。当我们使用“原生”来指“云平台的唯一性”时，我们并不是指特定云提供商的特定于供应商的方面。那将是“云提供商本机”，实际上，这将完全与围绕可移植性和使用开放标准的目标背道而驰。我们的意思是概念上所有云平台都通用的东西。换句话说，我们在上一节中有关基础结构和技术的内容中强调了这些内容。
对体系结构和设计有重要影响。我们需要编写解决方案以确保例如它们可以水平缩放，并且可以与自动恢复机制一起使用。在这里，云原生可能与微服务概念重叠最多。例如，这包括编写以下组件：
- 最小化状态
- 减少依赖
- 具有定义明确的界面，
- 轻巧
- 是一次性的
在下一篇文章中，我们将对它们进行更深入的描述，但是到目前为止，可能要注意的最重要的一点是它们都是高度相互依赖的。例如，如果要创建具有高度状态的一次性组件，则要困难得多。减少依赖关系从本质上将有助于使组件更轻便。具有明确定义的界面将使可抛弃的组件更容易重新实例化，依此类推。这只是一个更广泛点的小例子，即迁移到云原生方法需要同时在许多相关方面进行更改。我们逐渐发现的这些云原生成分是相辅相成的。
人员和流程：“云原生”如何改变我们的组织和工作方式?
可能不太明显的是，当我们使用有关架构和底层基础结构的上述假设和决策时，它为我们提供了从根本上改变我们处理人员和流程方式的机会。的确，可以认为必须进行这些更改。
下面，我们探讨了微服务方法对人员/流程的影响：
- 微服务意味着您是在小型自治团队中构建服务。这只是Conway定律的应用-如果您希望系统由小的，解耦的组件组成，则必须允许您的团队规模较小，并且不能与其他团队紧密耦合-仅允许通过定义明确且受控接口。
- 微服务还意味着您正在使用敏捷方法并将DevOps原理应用于开发流程。如果没有，您将如何获得端到端的反馈以及对代码的快速迭代，这是该方法的核心优势。反过来，DevOps将意味着进一步的流程改进，例如持续集成和持续交付/部署(CI / CD)。
- DevOps要求您采用其他特定的技术流程，例如自动化测试(可能包括测试驱动的开发)，并强烈引导您进行基于主干的开发。最小化测试周期的渴望可能会进一步导致您探索改变人们与工作相结合的方式(例如，结对编程)。
同样，容器技术也会影响所需的技能，角色和流程：
- 云基础架构通常使用诸如Kubernetes知识之类的通用云平台技能，而不是特定的运行时或产品技能，在操作(部署，扩展，高可用性等)上实现更多目标。这从根本上减少了跨多个技术领域工作的人员的学习曲线，并实现了更广泛的角色和知识共享，从而提高了效率并降低了成本。它还鼓励现场可靠性工程师转向尽可能使操作任务自动化。
- 容器，特别是容器映像技术，简化了CI / CD管道的自动化，从而缩短了构建/发布周期时间，并提高了生产率。构建管线实现方式的同质性提高意味着可以更轻松地维护它们，并且确实可以由更广泛的人群使用。
- 不变的容器映像与声明性的“将基础结构作为代码”结合使用，可以提高跨不同环境的部署的一致性。这降低了测试和诊断成本，提高了部署速度，并减少了停机时间。从过程的角度来看，这可以实现可靠性，性能和安全性测试等方面的“左移”。反过来，这又带来了更多的DevOps / DevSecOps文化，在这种文化中，开发人员对代码的操作质量负有更大的责任。
总结“云原生”的含义
综合到目前为止所讨论的内容，我们可以看到需要从三个不同方面定义云原生。
- 抽象化基础架构复杂性的平台。(基础设施和技术)
- 充分利用基础架构抽象(架构和设计)的解决方案
- 开发，运营和业务流程的自动化，以及开发团队(人员和流程)的自主权不断提高
今天，技术方面当然非常关注容器化，但是重要的是诸如该技术的自我配置，弹性和自动恢复之类的属性，而不是该技术本身。
在体系结构上，我们最常使用微服务原理来创建更轻量，细粒度，状态最小的组件，从而更好地映射到抽象基础架构。没有正确的设计原则，我们的解决方案将无法从该平台中受益。例如，它将不会动态扩展，也不会提供细粒度的弹性，不会提供快速的构建和部署，也不会与平台上的其他应用程序保持操作一致性。
人们通常将人员和流程更改与云原生隔离开来，但实际上它们是并驾齐驱的，我们认为它们是定义特征的一部分。缺乏软件开发生命周期的自动化将意味着团队需要花更多的时间在平凡的事情上，而花在商业价值上的时间却相对较少。繁重，自上而下的组织和治理结构将无法为团队提供帮助他们进行业务创新所需的自主权。
因此，有了对云原生实际含义的更具体定义，我们就可以开始下一步，并扩展之前的图表。
在上图中，我们提供了有关这些方面的关键要素的一些信息。在本系列的后续文章中，我们将考虑“如何”构建云原生解决方案，并从人员和流程问题入手详细研究每个要素。
但是，应该已经很清楚，完全采用云本地化并非易事，并且需要业务赞助。因此，在另一篇文章中，我们将汇总我们所学到的有关成功实现云原生所需的承诺的知识，并退后一步来重新考虑“为什么”您可能首先使云原生移动，以及什么?您可能希望实现的好处。
