最近阿里的ACE下线了，又一个PaaS的生命周期要走到末路。
3年前，是VMware Cloud Foundry这个PaaS从如火如荼到全体解散，并移交Pivotal。
Google的GAE日子也没有那么好。只是自己内部部署应用用了那么多年，也不会轻易因此倒下。
云上的日子，目前还是Amazon独占鳌头，只是人家是IaaS。
首先说一说docker吧。作为container的后起之辈，从cgroup，lxc，warden中脱颖而出，或许很大程度上要归功于对aufs的使用。
docker image借助文件系统分层化，使得软件的交付变得更加统一。不管什么时候，拿来image都可以很好的运行封装的app。唯一的缺点就是，build一个image交付的app比原来的占的空间要大出不少。这里就简单介绍下目前的虚拟化技术，从CPU的指令级虚拟化，到VMware ESXi，VirtualBox，Qemu－KVM，Bochs等这样的模拟硬件级的虚拟化，然后到系统库级虚拟化（Cygwin在Windows上模拟Unix环境，WineHQ在Unix上运行Windows程序），再者就是应用级的虚拟化（比如python的virtualenv）。而container虚拟化可以说是介于硬件虚拟化和系统库级虚拟化之间的，它在系统内核层面将资源分组并利用系统库级虚拟化让app正确运行，或者我们可以给它个分类叫“系统资源级虚拟化”。这里也简单说明了为何docker image交付的app要比原来大出不少：因为要封装好一整套系统库（比如glibc，libssl，libpnd…）和app本身。
那么IaaS和PaaS有什么区别呢？通俗了说，IaaS就是把你要的计算资源统统都交给你，你自己管理自己控制比如部署自己的app；而PaaS是你把app交出来，放到一个黑盒子里运行。所以在这一点上，PaaS是对dev开发者很不友好的；但是PaaS对ops运维还是很方便的，我根本不用管app怎么配置，dev开发好给我直接扔进去就可以运行了。所以总体来说，dev还是不太喜欢使用PaaS的。比如Cloud Foundry，app部署了，我连个具体可访问的ip都拿不到（这里的ip是指host ip，当然一个app是可以有一个固定的内网ip的，比如172.17.0.100），这出了问题怎么去调试？对于目前很多互联网公司，开发迭代快，测试不周全，质量低的代码拿到PaaS上真的是要够折腾的。所以PaaS的接受度大打折扣。
这几天在思考应用的HA和DR，总结了一下kubernetes＋docker的使用，发现要打造好PaaS，还需要dev的编程观念有所改变。
那么我们先来看一看几个IaaS和PaaS搭建app HA方案的比较。IaaS的app HA方案还是多种多样的，因为计算资源完全被我们控制着。假设我们有一个web app。那么我们可能会在IaaS上有几个机器节点去承担运行app的任务，比方说，有8个database节点，3个web ui节点，1个nginx前端l节点。那么在IaaS上，我们只要对8个database节点做集群（比如1+2主从节点和另一个1+2主从节点再加1+1主从的跨datacenter节点，用Galera或者Tungsten连接它们；当第一个1+2挂了可以用第二个，第二个挂了可以用1+1那个）。那么这样的HA方案运行起来对app服务还是比较稳定的。只是缺点在于如果没有很好的doc或者自动化脚本，dev是不会勤快到搭建整个和prod一样的环境去开发的；这样就导致了一个争端，当prod出了问题，那这个问题是配置系统导致的，还是app的bug导致的？第二个比较麻烦的问题是，今天prod搭出来了，等人员流动一段时间，搭prod的人辞职走了，那后来的人还能将prod快速搭建起来么？
所以PaaS可以解决这样的问题。首先它想剥离计算资源平台的组建和app部署。这样ops团队focus在维护计算资源平台，dev开发app然后直接扔进平台里。首先一个PaaS是有重启app的功能的，比如kubernetes里你可以设置，如果一个app挂了，它可以1min后再重启一个。在这个功能的演化下，部署到PaaS里的app对外确实不应该知道具体的ip的，因为假设它挂了无穷大次，那么你也不能立刻知道它这次重启被分配在了哪个host上。这样的好处是，今天我部署了一个app，哪天它挂了，系统可以在随机一个host上重启它，这样就做到了简单HA的功能，服务中断时间是PaaS检测到机器挂掉并重启的时间。这样搭建起来的app和开发时的app基本上是一样的，出问题了也比较容易分清楚是dev的还是ops的。
那么说了这么多，在PaaS上dev的编程观念到底要变在哪里？其实我们注意到kubernetes在运行的时候会启动一个pause，docker－compose运行的时候要求app build在swarm之上。这两个东西都是类似于monitor的。再宽泛一些说，dev需要为他们的app写monitor，去判断目前app运行的环境状态。继续扩展上面的例子，一个app挂了PaaS会重启它，那么我们同样可以为app写一个monitor。对于docker，我们可以写一个monitor然后最先运行它，它会启动app的主程序。当它检测到自己网络可能中断访问不到外部公共数据库的时候，它可以选择自己exit退出（container也会exit），这样就相当于app挂了；PaaS一般会挑选另一个host重启这个app，让这个app自己尝试重新连接数据库。这个例子进一步加强了HA的功能。
另外就是数据库schema升级和降级的方案在PaaS上也是可以自动化的。在IaaS上，可以使用Puppet，Ansible去解决各种升级问题。而在PaaS上，只要app有一个好的monitor。我们可以在公共数据库里多一张schema version的表。在初始化的时候schema version为1，然后我们准备好app v1的image，启动整个app。当需要升级schema的时候，我们先更新好app的image为v1.1，然后将schema version从1改为2，并开始升级；app的monitor应该去监测这个值，一旦发现version变化就自己退出；这时候app v1会全面自动下线，PaaS监测到app的node都挂了会一个一个重启它们，而此时app的image已经更新，重启后的app就是v1.1的了，连接着数据库的schema此时是version 2。
PaaS的战场app monitor的厮杀会是比较激烈的，谁的monitor写得好应该是可以造福dev ops的。
J.Y.Liu
2016.04.11
