为了支持遗留应用，很多生产环境包含着各式各样的技术和架构。这种复杂性导致的问题是，这个世界上没有一个人能完全了解其运作细节。每当我们对遗留应用做出一个改变，都无法预知接下来会发生什么。与这样一个复杂的环境交互完全就是一场梦魇 – 对此我们一向是尽量避而远之。这种状况同样会延误我们的工作进度。每次有人要上线新应用时，我都不得不说大概需要6个月时间——这还是最乐观的估计。

　　这种情况让我想起两个不可辩驳的事实：复杂性是敏捷性的敌人，而且还会导致风险。以我的经历而言，复杂的事情不会带来任何正面的结果。因此，我尽一切可能来避免复杂性。每天，我都尽力将IT环境简化，以此降低意外发生的概率、提升透明性并促进流程的标准化和流水化。

　　对简单化的追求无可厚非，但是有时候会和其他目标相冲突，而且和遗留系统也是相矛盾的。在过去的两年中，我们已经将一些主要的工作负载移到了云上。在所有应用都放到云上之前，总是会面临集成复杂度的问题。在云计算之前，数据交换都是发生在同一个数据中心内的应用之间。现在，数据从应用开始，经过内部网络和外部网络，最终到达SaaS、PaaS或IaaS服务商处 – 如此长的路径会带来严峻的挑战。

　　我们的第一个IaaS应用就是一场噩梦。当时，我们将一个应用放到了IaaS提供商那里，但是这个应用要和我们数据中心里的其他应用进行大量的通信。尽管我们竭尽所能，数据交换还是带了了极大的延迟，导致最终不得不把应用又迁回到数据中心 – 遗留系统主导了局面。

　　随后，我们又针对全球分支部署了一个SaaS应用 – 同样有和多个系统进行数据交换的问题，而且还要求一定的实时性。鉴于之前的教训，我们这次完全更改了架构设计。为了避免大量的点对点的集成，我们在云中部署了一个企业服务总线产品，以此作为数据的转换和集成器。这个数据交换架构特别注重可管理性、低延迟和应用的普适性。

　　至少可以说，购买产品而非自行构建，可以极大地降低项目的复杂度。更好的情况是，产品中包括了满足业务要求的数据交换功能，部分数据是实时转化和处理，其他数据则在消息队列中等候处理。这样做的好处就是，高优先级的数据交换并不占用其他数据的通道。

　　鉴于混杂云的复杂度是可以接受的，我认为这是利用SaaS、IaaS和PaaS的最为实用的方法。