CloudVolumes是在2014年8月份被VMware公司收购的一家公司，这家公司专注于应用交付技术，VMware收购CloudVolumes之后，将该公司的技术整合到了自己的 End UserComputing技术框架中，并且更名为 App Volumes。为 VMware Horizon 产品的用户提供了降低系统基础环境要求和管理费用的能力。
笔者在学习一种新的技术的时候，基本是带着如下几个问题去学习的： 是什么，什么时候用，谁来用，如何用，也就是what,when,who，how。本系列博客也基本上覆盖了这几个方面。
App Volumes允许企业根据需求将原生的程序传递到用户的虚拟环境中。App Volumes可以协助虚拟机器的管理与更新，能在几毫秒或几秒内递送程序和资料到无数的虚拟机器上，让企业更容易更新程序与虚拟机器；同时App Volumes能无缝整合至企业既有的虚拟架构中，不需置换储存、网络、虚拟机器或hypervisor。这里要强调一下，App Volumes的使用场景是基于用户已经实现了数据中心的虚拟化，如果用户还是使用单独的PC，目前是不能使用到App Volumes提供的强大的能力的。
传统的虚拟系统的架构如下图左所示，在操作系统之上，数据，文件以及应用和操作系统都是紧密耦合在一起的。而App Volumes的体系则改变了这一架构，新的架构如下图右所示，AppVolumes在操作系统之上引入了App Volumes一个适配层，传统的数据，文件以及应用都被包装成单独的模块，通过App Volumes的适配层与底层操作系统组合起来。通过这种方式App Volumes可以将一个原本整体的虚拟机转化为一个模块化的虚拟机。现在每个组件都可以共享或进行换入换出。应用程序继而可以方便和快捷地被加到虚机系统里。 App Volumes 能够允许包含多个虚拟机系统环境中的文件、数据和应用被快速稳定地分配到不同的虚拟系统中，帮助服务器和数据中心的管理者更快捷地分配管理服务器间的工作负载。
系统管理员不必再为了安装程序或更新而专门协调停机时间段。新的应用程序或更新现在能够以完全透明的方式被交付到一个正在运行的、有用户登陆的桌面上。由于虚拟化操作处于系统的上层，应用程序无需修改即可以在本地配置。应用程序从底层的操作系统被抽象出来，再以应用管理容器的模式组织起来，充分利用现存的存储和网络。这些应用程序继而可以被实时交付到不同的环境里。
图1. 传统虚机系统和AppVolumes体系对比
在我们了解了App Volumes体系架构以后，那我们来看一下App Volumes的使用场景。通常的场景下，如果用户要在属于自己的虚机环境中安装应用，用户或者是IT管理员，需要一个一个的虚机环境中手动安装每一个应用，这将是一个费事，重复的活动。当然如果用户使用了类似VMware的Horizon View中的floating pool之类的技术，管理员是可以通过更换模板来批量更新虚机的应用的，但是这种方式却缺少应用管理的灵活性，例如有些虚机或者用户可以使用某些应用，另外一些虚机或者用户使用不同的应用。
而App Volumes却可以同时实现高效率和精细管理。在使用App Volumes的时候，IT管理员需要对IT应用有一个全盘的规划（备注，这对IT管理员提出了比较高的要求）。如下图2所示，根据公司的业务，将公司要使用到的应用划分为核心应用，财务应用，市场应用等等。我们看一下一个虚拟的使用场景，当一个员工加入到市场部以后，IT管理员就可以将两个应用集合 核心应用和市场应用分配给该员工，该员工登陆到自己的虚机环境后，就可以立刻看到市场部常用的应用了。当由于业务调整，该员工需要有某种角色的变化，从市场部调入了财务部，该员工需要有一个工作环境的变化，原有的市场部应用应该从他的桌面环境中移除，同时增加财务部的应用。这时候IT管理员只需要简单地在App Volumes的服务器端将市场应用到该员工的分配删除，同时分配财务应用到该员工。如果目前核心应用有了新的版本，IT管理员也可以同时将一个核心应用2分配给该员工，这些变化都是可以瞬间发生的，员工甚至都不需要重启机器，在IT管理员做完调整的瞬间就可以看到这些应用的变化。
图2. App Volumes应用规划
这篇博客基本上覆盖了App Volumes的基本概念以及使用场景，也就是what,when的问题。后续的博客我会继续介绍App Volumes关于who和how方面的知识。
关于作者：Sam Zhao，EUC解决方案经理。在软件开发，测试，项目管理方面有13年IT从业经历，发表过三个专利以及合著书一部。
