通常，围绕云原生的对话会直接潜入诸如容器化和微服务之类的技术选择中。这些绝对是云原生项目的潜在组成部分，但绝对不是全部。在本系列文章中，我们将从几个不同的角度探讨本机云，当然包括技术和基础架构，还包括架构，设计，以及可能最被忽略的人员和流程。用最简单的术语来说，云原生意味着不仅要迁移到云，还要充分利用云基础架构和服务的独特性来快速交付业务价值。
在该术语本身开始使用之前，就已经存在云原生概念。从某种意义上说，云原生始于公共云供应商开始提供对弹性计算能力实例的轻松且负担得起的访问。问题就变成了，如何利用该新基础架构的灵活性来编写应用程序，以及由此带来的业务收益?
在过去十年中，云原生方法和技术发生了很大变化，并且仍在不断发展，但是云原生应用程序要实现的核心技术和业务目标却保持不变。这些包括：
敏捷性和生产力：实现以业务指标为指导的快速创新。降低维护风险，并使环境保持最新状态。
弹性和可伸缩性：以自我修复和无停机的持续可用性为目标。提供弹性缩放和无限容量的感知。
优化和效率：优化基础设施和人力资源的成本。启用位置和提供者之间的自由移动。
当我们回顾云原生的“为什么”时，我们将在后面的文章中进一步细分这些目标，但是希望即使是从这个简单的定义来看，也应该清楚的是，云原生的范围比仅仅向新的类型迁移还广。基础设施。但是，尽管这些目标是准确的，但很难看出它们专门适用于本机云。我们需要做更多的工作来定义云原生的真正含义。
与云原生相关的流行参考点(例如微服务)和较早的清单(例如12factor应用)可能会让您得出结论，云原生是对体系结构样式的描述，其他选择也随之而来。毫无疑问，云原生架构确实存在。但是，为了在云原生平台上取得成功，公司必须采取更全面的看法。除了架构和基础架构决策外，还存在组织和流程决策。这导致我们实现了一个关键的实现：
单凭技术无法取得业务成果下图显示了这些决策如何相互作用。
单凭技术无法取得业务成果
我们的文章“避免使用不完整的云原生采用”中描述了如何将这些方面相互链接以及有关链接断开时发生的警告的一个很好的示例。在本系列文章中，我们将展示云原生的成功如何与这三个关键领域的变更协调相关联，以便成功进行协调：架构与设计，技术与基础架构，人员与流程。让我们更详细地探讨每一个。
技术与基础设施：在“云原生”的背景下，“云”是什么?十年或更早之前，“云”一词主要是关于位置的。它通常指的是位于可通过Internet访问的其他人的数据中心中的基础结构。但是，今天的“云”更多地说明了您如何与该基础架构进行交互。确实，位置元素几乎消失了，因为现在很常见的是在您自己的数据中心中运行类似云的设施-“私有云”，以及可能涉及在两者之间运行的服务和工作负载的混合解决方案。
因此，今天的云更多地与您如何与基础架构互动有关，至少必须提供以下内容：
自我配置：即时获取新的虚拟资源(服务器，存储，网络)。
弹性：根据需求自动向上和向下扩展资源(及其相关的成本)。
自动恢复：资源旨在从故障中恢复而无需干预，并且对服务可用性的影响最小。
但是，随着云平台和概念的日趋成熟，云原生云实际上也意味着对基础架构的更大抽象。
不变的部署-例如基于容器映像的部署
声明式配置-提供基础状态的“基础架构即代码”
与运行时无关—平台将组件(例如容器)视为黑盒，而无需了解其内容
组件编排—通过通用的声明性策略和配置启用管理(监视，扩展，可用性，路由等)。
在云原生的早期，这些功能通常是高度专有的，但是现在，这种功能几乎以容器和容器编排功能(例如Kubernetes)的形式无处不在。因此，上面的列表非常特定于容器的词汇表，但是值得认识到还有其他选择，例如无服务器/作为服务的服务会进一步从基础结构中抽象出来，并且将来可能会变得更加突出。
我们可以包括更多内容，例如构建自动化，服务网格，日志记录，跟踪，分析，软件定义的网络和存储等。但是，我们随后将涉足云平台当前更具专有性的方面。希望随着时间的流逝，这些也将变得更加标准化。因此，在这种情况下，“云”实际上表示具有上面列出的特殊属性的基础架构和技术。
架构与设计：“云原生”中的“原生”是什么意思?郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。
