云本机应用程序成熟度的模型

云本地应用程序是为了能在云基础架构上最佳地运行而构建的。云本地应用程序体系结构与为数据中心设计的传统分层应用程序非常不同。在本文中，我将讨论来自开放数据中心联盟（ODCA）的成熟度模型，用于评估应用程序的云本地性。

云本地应用程序成熟度模型

我最近从开放数据中心联盟（ODCA）上阅读了一篇非常好的论文，名为“ 最佳实践：构建云感知应用程序1.0版”。该篇论文提供了一些开发和运行云应用程序的原则，模式和实践，还包括这个云应用程序成熟度模型：

云应用程序成熟度等级

来自：http://www.opendatacenteralliance.org/docs/architecting_cloud_aware_applications.pdf

这篇ODCA论文提供了针对每个级别的额外细节，我推荐您先阅读。以下是我对每个级别的笔记*：

等级0 - 虚拟化

这个级别的主要目标是能够方便快捷地在不同类型的虚拟机或云实例上安装应用程序。（作为一个侧边栏 - 我不确定以”虚拟化”这个词来命名这个级别是否最合适;应用程序可以部署在运行于物理服务器之上的应用程序容器中，并且仍然可以满足此级别的所有要求。）

要考虑的一个最佳实践是为应用程序创建不可变的应用程序映像。例如，Netflix支持在构建时生成AMI。如果您正在使用像Docker这样的应用程序容器，则可以使用像Jenkins这样的工具来构建不可变的容器映像。

如果您的应用程序是多租户的，那么您可能需要为此级别的每个租户运行单独的环境。如果您正在从传统的应用程序交付方式迁移到“软件即服务”，那么这样做是有道理的，但是应该将其作为中介目标。

等级1 - 松耦合

在此级别，应用程序与底层基础架构基元分离，所有主要应用程序组件（或层）应该彼此分离。

一个好的第一步是将您的应用程序从存储和数据管理层中分离出来。这可能还包括配置数据，日志等。如果应用程序是多租户的，则应该在租户之间共享您的数据层。

下一步往往比较困难，就是将应用程序和网络结构分离开来。目标是使用命名服务，而不是依靠IP地址和端口。这可能只是跨层的DNS，或者将IP地址和端口作为部署的一部分（这适用于静态应用程序组件）或服务命名，注册和发现方案。

例如，Nirmata.io内置了服务命名，注册，发现，负载均衡和路由，这些功能可以使应用程序与底层网络完全分离。其他工具，如 Zookeeper， Etcd和 Consul.io ，也可用于构建服务注册和发现。

等级2 - 抽象

要达到这个级别，应用程序必须与基础架构完全分离。像Docker这样的应用程序容器提供了一种将应用程序组件与基础架构分离的方法，但这还不够。您还需要抽象应用程序蓝图，部署策略，扩展策略，关联和布局规则等。

在这个级别上，每个应用程序服务必须是可伸缩的（即，可以独立于其他服务而放大和缩小）和可复原的（即，具有多个实例并且可以在实例失效发生时存活）。应用程序也应该被设计，以便一个服务中的失败不会级联到其他服务。

微服务类型体系结构是这个级别的应用程序体系结构的一个很好的例子。在微服务体系结构中，应用程序由多个服务组成，每个服务的设计都是可伸缩的，可复原的，可组合的，最小的和完整的（请参阅微服务：5个架构约束）。

等级3 - 适应性

在这个级别，应用程序能够以全自动的方式检测或预测变化并对其做出反应。例如，Netflix使用预测性自动缩放算法。

作为最佳实践，您还需要将应用程序管理和控制功能与应用程序本身分开，或者使用外部应用程序控制服务（如 Nirmata或 AWS Auto-scaling服务）。

ODCA论文还谈到了跨供应商的动态迁移。我同意这是一个很好的目标，但是，现在的现实是，每个云提供商的协议栈是相当不同的，这需要掌握重要的技能和运营专业知识。

像Docker这样的应用程序容器迅速变得如此流行的原因是它们克服了缓解云端可移植性的挑战。容器是是非常重要的构建模块，但仍然是整体难题的一小部分。还有很多其他的问题需要跨供应商才能真正地实现应用程序的可移植性。在Nirmata，通过提供与云无关的应用程序操作和管理服务，我们正在解决一些挑战。

云本机测试

Andrew Spyker（曾服务于IBM，现服务于Netflix平台团队）曾经提到使用一组问题来评估应用程序体系结构。我认为这是一个好主意，并试图将每个成熟度等级映射到一组问题：

1. 您能在几分钟内重新部署你的整个应用程序吗？
2. 您的应用程序是否依赖于不属于自动化安装的特定IP地址，端口，文件系统？
3. 您的应用程序能否存活并自动从基础架构（计算，网络，存储）故障中恢复？
4. 您可以升级和降级你的应用程序（或应用程序的一部分），而不会对用户造成任何影响吗？
5. 您可以在同一个环境同一时间运行多个版本的应用程序服务吗？
6. 您能在生产中安全地测试吗？
7. 如果一个应用程序的一部分失败，其他部分是否会继续运行？
8. 基于用户负载或其他因素，应用程序的某些部分是否可以自动放大和缩小？
9. 您能否跨云提供商部署应用程序组件？
10. 您能否在不同的云提供商上部署应用程序组件？

评分：

• 针对 问题1 ，如果您回答“是”→级别1
• 针对 问题1 到 问题3 的所有问题，如果您回答“是”→级别2
• 针对 问题1 到 问题7 的所有问题，如果您回答“是”→级别3
• 针对 问题1 到 问题10 的所有问题，如果您回答“是”→级别4

总结

来自开放数据中心联盟的云应用程序成熟度模型提供了评估应用程序的云本机性、了解最佳实践和规划改进的方法。尽管我可能用了略有不同的级别名称和术语，但差别不大。

请记住，该模型仅评估应用程序的成熟度。要成功，您还需要构建DevOps文化。也许我们也需要一个DevOps成熟度模型？

若将你的应用程序映射到这个模型，你觉得怎么样？期待听到你的想法和反馈！

Jim Bugwadia

Nirmata 创始人兼CEO

@JimBugwadia