本文介绍的云原生应用的出发点,还可以清晰明白在非云应用往云生应用的发展框架是什么,会带来什么样的好处等等,以及如何处理好不同域间容量、数据、状态的关系。
我们通常都会在设想什么是一个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模型。