本文作者戴维·高塞尔是微软全球基础设施服务数据中心架构总监。主要负责微软的技术发展方向以及该企业全球数据中心综合基础设施架构碳排量可靠性的整合。
传统设备vs. 规模云计算
由于全球各地的人们越来越依赖于云服务来充分享受他们的数字化生活，尽管在物理故障时常发生的情况下，这也使得在线服务方面的需求的增加变得日益迫切。 正如我的同事戴维·比尔在本系列文章的第一部分所介绍的那样，云服务提供商需要从传统对于复杂的硬件冗余方案的过渡依赖，转向于专注开发更多的智能软件，以便可以监控、预测，并有效地管理物理基础设施的故障。当服务可用性设计内置于更具弹性的软件时，会有利于我们反思如何设计重大的物理数据中心。
直到2008年，像行业内的诸多企业一样，微软也是遵循传统企业的IT数据中心的设计和运行方法，通过多级冗余来交付高度可用的硬件。这使得软件开发人员必须依赖于硬件随时都是可用的，或者动态数据冗余副本仅仅被认为是用于灾难恢复。而当转向通过依赖硬件的可用性之后，我们在软件方面获得了长足的发展。虽然我们在早期的模型中曾经历过某些硬件故障和人为错误，但我们最终成功地交付了高度可用性的服务。然而，当我们在我们称之为“规模云计算”方面获得显著进展时，我们很快看到了，所需的投资水平和复杂程度是站不住脚的。我们也认识到，这种软件可能会比硬件导致更重大的服务中断。
编写代码的可用性
我们今天所运行云规模数据中心仍然需要大量的硬件，但软件已经成为数据中心服务可用性的主要驱动因素。在某些情况下，其帮助我们显著地减少了对于物理冗余的需求。通过解决软件中的可用性程式，我们可以查看到物理环境的方方面面，从中央处理单元(CPU)到建筑本身。作为集成的系统同时又可以优化各个方面的工作。
通过软件开发工具和工作量的布局引擎，我们可以编写一个数据中心的可用性的解决方案，比我们安装物理冗余硬件要快得多。这种心态的转变迅速创建了复合改进可靠性、可扩展性、效率和我们在云投资组合中发展的可持续性。
在我们的数据中心，我们已经接受了这个事实，即资金的缺乏将减少硬件故障或人为错误。因为这样的服务可用性的设计必须在软件层。不管发生任何事，应用程序或服务应该很好的将故障转移到另一个群集或数据中心，同时保证客户的体验不受影响。这些故障预期将按照业务规则在一定的条件下操作，也就绝不会成为在凌晨两点将公司的CIO电话吵醒的原因了。
这种方法使我们接受了要在我们的环境中进行风险衡量，并删除冗余的基础设施的重要部分。2009年以来，我们开始提升数据中心的环境温度，使得冷水机组成为了我们重要的设施之一，这带来了用水量大巨大减少(平均只占到传统数据中心用水量的1%)以及节能效果的显著提升(平均节省了50%的能源)。同时，自2009年以来，我们还在没有使用备用发电机的情况下一直经营数万数千台服务器，即使在发生停电中断时，也保证了数以万计的用户体验。通过优化我们的应用程序集群在物理世界中不相关的故障域的大小，我们已经实现了一个小故障的拓扑结构，使我们能够区分故障并影响维护。