如何应对云应用程序生命周期的挑战？

上周我谈到了关于IT组织现在正在执行一种“和”的云计算策略，在这个意义上，它们未来的计划(最有可能)包括一个基于VMware的内部的云服务和一个外部的云服务(最有可能是亚马逊云计算服务)。

我指出，管理虚拟机的传统模式——建立一个虚拟机模板，它包含了该虚拟机所包含的所有软件组件，这种模式在一个应用被在内部，外部，或横跨内外的云环境中部署，甚至是在内外之间转移的云环境的世界中是不合时宜的。这是由于虚拟机镜像通常在部署环境间不相容。

V2C对于当今的云应用生命周期来说过时了

经常提出的一种解决方案是在一个转换过程(通常称为虚拟机到云，或V2C)中放入一个模板镜像，使它能在另一个环境下运行。然而，这个方案有两个问题。

虽然V2C对一次性的、一种方式的转化来说是有效率的，但对于镜像运行于多个地方的环境来说简直就是一场噩梦。反复转换镜像的工作是非常繁重的而且容易出错。

更具挑战性的是，转换的心理模式在如今的IT世界里越来越过时了。在转换过程背后的着眼点是带有静态软件组件的一个稳定的镜像。事实是，如今的应用都在不断发展和持续变化着。这种灵活的变化与大的，稳定的发布背道而驰，显示了一个事实，“大爆炸”式的发布理论经常产生过时的代码。

新的模型是带有少量增加功能的频繁的小代码发布。实际上，这种方法有一个名字：持续集成。这个过程让你远在迷失和平静前就能不断检查进度和快速做出改正。这种灵活的方法不利于“一次性”的转换方法。

鉴于这两个问题，注定要采用基于转换大静态模板的操作方法。简单地说，应用程序进化的速度难以忍受模板转换和迁移的缓慢步伐。

一些IT组织试图将开发与部署分离，应用敏捷开发创建软件版本，然后转移到一个传统的生产经营模式。主要思想是促进软件快速开发，并根据受过时间考验的操作原则管理产出。

DevOps带来了敏捷方法

一个简单的事实是，应用程序是被许多小组件逐渐组装成的，这些组件被聚集成一个整体，作为一个单一成品交付。开发和部署方法必须支持各个组件的不断变化并将所有组件的持续集成到最终交付。

我们需要一个在应用程序各个阶段的开发和操作方法来实现应用程序的灵活性，从而带来业务的灵活性。人们一旦接受了快速应用程序发展是无止境的，不是一个偶然的特例这一事实，这种需要就非常明显了。

云应用程序生命周期问题的解决方案是明确的：一种应用程序组装，交付和部署，可以支持持续开发和集成，且可以被IT供应链的各个部分使用的方法。

DevOps的关键特性集中在这个解决方案在云环境下应用程序组装和部署的意义——尤其是最终镜像必须能够运行在不同的云环境下的情况。

比之传统的两步法——创建一个大的模板，然后在运行环境下部署——这种方法是一个三步的过程，每个过程都有不同的工具管理。

步骤1：资源管理器

在图中，资源管理器是云编排堆栈。管理器的核心任务是自动结合或协调必要的资源，创建合适的虚拟机。例如，这个管理器协调组建了一个虚拟机，它有4GB内存，特定IP地址的网络连接和360GB的存储容量。

这个管理器安装的部分虚拟机是镜像操作系统。与传统的每个镜像包含整个软件负载的做法不同，在这个环境中，镜像是一个精简的操作环境，刚好可以启动一个基本的操作系统。这种操作环境有时被称为JeOS，全称为JustEnoughOperatingSystem。其目的是为应用程序负载提供一个运行时环境——软件包，实现云虚拟机需要提供的功能。每个部署环境，无论是内部还是外部，都会给每个必要的操作系统提供有一个精简的JeOS；例如，内部和外部的云环境，分别会有一个Windows2008虚拟机和一个RHEL虚拟机。

步骤2：配置管理器

配置管理器同时注入相应的软件包，把JeOS转化成适合的执行环境。配置管理器是这种应用程序方法的关键步骤，因为每个虚拟机的“个性”是由众多的包和配置设置组成的，为了虚拟机的正常运行，所有这些都必须正确执行。

此外，由于应用的进展频率的变化，由于应用程序的演变，更不用说由应用程序规模而产生的大量虚拟机，配置这一步必须保持一致，避免错误。如果由人来执行这一步，错误是在所难免的；使用配置管理器，这一操作完美无瑕。

配置管理器是现在IT应用商店里的热点，像Chef，Puppet和CFEngine这样的名字都挂在人们嘴边。明确一点，可以快速，反复执行的自动配置将是应对未来云应用程序生命周期挑战的核心技能。

步骤3：云管理器

云管理器是这一流程中最后一个管理器。云用户使用这个工具可以揭开整个设置过程。云管理器的主要功能如下：

一个为最终用户交互(自服务)的入口

应用程序定义(应用程序需要什么类型的虚拟机，并以此由资源管理器提供，由配置管理器设置)

应用程序部署

至关重要的是，这一层引导了部署过程，告诉其他两个管理器应用程序虚拟机将要运行在什么云环境中，还有应用程序如何在不同的服务器上部署。此外，这层控制着应用程序本身的配置——例如，与每个虚拟机联系其他服务器的IP地址。

在不同云环境间经常调整应用程序部署的需求还有一个隐含意义，就是需要一个管理工具，它可以包含部署不同云环境的需求并自动进行这一过程，隐藏它们之间的句法和语义差别。

很多人在开始考虑在云上部署应用程序时都会质疑是否需要使用云管理器。像许多其他类型的IT自动化一样，这一需要在要管理的应用程序数量从少数增加到十几个或几十个时才会变得明显。复杂的云配置极难管理，并会让许多税收业务组濒临崩溃。

正如支持复杂的服务器配置的需求产生了配置管理器，同样，支持复杂的云应用程序部署的需求也会带来对先进的云管理功能的需求。

云应用程序生命周期的一般做法行不通

上周我写道，“事实是，每一个IT组织都会有一个‘和’战略：基础设置会成为一个私有与公共云计算的混合体。对大多数人来说，这将意味着私人资源与亚马逊云计算服务的某种混合”。我总结了这种“和”混合云需求的方法的不足之处即：“解决方案必须能够为任意目标环境采用软件组件并且建立合适的镜像。创建虚拟机模板的常见方法不支持这个方案。”

对敏捷应用程序生命周期和在一个可塑的混合云环境下部署的需求，表明应用程序管理的新方法是有必要的。连接资源，配置和云管理将成为企业未来的关键。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友