应用虚拟化可能是一种很好的交付应用的方式，但并非最佳方式。

应用隔离可能导致功能被缩减甚至是使应用变得更容易崩溃。当然，在员工真正开始使用应用前你是不会发现这类问题的——没有人知道比用户亲自使用更好的查找应用细微性能问题的方法。

应用虚拟化引起的某些问题通常是因为特定的应用不喜欢被虚拟化，但问题也可能源自打包过程，或者是应用本身的问题。你所面临的挑战是找到问题根源，这样才知道从哪儿获取支持（提示：很可能你必须自己解决某些问题）。

应用虚拟化引起的问题之一就是你仍旧会使用安装在桌面上的本地应用，因此应用虚拟化并非交付应用的替代方式，仅仅是增加了一种新方式。

应用虚拟化并非放之四海而皆准

我并不认为应用虚拟化的前景惨淡，它有很多很好的用例。例如，以传统方式交付某些应用存在着挑战，而且这些应用能够很好地封装。其他应用需要彼此隔离，或者是这类应用不喜欢和其他应用安装在同一台机器上，或者是因为你需要同一个应用的多个版本。

毫无疑问，应用虚拟化很了不起，但人们很容易理想化以至于给自己增加了更多的工作。厂商搞清楚了这一点，这正是VMware收购CloudVolumes的原因所在。为更好地诠释其用途，该产品已经被重命名为App Volumes：分割整个应用用于部署。App Volumes为应用创建了单独的VMDK文件，并根据需要将应用附加到桌面或虚拟机中，并没有太多的技巧可言，而是直截了当地交付应用。

FSLogix几乎与CloudVolumes同时出场，采用的方式甚至比附加VMDK文件更简单：使用FSLogix App，你需要在一个镜像中安装所有的应用，并在Windows中隐藏不想要的应用程序。在这种情况下，你可以推送只允许Windows看到特定应用的策略。

我对为更易于管理与交付而对应用进行隔离非常着迷。当今世界与众不同是因为我们能够在逻辑上或物理上实现应用隔离。选择不再仅限于“应用程序流或者本地部署。”应用虚拟化有它自己的用例，但其并非是交付应用的最终方式。只有用在合适的地方才能够避免在尝试虚拟化应用时反而要做更多的工作，这类应用在本地运行可能更好。下次面临应用交付挑战时，首先问下自己应用虚拟化是否合适。如果不合适，在本地部署应用前可以考虑一些其他的选择。