2016年11月18日-20日，由CSDN重磅打造的年终技术盛会 —— “2016中国软件开发者大会”（Software Developer Conference China 2016，简称SDCC 2016）在北京京都信苑饭店隆重举行。本届大会云集了100多位国内外顶尖专家和技术大牛，共设新趋势和新实践2大主题会场，14个技术专题。面向国内外的中高端技术人员，聚焦最前沿技术及一线的实践经验，助力企业的技术升级和改造、全面提升技术人员的综合实力。
在11月18日上午的 Keynote 上，ThoughtWorks 中国区 CTO 徐昊率先发表《技术雷达之 PaaS 容器即进程，PaaS 即机器，微服务架构即编程模式》主题演讲。在过去五年里，云已经成为真正意义上的“The de facto platform”，如何在实践中真正拥抱这样一个平台的变化是整个行业都在思考的命题。我们能够看到，行业内许多所谓的云化操作仅仅只是简单的迁移替代。云和内核虚拟化存在着什么样的差异？在我们使用 AWS 等设施时，就是在使用云？而虚拟化和云之间存在的一大鸿沟就是完全拥抱云平台给我们带来的弹性。大家狂热地强调自动化部署，但对于应用而言，真正的问题是，是否能够发挥云的最大效果，能否真正利用云平台带来的好处。
大家好，很高兴今天能够在这里与大家进行分享。我先来解释一下这个题目。每隔六个月的时间，ThoughtWorks 都会把资深的技术领导者集结在一起，聆听一线工作者的声音，讨论全球技术战略、对行业有着重大影响的技术趋势与实践，“技术雷达”即由此而来。
今天，我们在行业内我们能够看到这样一个主题，Docker 会成为新的进程模型，是计算机最基础的部分。未来，整个云化的 PaaS 平台将会成为今天的单台机器一样，我们将不会考虑独立的计算机。对于这些机器这样的模式，微服务就是默认的编程模型。
接下来，我们具体分析为什么会得到这样的结论，它的演进过程是怎样的，简而言之就是看过去五年里到底发生了什么。
我们认为云已经成为软件开发默认的平台，如果是五年前，大家可能还会有所争议，但在今天已然不会。我们已经很难想象，开发一个新应用时，目标平台不是在任何一个云上，无论是公有云还是私有云。
但是，在每年的实践中，我们并没有从整体思想上真正拥抱这样一个平台的变化。当我们讨论云时，仍然会有一些比较简化的想法。我看到在行业内有些做所谓的云化操作时，仅仅是把云简简单单地去替代，将服务器迁移至云或虚拟化就算完成了。在许多所谓实施云化的方式方法中，仅仅只利用到了虚拟化。所以我们经常会面临这样一个问题——云和内核虚拟化存在着什么样的差异？是不是把所有的机器搬移至一个虚拟化的环境下，或当我们使用 AWS、华为云等设施时就是在使用云？不是这样的情况。
云化最根本的区别在于弹性
在这个过程中，它仅仅是帮助我们完成了自动化部署。在行业内大家狂热地强调部署的自动化，它们唯一帮我们做的事是讲实际的物理机器转移到一个云化的基础设施上而已。我们真正的问题，是应用本身能否发挥云最大的效果，我们的应用能否真正利用云平台带来的好处，使它获取真正的一些收益。
从行业上来看，我们很怀疑这一点，我们认为它与云之间最根本的区别在于弹性。那么，怎么理解“弹性”这件事儿？今天用100台机器，明天可以用1万台，在不需要时，可以缩减到100台，这的确是一种弹性。另外一种对于弹性的变化，来源于可抛弃性，实际上，云的弹性绝大部分情况下都是来自于它的可抛弃性。
比如在 Data Center 中，当我们想要去修改其中一台机器的配置，更新其中的一个软件、基础包，发布新项目时，因为我们是在物理机器上，没有办法提供足够的弹性。我们需要登录到机器上进行修改，大家认为这样操作天经地义，但这却是因为我们缺乏弹性造成的。如果在云化环境下，它都是虚拟化的，当我们想要升级或更新一台机器时，最简单的做法就是直接拿掉，换一个镜像，再启动一台新的机器。所以，换句话说，在今天，当我们去考虑应用部署时，对于云平台，有没有将弹性列入考量范围是非常重要的。你不能拿着老旧的编程模型放到今天的云化环境下再来使用，这样并不能得到你想要的效果。
软件过程中的不变性
当我们在做大规模部署时，不变性在软件架构上来讲非常关键。当你在云环境下，任何的机器都不要去修改它。我们一直推荐凤凰环境（Phoenix Environment），使用凤凰服务器（Phoenix Server）模式，能够以自动化的方式支持测试、开发、UAT和灾难恢复所需的新环境准备。你可以修改它背后的镜像，产生新镜像，即为重生，也正应和着 Phoenix 的“凤凰涅槃”之意。在强调了服务器和环境不变性的情况下，它充分考虑了云平台所提供的弹性。在这个时代，弹性会解决很多问题，让我们之前很复杂的事情都变得简单化。
如果我们在设计、开发软件、部署软件的过程中，没有每时每刻都去考虑云平台所带来的这种弹性的话，我们的架构并没有真正发挥它的最大潜能。这个时候，当我们看到虽然过去在四五年的时间里，云平台已经作为我们默认的部署和研发平台了，然而我们的思考问题的方式，我们的头脑里并不是真真正正 100% 云化了。
另一方面，我们看到把云的基础的运算能力带到每个人的面前，让我们获得这个计算能力变得越来越容易了，但实际上它对每个人素质技能要求变得越来越多了，你需要知道非常多的细节和功能，才能把所有的功能都来实现。所以我认为，在过去四五年的时间里软件从业者是非常辛苦的，你所掌握的关于软件的知识正在快速地淘汰，过期的阶段，而新的内容和新的知识是非常巨大的一个体量。最明显的一个效果是，当我们每次在技术委员会开会时，我们云计算每隔3-6个月，他们对于过往的实践方法都会发生翻天覆地的变化。搭建云平台的时候，都会在三五个月进行变化，这件事情太复杂了。
我们今天所面临的处境和上世纪60年代是非常相似的。如果你是那个时代的程序员，你会有什么样的想法？没有操作系统，因为系统一直到1972年才诞生，能使用的编程语言也非常有限。那么，你会做什么？
在今天，规模的复杂度已经替代逻辑复杂度成为了我们今天的首要处理的部分，我们看到很多应用在逻辑上并不复杂，但要求在一个很大量级上可用，所以我们花了很多时间，去关注底层的云平台、架构服务器等。逻辑没有那么复杂，对业务的响应度非常高，花了非常长的时间，让我们代码以更快的速度放到生产环境上去。
换句话说，我们今天做软件的时候，和60年代时有一个巨大的相似形，我们有很大的精力和内核时间，并没有花在软件复杂度上，而是被其他的一些复杂度所代替了。这是很有意思的，这是据我所知的第二次出现这样的情况，这意味着我们缺乏必要的抽象。当你看到有非常多的细节展现在面前，需要着重处理非常多的细节上，你才能把工作干完时，答案是非常明显的，我们缺乏必要的抽象、封装。我们回看一下，在60年代末做了一个什么样的封装，引用操作系统，操作系统上的封装使得我们对机器上的控制，从概念上来讲，转化成进程内存的分配，我们可以无差别的忽略下面所有的机器，只要这样在逻辑上是讲的通的，我的代码在运行上就不会有问题。在过去五年里，在第一线的使用云平台的人，我们首先需要改变的是自己头脑中看待这件问题的方法，然后才是怎么做。
即：
Stop thinking in machine, process instead!
