本文讲的是什么是云原生应用程序，【编者的话】我们通常都会在设想什么是一个Cloud Native Appliction，这也是我们为什么不停地去测试、学习各种云服务，学习、使用docker的原因。本文介绍的云原生应用的出发点，可能和我们的有着异曲同工的地方，，可能在某些方面说的还是比较抽象，但是通过图片，我们还是可以清晰明白在非云应用往云生应用的发展框架是什么，会带来什么样的好处等等，以及如何处理好不同域间容量、数据、状态的关系。
最近，云原生应用（Cloud Native Application）这个概念又重新被大家提起来，谷歌也组织成立了云原生计算基金会（CNCF）。很多人都不明白什么是Cloud Native Application，本文中我试着向大家解释它。
用12因子应用程序的理念来解释什么是云原生应用最合适不过了。但对于很多不了解12因子的人来说，这样的解释理解起来还是会非常困难。
简单来说，云原生应用其实就是需要严格的分离架构和数据。但在我看来，我们很难清楚的划分架构和数据之间的界限。
在这里，数据是一个相对宽泛的术语，你可以理解为数据库，但它还应该包括一些配置数据。
换个角度来看，我们也可以把这种分离（界限）描述为『能力（capacity）』和『状态（state）』。我们可以用下面这副图片来解释这个概念。
请注意这两个域的特点。
基础设施中没有任何需要保存的信息。这完全是无状态的。
另一方面，承载持久化功能的域（在每一个可能的形状和形式）具有完全不同的特征，因为它需要可靠的、高可用性、持久性和。这个时候，你可能会问，它与传统的三层Web应用的区别。在我看来，云原生应用吧应用层和数据层的分离做的更彻底。
基础设施容量域
这就是虚拟机（又名实例）实时托管原生云应用的代码。他们完全是无状态的，他们是一群VM所有相同配置（基于角色）和整个生命周期的自动化。在这样一个环境中传统IT概念通常关联到虚拟机甚至没有任何意义。下面是一些例子。
- 不安装这些服务器（传统方法），因为它们是由自动生成脚本由外部事件或政策触发（如基于用户需求自动定量前端层）
- 不操作这些服务器，原因同上。
- 不记录这些服务器做什么和如何提供它们，因为代码生成文档。
- 不备份这些服务器，因为他们没有状态。如果你失去了服务器，你重新实例这些服务器，从头开始。
- 你没有这些服务器从一个地方迁移到另一个，因为同样的原因。你重新实例这些服务器，从头开始。
- 你不用云平台级别提供高可用性来保护这些服务器。没有任何保护，如果他们失败了，你重新实例服务器。
- 你不需要为这些服务规划基础设施的大小，你只需为任何给定的时间点上的消费。
你配置基础设施的本质与运行代码中的一部分一样。你听说过“基础设施及代码”的概念吗？这就是了。
现今，相当常见的看到实现这类模式被用于实现配置工具组合，然后切换到配置管理工具。
这个想法是为了提供虚拟机，让配置工具给客人创建适当的个性和角色。
AWS Cloudformations，HashiCorp Terraform，VMware Application Director，RightScale CMP这些都是专注于可编程初始化实例的几个例子。
Puppet、Chef、Ansible (等等) 是配置管理工具，专注于通过自动化确保实例融合，给定一致的配置和状态。
截至2014年底，这几乎是目前的状况（和最佳实践）。
然而几个新趋势和模式在上升。他们可能最终收敛汇聚，在某种程度上，你可以看作为一种趋势。
第一个被称为不变的工作负载。目前为止，我们已经讨论了被称为可变负载，这意味着他们的配置可以改变加班一样配置管理工具配置和重新配置他们需要让他们收敛到一个理想的最终状态。换句话说云本机应用程序当前的最佳实践建议提供一个基础模板和在操作系统核心模板，确保核心模板使用特定的配置。不变工作量的哲学表明，实例相对应的应该是不变的，如果你需要重新配置一个实例（如更新应用程序代码），你应该摧毁这个实例并重新立即部署它最新的配置到模板中。
第二个趋势是朝着简化整个堆栈包括这些工作负载。目前常见的做法是使用虚拟机作为一个占位符，用于运行时（例如AWS EC2实例或VMware虚拟机）。这些天有一所新学校的想法说虚拟机太大，太臃肿和云本机应用程序太重，容器是一个更好的方式来打包和部署云本机应用程序。我相信你听说过Docker和相关的动量（或者说是科技泡沫？）。这也很符合另一个趋势（微服务），这一个博文不够说了。
有趣的是，许多人也认为这种容器化趋势只是某个东西更大（呃，或者说更小？）的过渡。
援引：Invent 2014 AWS介绍了一项新服务，被称为Lambda云本机应用程序。这个可以允许开发人员编写代码并把代码作为数据的一部分。当数据发生变化时，事件触发代码运行。没有虚拟机，没有选择的容器，代码只是突然地运行起来。换句话说，基础设施没有简化，它只是消失了。
下图描述了图形化这一概念：
你可以想象这些概念将会话通向PaaS-ish模型。
数据和状态域
现在将自己传送到另一个维度。
转换思维。
持久性和弹性问题。很多很多问题。
有几件事，属于这个域。
最重要的一个就是在哪持有用户数据。想想传统的（关系型）数据库但也可能是一个存储库的非结构化数据（例如对象存储、NoSQL）。往往这些服务是由云提供商提供管理服务。并没有什么会阻止其他人写云本机应用程序部署和管理他们自己的数据库（关系型或非关系型），通常是利用诸如AWS RDS或AWS DynamoDB等管理服务。
这方法（有价值可选）的优点是，你有你的持久性和可靠性保证而不是花时间让自己发生。
最后，一个云提供商用一个完全自动化的方式管理成百不一定上千的实例比一个人兼DBA特别是一个开发人员，要好很多。
这些云托管服务的特点是，他们（通常）和水平呈线性比例关系。
以对象存储为例，您可以在主宰无限(或观念上的)的数据量。
想想诸如AWS DynamoDB等服务，你只需要订阅这个服务形成SLAs，云提供商将根据SLA管理所需的容量（后台）。
传统的关系数据库（尽管管理，如AWS RDS）通常不提供这种感觉无限的可伸缩性，因为他们常常向外扩展（但不超出）和基于云实例支持管理数据库大小才有的实际限制。
取决于你的选择将会有一个变量的基础设施和核心操作过程的可视性，但所有这些解决方案减轻很多负担的持久性域的可伸缩、高可用性和弹性。
第二组持久性，属于这个域的描述是基础设施，随着应用程序栈，需要部署、推广和运营。我把它叫做基础结构状态。
这样描述：
- 核心基础设施应该像什么样的（又名“基础设施及代码”）
- 实例化应用程序的存储库
- 应用程序配置。
题外话： Twelve-Factor App声明中描述将应用程序代码从应用程序配置中分离是一个最佳实践。通过这样做你可以实例化不同的环境（开发、测试、分期、生产）通过简单地指向一个不同的应用程序配置。模块化(各级)规则在云本机应用程序。
这种持久性的第二组数据和状态域可以以不同的方式实现。这可能是一个（或多个）：
- 一组AWS Cloudformations模板描述如何建模你的基础设施容量
- Puppet， Chef， Ansible， Saltstack或是Terraform，声称让你的虚拟机在运行时通过给定的配置集中起来
- 服务如GitHub托管应用程序的“代码”
注意基础设施状态只是概念上的用户数据，它们共享相同的需求（一致、可靠、耐用等）。然而这些服务可以在物理上分开。
虽然最近用一个云提供商一起把所有这些环境（基础设施容量域和数据和状态域）放在一起是相当普遍的，大家也可以认为他们是松散耦合的环境（如基础设施容量由两个云提供商，业务数据托管在第三个云提供商和基础设施状态托管在其他地方）。
让我们一起把它们组装起来
如果你试图把所有上述成更详细的图片，云本机应用程序将看起来像是这样。
在根据上述每个基础设施状态逻辑的描述实例化（和运营）每个基础设施，在运行时，应用程序部署在开始消费和交互用户数据（如数据库、对象存储等）。
这张照片缺少的（在许多其他事物）是可伸缩性这两个域的性质。这是另一个云平台的核心原则，在这篇文章中我不不涉及过多。这两种环境中可以根据外部触发自然增长和收缩（如越来越多的应用程序用户或越来越多组数据管理）。
因此应用程序所有者将根据实际的，正在被应用程序使用的，资源支付相关费用。
你今天站在哪里?
我们已经描述了一个云本机应用程序的外观。
但是，你处于什么位置？
很有可能，除非你是Netflix风格组织，你不在我所说的范围内。
很有可能你的工作负载可能看起来或多或少是这样的：
你还记得 [Pets and Cattle](http: //it20.info/2012/12/vcloud-openstack-pets-and-cattle/)的故事吗？
我不再重复了。你可以阅读一下那个博客。
还要注意为何你没有形成基础设施容量和数据之间的关系。更不用说基础设施的状态了。
95%的组织（完全编造的数字，但我觉得差不了多远）本质上是处理一群宠物，通过名字召唤，都有自己的独特的个性和状态（在本地保存），当他们死的时候你会哭的很凶。
传统的（即不是云原生的）应用程序时，您需要安装，操作，文档，备份，迁移和保护您的工作负载。这与你在云本机应用程序上做的完全相反。
除此之外，没有特定的分离容量和状态。所有工作负载的状态保存在本地磁盘上的每个实例。
在最好的情况下，状态一直备份到一个Word或Excel文档。如果（或者当？）工作负载的接近满负荷，操作员通常会手动地通过一个简单的模板根据Word / Excel“使用说明书”重装一次。
其中的一些工作负载也以数据库或文件的形式托管用户数据。他们需要额外的照顾，这很复杂，甚至以后的可靠性和可伸缩性。
一个很好的试金石：看看您正在运行的旧的应用程序或云本机应用程序是不是如下。
在周一早上11点邀请我到你的数据中心，关闭并摧毁20%的生产实例。
如果您的应用程序部署自我修复本身没有任何需要你的部分，如果有最小的不中断你的终端用户体验，那么你正在运行一个合适的云本机应用程序。
相反，如果你是像“噢，我的天你做了什么？我有一个星期的工作现在在我的面前!”这样的，所有你的手机疯狂地响了，那么欢迎来到还有剩下的95%的人的现实世界。
记住，自动化和自愈是云本机应用程序的一个重要宗旨。我记得会见过一个客户，一个应用程序（计算容量和数据）分布在数据中心的架构只为了保留一个完整的站点不中断。他们告诉我，不幸的是，如果一个数据节点坏了，它将花费数周，也许不是数月手动重建环境。如果你问我，那这不是云。
结论
还有许多其他云本机应用程序的特点，这里我不赘述了。如果你是一个高级的开发人员加入到这个行列中，你最好立刻先把Twelve-Factor App 的说明读一遍。
在这篇文章中我想笨一点方式让这些概念被更多的人明白（特别是没有云或开发人员背景的听众）。
总而言之，我认为强分离容量和状态是其中一个强大的云咒语，把大多数优势（和改变？）与传统IT相比较。
这种分离是一个在任何级别的一个真正的云的基础设施都是的核心原则。在这篇文章中，我利用一个大图提到了全部的复杂的云本机应用程序。
然而，即使你把云环境的最小的原子单元（即一个实例），分离容量和状态仍然是核心。看看亚马逊是如何描述由一个EC2实例与一对EBS磁盘（即持久的磁盘）组成的一个基本的工作负载：
在一个小得多的规模它传达了这篇文章我试图传达的同样的信息（图形化）。云中的各级模块化是核心。
题外话：具有讽刺意味的是，EC2默认为临时的磁盘，那么云本机应用程序模式（在实例级不需要状态存储）。然而，为了更好地服务传统非云本机应用程序，亚马逊引入一个EBS（单一实例级别持久性）的概念。一个可以称为在持久的磁盘anti-cloud模式的实例。我将因为这点抛弃它。
最后，正如你可能已经猜到了，在这篇文章中你所读到的关于云本机应用程序会引入其他流行语如：敏捷、DevOps、持续性开发、持续性部署和更多更多。
事实上，没有一个正确设计云本机应用程序没有办法，做到这些的。
原文链接：Cloud Native Applications (for Dummies)（翻译：李渊文）
原文发布时间为：2015-08-16
本文作者：zaburo
本文来自合作伙伴DockerOne，了解相关信息可以关注DockerOne。
原文标题：什么是云原生应用程序