DJ亚当斯在最近的一篇文章中开始了关于cloud native的对话。看过了SAP云平台从JPaaS时代到现在的历程，我肯定已经接近了现在被称为"云原生"的原则和模式，我开始在DJ Adams博客上发表评论，时间太长了，我想把它写成一篇文章，所以我们开始吧。

在深入研究"云原生"的细节之前，让我们先来看看设置一些背景，说明为什么it对企业来说非常重要。马克·安德森，网景公司的联合创始人，现在在a16z备受尊敬的风险资本家，在写《为什么软件正在吞噬世界》时发出了号召，他提出的一个主要论点是所有的企业都将成为软件企业。你可以看到这一切的表现——越来越多的东西都有软件在里面，淘客什么意思，规模更大的公司正在通过软件推动其收入的显著增长。软件在各个行业的影响有无数的例子。twitter上的一个非常好的帖子是@SuB8u。整个帖子以及这个搜索充斥着软件中断

这样说，软件已经成为组织存在的事实，对于企业来说，有效地处理软件流程是非常重要的，即我的标题运行得更好、更快。为了理解这一点，让我们考虑一个基于DevOps工具链的现代开发工作流–

这个工具链基于当今人们、事物和企业都使用软件的互联世界对软件的期望。这可能是从订购午餐、预订住宿地点、检查供应商库存到执行自动维修等。除了始终在那里（可用性、优雅的回退）和不中断（恢复能力）的基本要求外，还有对更快响应客户需求的期望（意味着更新的功能，而不是延迟，虽然较小的延迟也是好的）。在这种情况下，让我们看看两个最重要的想法，云本地原则是从那里产生的

如果你想以最快的方式从想法走向市场，你最好有非常短的交付周期和持续的反馈周期。你可能有一个宏大的想法，但你想以一种有意义的增量方式（MVP任何人）交付它，手机网站建站，或者你想做一个大的宏大交付，但很有可能不理解客户的要求，或者他们从你开始就已经改变了。更短的反馈和部署周期也有助于降低风险。为了缩短交付和反馈周期，您需要一些概念/模式，如

按需服务，最好是代码驱动的自助服务，用于解决方案所需的服务和资源（计算、存储、数据库等）。如果您仍在等待采购订单获得批准，或者服务器交付出现物流问题，或者数据中心电源未正确配置，那么这将不会是一件有趣的事情。 您自己开发或购买的软件解决方案有自己的代码/二进制文件/工件以及许多先决条件/依赖项。如果我们有一个标准的方式来打包所有这些内容，并将它们打包成可以在任何地方（几乎所有地方）运行的格式，那就太好了。容器在这里提供帮助，它们的图像定义提供了这样的解决方案。还有很多其他好处，但这是另一篇文章的主题。持续集成和持续部署管道，将构建、测试这些工件并将其提供给适用的运行时。

我们希望以最高效和经济的方式运行我们的解决方案。这些效率可能来自易于采购/操作/弃用/升级的基础设施方面，也可能来自人力方面，即不需要大量的人力整理，大数据什么意思，具有很强的弹性或至少优雅的降级功能，以避免凌晨2点的通话。这里我们应该考虑三个概念–

活动的演变–我是由西蒙·沃德利首先介绍这些概念的，这个概念本身是基于他自己的研究，并建立在埃弗雷特·罗杰斯（Everett Rogers）的创新扩散基础上（杰弗里·摩尔（Geoffrey Moore）的《跨越鸿沟》（Crossing the Chasm）也是基于此）。这个想法是，大多数技术都经历了一个从相对未知的起源到无处不在的效用的进化曲线，如下图所示

你可以从电池到电力，电报到今天数百种通信方式，最后从Z3开始计算https://en.wikipedia.org/wiki/Z3_（计算机）云计算。软件解决方案所需的其他组件（如数据库、应用服务器）也在经历类似的演变，并作为服务或实用工具提供。在任何时候，最好（大部分）使用最新的进化论。例如，我应该从公用事业公司获得电力（Solar对此提出了挑战）还是自己生产电力，我应该建立自己的数据中心还是从云计算购买电力等等

标准化——随着任何东西在进化曲线上从左到右移动以提高效率，大数据的商业价值，你开始看到各种组件的标准化。这就是容器适合的上下文。你有一个标准的方法来打包和部署软件，包括所有的依赖关系。

编排-我们已经介绍了构建、测试和打包（CI/CD、容器）软件，以便它能够尽可能高效地运行。这个高效运行的任务属于一个叫做orchestrator的概念。这个orchestrator将我们的软件打包为一个容器并运行它，确保它继续运行。保持它运行是一个很大的部分，包括监控，确保响应时间是好的，基于操作员定义的准则，放大或缩小应用程序，提供健康检查等