什么是云原生应用程序？
我们通常都会在设想什么是一个Cloud Native Appliction，这也是我们为什么不停地去测试、学习各种云服务，学习、使用docker的原因。本文介绍的云原生应用的出发点，可能和我们的有着异曲同工的地方，可能在某些方面说的还是比较抽象，但是通过图片，我们还是可以清晰明白在非云应用往云生应用的发展框架是什么，会带来什么样的好处等等，以及如何处理好不同域间容量、数据、状态的关系。
最近有试着描述“现代应用程序”或“现代工作负载”。 Twelve-Factor App就是一个很好的尝试。
这是一个很好的方法来描述这样的工作量但我认为这些概念需要降低一个数量级使普通人正常理解他们。
这就是我想要在这个博文上做的。我们将省略一些重要的细节通过这样做但没关系。
让我直接点：在(我的意思是非常)高水平云本机应用程序是一个应用程序,该应用程序有一个明确的“基础设施”和“数据”之间的分离。至少在我看来,设计一个云本机应用程序没有画这个明确的分离。
我用数据作为一个非常松散的术语。你可能正在考虑一个“基于数据”(哪个都行)但这真的应该包括“配置”。
另一种方法来描述这种分离可能是“容量”和“状态”。不仅仅是这样。 让我们立刻开始用一幅画来描述这一概念：
请注意这两个域的特征。
基础设施容量没有你需要或想要保护的自己的状态(至少在本地存储中)。 这是完全无状态,你可以通过自动化轻松地(反复)创建它,因此,它不需要有弹性。 另一方面承载了你的持久性的域(在每一个可能的形状和形式)具有完全不同的特征,因为它需要可靠的、高可用性、耐用和这一切。
此时,您可能想知道这是如何不同与传统模式相比在3层web应用程序。在我看来，云本机应用程序在隔离传统“应用层”与传统的“数据层”将envelope推到极端。 基础设施容量域
这就是虚拟机(又名实例)实时托管原生云应用的代码。他们完全是无状态的，他们是一群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托管应用程序的“代码”
?
注意基础设施状态只是概念上的用户数据,它们共享相同的需求(一致、可靠、耐用等)。然而这些服务可以在物理上分开。
虽然最近用一个云提供商一起把所有这些环境(基础设施容量域和数据和状态域)放在一起是相当普遍的，大家也可以认为他们是松散耦合的环境(如基础设施容量由两个云提供商,业务数据托管在第三个云提供商和基础设施状态托管在其他地方)。
让我们一起把它们组装起来
如果你试图把所有上述成更详细的图片，云本机应用程序将看起来像是这样。
在根据上述每个基础设施状态逻辑的描述实例化(和运营)每个基础设施，在运行时，应用程序部署在开始消费和交互用户数据(如数据库、对象存储等)。 这张照片缺少的(在许多其他事物)是可伸缩性这两个域的性质。这是另一个云平台的核心原则,在这篇文章中我不不涉及过多。这两种环境中可以根据外部触发自然增长和收缩(如越来越多的应用程序用户或越来越多组数据管理)。 因此应用程序所有者将根据实际的，正在被应用程序使用的，资源支付相关费用。
什么是云原生应用程序
