如何实现飞跃：在架构内构建云就绪应用

本文要点

• 云就绪（Cloud-Ready）！= 云原生（Cloud-Native），后者比前者要进行更多的重建。
• 云就绪的工作主要是修改部署过程，也可能要转变思维方式。
• 云管理平台（CMP）是一个辅助工具。
• 好处主要是可移植性、合理大小的云部署以及应对未来变化的灵活性，这样在处理这些老旧的应用的时候，你可以节省更多的时间。
• 大处着眼, 小处着手。不必一下子做完所有的事，那就从可控的开始吧。

在企业中，应用组合可能很复杂。 应用程序包含多样的需求和多种架构并不罕见，这些架构涉及的范围非常广，从电子邮件、维基和博客等协作项目到金融交易资产，再到人力资源的员工门户网站以及面向客户的营销网站。为了给这种多样化的需求寻找一种恰当的托管方式，我们有一种现代化的方法，那就是，在数据中心中运行一些应用程序，而其他应用程序在公有云中运行。研究表明，这样的混合云方法受到多达73％的组织的欢迎。

但这具体是什么意思呢？这些截然不同的应用直接在计算机上运行多年，而编写这些应用的开发人员早已离开公司，如何将这些应用变得云就绪（公有云或私有云）？

云就绪与云原生

云原生应用编写之初就是为在公有云上运行，通常意味着基于容器进行部署。这种架构在其初始设计中内置了水平自动扩展能力，并且通常依赖于云端衍生服务，如负载均衡器、对象存储、托管数据库和队列系统，这样它可以专注于具体任务的业务逻辑。通常，持续集成/ 持续交付工具链与这些应用相关联，因此敏捷软件开发方法可以快速地推出新的迭代。

也就是说，这不是这里讨论的那种应用。

经典的企业应用程序有多个组件，如Web 服务器、应用服务器和数据库服务器。许多应用程序最初是在客户端- 服务器时代编写的，要直接在硬件上运行它们。这些类型的应用程序尽管年代久远，但仍然可以变成云就绪的。基本上，组件通过TCP 连接使用IP 地址和端口号进行通信，通常由DNS 辅助。这些应用程序的结构丝毫不会阻碍它们在虚拟机或甚至是容器上运行，它们如果可以在两者中任意一个上运行，那么也就可以部署到任何公有云或私有云上。

虽然这样的应用程序无法像云原生应用程序一样充分利用公有云提供的服务，但有时候，经典的企业应用程序可以变成云就绪的，并从中受益，而无需完全重写。这种转变的限制因素通常不是代码，因为如上所述，代码在公有云上运行时运行的上下文不会改变。相反，限制因素往往是部署机制，而检查应用程序生命周期的这个方面就能将经典的多层企业应用程序转变为云就绪的应用程序。

你如今如何部署？

在考虑现有的客户端- 服务器时代应用程序的云就绪时，请问自己以下问题：应用程序如今如何部署？

最终要考虑生产环境，再三琢磨部署细节能了解使应用程序云就绪的难易程度。应用程序是五年前手动部署的吗，部署人员之后就退休了？这很可能表明，应用程序要变成云就绪还有很多问题。

应用程序有一套脚本来准备其Linux 或Windows 环境，然后自动安装自定义设置和依赖吗？离现在较近的应用程序有一组脚本，可以自动执行诸如准备操作系统内核和将IP 地址注入到配置文件中的任务。这些过程和（或）脚本是过渡到云部署的关键，为云就绪指明了路线。在准备这些经典应用程序时，最重要的背景知识是，上述过程如何运行。

这两种极端的中间情况是，应用程序没有自动化脚本，但是有一本运行手册，详细说明了为应用程序准备特定环境所需的步骤。尽管没有完全使用脚本的场景那么容易转变成云就绪，也没有手动案例那么难，但这种情况描绘了一个需要根据具体情况仔细审查的灰色区域。

宠物与家畜

开始云就绪之前，另一个要考虑的部署方面涉及到思维方式的改变。对于这些较老的应用程序，根据其发布的年代，物理硬件当时是一种稀缺资源。获取新硬件需要几个月的时间，这影响了应用程序架构，这种架构考量物理服务器的养护，将软件发布视为风险。因此，我们将服务器看做宠物，给它们取名字，并尽我们所能，保持它们一直运行。如果在这些宠物般的服务器上所发布的新软件引入了难以恢复的风险，从零开始重新安装一台物理机器的成本是非常高的。

相比之下，采用虚拟机的方案能够控制额外的生命周期，带来了改进应用程序部署的可能性。在虚拟机世界中，计算资源可以被视为一次性实体，而不是稀缺的资源。例如，与其花费时间来升级VM 的操作系统，不如使用新的操作系统创建一个新的VM，将其插入到负载均衡器池中，然后删除旧的VM。将VM 看做家畜，带来了诸如水平自动扩展和更快的发布周期等优点，因为计算资源的稀缺性被最小化了。

即便不是全部，但有一些遗留企业应用程序适合这种云就绪的现代化方式。具体地说，不同程度地使用负载均衡器的应用或者允许节点插入的应用都是非常适合采用这种方式进行改善的。无论如何，在云就绪过程中，了解这两种方法之间的差异非常重要。

工具

云管理平台（CMP）专门用于辅助云就绪相关的准备工作。它提供了一种机制，了解特定应用程序部署的人员可以建立一个描述每个应用程序组件以及它们如何彼此交互的蓝图或资料。

CMP 通常提供常用组件的实现，如上所示的 HAProxy、Apache 和 MySQL。想要自己实现这些层的组织可以创建自己的组件，也可以在每一层上注入脚本来自定义安装。

例如，在上面的屏幕截图中，可能需要一些自定义的 MySQL 配置，这超出了 CMP 提供的基本安装的功能范围，比如我们想在操作系统上安装特定监控或安全软件。这里就能很好地用到部署过程的知识，以确定对目前正在使用的基本组件的补充之处。

CMP 的核心优势在于，它将具体的公有云和私有云的细节抽象化，从而简化了经典企业应用程序向云就绪过渡的过程。例如，IT 人员不必成为 Google Cloud Platform、Amazon Web Services 和 VMware API 的专家，而是要努力将应用程序抽象为 CMP 表示形式。虽然可以直接使用新的云 API 编写部署脚本将应用程序变得云就绪，但如果将来选择了不同的云，那么部署脚本也得修改。通过使用 CMP 的抽象来掩盖这些 API 细节，这可以一次完成，通常比直接使用 API 的方法更省力。

好处与如何开始

将经典企业应用程序转变成云就绪，使用 CMP 最大的好处是，可移植性和易用性。更进一步，可以将水平自动扩展和蓝绿部署注入到新的部署脚本中，从而为一些应用程序提供额外的好处。一些 CMP 甚至能够针对云部署运行基准测试，以便可以正确选择每个应用程序层的 VM 大小，甚至可以使用价格和性能标准彼此进行比较。这能够确保，应用程序满足业务需求的情况下，应用程序运行在最高效的云上，同时可以使用与初次云就绪时相同的 CMP 抽象轻松地迁移云平台。

大多数公司最开始所采用的部署机制都是移植那些低需求、无复杂高可用性需求且最初的部署专家仍然在职的应用程序。这降低了首次尝试云就绪转变的风险。早期成功之后，就可以评估应用程序组合的其余部分，并排定云就绪的优先级。通常，这意味着推后需求程度高、可用性要求高或专家早已不在的应用程序。

关于作者

作为思科全球合作伙伴组织的云技术解决方案架构师，Pete Johnson 是一名有着20 多年技术行业经验的资深人士，在Twitter 上关注@nerdguru 可以联系到他。

查看英文原文： https://www.infoq.com/articles/cloud-ready-applications

感谢张卫滨对本文的审校。