现今，混合IT一词常用于多场地IT桥接的言论里，但这个词是进行了过分简化的。如果深入谈论所有的混合IT，就需要谈论标准化，合规性以及如何将我们的IT方案概念化等一些艰难决策。

作为一个营销术语--"混合+一切"都是指对先前分离的两个事物的整合。混合存储阵列包括闪存和磁介质。混合WAN网络则是包含了多个连接类型的网络拓扑结构，例如MPLS和一个基于网络的传输通道。

可是到了2017年，当我们谈论混合IT时，所说的是联合内部部署IT和公有云IT。有时我们甚至可能会增加托管IT的服务提供商。不论如何，我们始终都应该了解自己说的混合究竟是哪种形式的混合。

IT已然是混合型

我们给多场地与/或多供应商的IT一个特殊的营销标签进行区分。并不是要深究标签本身，而是我们要把它看作不同的东西来特别考虑。

我们加"混合"这个词就意味着应该把多场所IT视为一个带来了巨大变化的新奇事物，尤其是在易用性方面。比如一个PDA，MP3和手机，用智能改变世界，而混合IT将会改变IT的面貌！

然而，混合IT没啥特别的，它不是你应该考虑做的事。你不需要为此制定长期计划。事实上，除了个别利基案例，混合IT是你已经在做的事情。

可能你想称其为多场地IT，多供应商IT或是混合IT。现在我们简称为IT。只做内部部署IT或公有云IT的人比较奇特。而绝大多数使用公有云，私有云和服务提供商的组合解决方案的才是常态。

也就是说，混合IT虽然常见但并不意味着它能进行有效地实践。我们仍要了解很多关于它的方式和方法。

多个通道

IT服务可分为三大类。基础设施即服务（IaaS），平台即服务（PaaS）和软件即服务（SaaS）。这三大类是众所周知的，同时也是公有云提供商的标准营销方式。

IaaS没什么特殊，一个按钮控制的接收操作系统。无论在本地，AWS或是服务提供商的云上，它都只是一个具有操作系统的虚拟机。PaaS需要多一点关注度，但除了几个版本限制，LAMP服务器就是LAMP服务器，无关提供商。

IaaS和PaaS当做一件多供应商事务，很容易能做到。如果脚本需要建立在裸机操作系统或标准化平台之上，那么哪家能提供最低成本，最低延迟与/或最佳服务就可以选择哪家。IT基础设施变成了一件真正的商品。

而SaaS却不同。传统上，SaaS是作为类似一份与SaaS开发人员签订的合同的存在，并没有论及他们所使用的平台。例如有人订阅Dropbox，但不会指定是"谷歌云平台上的Dropbox"。

但它正在开始变化。较小的供应商正在充分利用公有云，私有云和服务提供商云所提供的市场。比如Salesforce，大到足以让客户去忽略它所使用的云提供商，而记住它在所有主要的公有云上都提供了服务。

这对于那些想把所有公有云局限于一家提供商的人而言，是个好消息。SaaS提供商都在整齐划一，而且紧密集成工作负载可能产生最低延迟而且会形成单一账单费用。对于那些想要跨多供应商传输工作负载的人来说，这也是一个好消息--可能你稍一努力，基础架构提供商就能够实现所有工作负载的灵活性。

此外，我们对IaaS或PaaS跨平台功能的依赖性正在减小。

云代理

IaaS和PaaS本身并不坏。值得一提的是，旧式混合IT一直希望将本地工作负载无变化地向服务提供商或公有云提供商迁移。而在2016年初被甲骨文收购的Ravello就非常擅长此道。VMware也越来越能够通过其云产品来实现这项功能。其它供应商预计将于2017年交付。

这就为云代理创造了一个市场--第三方会根据你选择的标准找到运行工作负载的最佳位置。这些标准可以是价格，延迟，数据主权，数据位置，监管认证等。

随着供应商的价格和功能的变化，云代理商将会建议客户迁移工作负载。根据云代理商的软件与客户基础设施的深入融合程度，可能就会触发客户的工作负载迁移。

当然,我们也可以将虚拟云代理构建成一个软件。这可能会出现在客户的场地或是一个客户控制的托管实例里。它可以读取公开的数据，或从虚拟云代理软件处接收更新。虽然对于客户而言，能控制工作负载是非常好的，但可能并非最佳方案。

更直接控制客户工作负载位置的云代理商能够代表客户进行议价。虽然政府或全球五百强企业或许能够从服务提供商或公有云提供商那里拿到折扣或优惠，可中小型企业就悬了。

因此云代理商倡导成千上万的小型企业从各大规模的供应商那里拿到优惠。一些新一代"工作负载代理商"正在寻求获得异地托管型服务和内部部署基础设施的议价权力。

在超大规模提供商的世界里，捆绑才是硬道理。SaaS应用程序开始在多个平台上可用，这一点正在填补这个方案里的最后一个漏洞。消除平台排它性，将权力重新放回客户手中，而不是交给托管基础架构提供商。

标准化需求

将工作负载从A处轻松迁移到B处的能力是正确打开多场地IT游戏的首要"姿势"。作为最低限度，你需要一种从一个地方迁移到另一个地方获得数据和配置的方法。

这就有了关于标准的讨论。考虑一下迁移IaaS工作负载需要什么。最简单的方法是只将虚拟机从A地迁移到B，但这并不总是可行或者很容易。因此通常大家都是在目标基础架构上重建工作负载而非迁移。这种处理方式取决于相关的工作负载是基于模板还是基于管理程序。

基于管理程序的工作负载就是在一个空白的虚拟机里放入操作系统和代理。代理与主服务器协同查看应有的配置，安装相关应用程序，附加数据存储并应用这些配置。一切都是脚本化和自动化的。然而，如果基于程序的工作负载，每个提供商都需要一个常见的基础设施管理程序。

模板更为传统。就是你策划并建立一个模型。然后对这个模型进行复制和普及，可能运行一些克隆后的脚本会让定制化变得更容易。通常在工作负载准备好之前，需要手动干预才能完成任务。一些模板方法在最后阶段使用更类似于管理程序的方式消除手动干预。

标准化的促进作用

PaaS尝试通过消除对整个操作系统的需求来解决这一问题。但能否成功再次取决于标准化;不同供应商的PaaS产品是否也是如此呢？

SaaS应该能在不同提供商之间"正常运行"，但通常行不通。例如，线上QuickBooks和本地QuickBooks的功能之间差距巨大。一些供应商只是有不同的团队在不同的平台上设计不同的解决方案，并且随着时间的推移，这些产品会有分化。

连锁反应

除了原始工作负载兼容性和实施标准化之外，我们还需要规范治理。但由于不同的提供商具有不同的管理，监控和警报方法，问题可能会比较棘手。例如，在本地你可能要有加密所有工作负载的能力，但你需要依赖于公有云中每种工作负载的加密解决方案，并采用完全不同的密钥管理方法。

由于多场地和多供应商IT扩大了企业内部部署的覆盖范围，IT治理从仅需要担心工作负载在线与其功能而转向追踪工作负载的放置位置，数据保护和隐私影响包括其他风险和合规性的问题。

就像累积更新一样，通过更新消除大量控制，提高阻断第三方应用程序更新的可能性，而无需修复。API也是一个弱点。现在，提供商API更改可能会影响企业的大量工作负载，严重破坏应用程序集成甚至破坏加密。

适应性

如今混合IT是我们正在做的。最终，随着时间的推移而提高工作负载位置的多元化。

而通常为了最大限度地降低风险，提高效率，我们不得不开始与第三方合作，在我们的内部IT部门和业务部门之间提供一层"粘合剂"。这些第三方提供商可能是云代理商，增强了我们的议价能力，并获得一个更合算的价格。

这些第三方提供商也可能是更传统的咨询公司或渠道合作伙伴，和原来一样帮助我们--了解如何将所有这些技术结合在一起。只是现在有了更多的云和API，比以往增加了更多的不确定性。