云环境下的软件开发需进行重新思考

编者注：此文是Eucalyptus Systems CEO Marten
Mickos的文章。

软件自出现以来模式就未曾改变：运行应用，然后应用则是在平台上面跑的。但是由于基础设施的飞跃发展，应用设计和部署的基础原则的确会不时改变—有时候这种变化还很激烈。

比方说，1980年代出现PC、x86架构的出现以及客户机/服务器模式的诞生令应用应用设计原则发生了巨大的改变。然后，随着web和开源技术在1990年代中期的出现又再次剧变。每每发生这种巨变，开发者都被迫要对软件的开发和部署方式进行反思。

现在的基础设施能力又有了新的飞跃，其主导是Amazon Web Services（尤其在网络速度有了飞跃提升的前提下）。显然，为了能够充分利用新的云设施，那些在AWS上取得成功的应用必须与运行在企业服务器上的应用有着本质的不同—哪怕是与运行在虚拟服务器上的应用也不一样。除此以外，还有其他一些因素决定了云应用在设计上必须与过去有所不同。以下列举的就是其中一些关键因素，这些因素也决定了新旧世界演变的方式：

伸缩性

旧世界的伸缩是通过扩容实现的—要想容纳更多的用户或数据，只需购买更大对的服务器。

而在新世界里，伸缩性通常是通过横向扩展实现的。要增加的不是更大的机器，而是同类的多台机器。在云世界中，那些机器是虚拟机。

弹性

以前，软件是不可靠的，弹性是在硬件层实现的。

今天，底层的基础设施硬件被视为是薄弱环节，所以应用必须自我调整来适应。应用并不会保证每一个虚拟机实例都工作正常。单台虚拟机一段时间失效也没关系，应用必须对此做好准备。

就拿Netflix来说吧，这可以说是最先进的云用户了，它在云应用的道路上迈出的步伐是最远的。他们有一个过程叫做ChaosMonkey，会随机地杀死应用负载下的虚拟机实例。这么做的目的是什么呢？就是为了确保应用的正常运转和弹性：通过让应用面对随机的实例损失来迫使应用开发者开发出更加弹性的应用。

爆发性

在旧世界里，像财务和工资单这样的应用其负载一般都是很稳定和可预测的。特定时刻的系统用户数、待处理记录数基本上都是已知的。

在新世界里，工作负载是多变的、不可预知的。今天的软件系统的触角必须伸得更远，要到达有服务需求的消费者和设备那里，时间不可预测，负载无法衡量（想想看那个成为众矢之的的12306网站吧）。要想适应独立应用负载这些不可预见的波动需要新的架构。虽然我们现在已经在云上面了，但是显然还处在初级阶段。

软件多样性

在过去，软件并没有太多的多样性。每一款应用都是用一种语言编写的，使用的是一种数据库。公司一般都是依托与一个或少数几个操作系统。软件栈简单到令人乏味的地步（至少从现在看是这样的）。

而在云的新世界里，情况截然不同。一个应用里面可能就会用到许多不同的语言，不同的库，不同的工具包以及不同的数据库产品。同时由于在云端时你能够创建和启动自己的镜像，根据特定需求进行定制，一家公司的应用必须能够运行在各种不同的配置上。

从虚机到云

哪怕是相对较新的hypervisor和现代的云思维方式之间也是有区别的。虚拟化的的先锋和领袖VMware所开发的hypervisor表现基本上与物理机器并无二致。

而在云端，虚拟的并不是物理服务器的代表，而是计算单元的代表。

用户的耐性

在旧世界，用户受到的教育是要有耐心。因为系统的响应可能需要很长一段时间才能完成一些简单的提取或更新请求，新功能的添加也很缓慢。

在新世界里，用户是没有耐心的。他们几乎无法容忍时延，不愿意等待。他们希望软件经常更新，如果说不是每天的话，起码也是每周。你可以在自服务IT找到相关证据。在那里，你不是递张条子给IT部门然后等待几天后回应了事，用户所需的资源可以实现自提供。