云原生应用的成熟度模型探讨

原文作者：Jim Bugwadia

原文地址：https://dzone.com/articles/cloud-native-application

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

Level描述

我最近从开放数据中心联盟（ODCA）上阅读了一篇非常好的论文，名为“ Best Practices: Architecting Cloud-Aware Applications Rev. 1.0”。该文章提供了一些开发和运行云应用程序的原则，模式和实践，还包括这个云应用程序成熟度模型：

ODCA文章中Level划分

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

ODCA文章中提供了每个级别的额外细节，我鼓励您先阅读。以下是我在每个级别的笔记：

Level 0 - 虚拟化

这个级别的主要目标是能够方便快捷地在不同类型的虚拟机或云实例上安装应用程序。（我不确定虚拟化是否是这个级别的最佳名称;应用程序可以部署在物理服务器上运行的应用程序容器中，并且仍然可以满足此级别的所有要求。)

要考虑的最佳实践是为应用程序创建不可变的应用程序映像。例如， Netflix在构建时依托于亚马逊AMIs 。如果您正在使用像Docker这样的应用程序容器，则可以使用类似于Jenkins这样的工具来构建不可变的容器映像。

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

Level 1 - 松耦合

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

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

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

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

Level 2 - 抽象

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

在这个级别上，每个应用程序服务必须是弹性的（即可以独立于其他服务而放大和缩小）和可适应的（即具有多个实例并且可以在实例失败的情况下）。应用程序也应该被设计，以便一个服务的失败不会级联到其他服务。

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

Level 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→Level 1
• 如果您回答“是”，则从1到3的所有问题→Level 2
• 如果你回答所有问题的答案是“1”到7→Level 3
• 如果您回答“是”，则从1到10的所有问题→Level 4

概要

来自开放数据中心联盟的云应用程序成熟度模型提供了评估应用程序的原生性，了解最佳实践和规划改进的方法。虽然，我会用略有不同的级别名称和术语，但差异较小。

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

你如何看待你的应用程序映射到这个模型？很想听听你的想法和反馈！

吉姆Bugwadia 创始人兼CEO Nirmata @JimBugwadia