做PaaS也有将近八个月了,作为在亿贝第一年的目标,写一个自己的PaaS系统一直是我不敢想的。不过渐渐的,时机也差不多成熟了。从最开始的CMS客户端,PaaS和IaaS的API客户端,一个用来做资源迁移的略带智能的应用,一个高危的LB应用,我几乎重写、改进、使用和理解了我目前所维护系统各个方面。然后我发现两个致命问题,我所维护的系统并不是PaaS,只是provisioning;然后公司的PaaS又是高度定制化的,完全不像我过去所接触的诸如heroku、GCE或者Asure。于是,我决定要仿照Cloud Foundry的概念,写一个自己的PaaS。PaaS必须要围绕应用(很奇怪,并不是围绕平台的),大致有部署(安装应用)、维护(监控、scalaing)和路由(访问应用,灰度发布)组成,应用可以定义自己所需要的服务,由PaaS负责提供服务,服务本身可以是一些按需启动的应用。目前我已经完成了单机的部署,仿照go语言管理包的方式,从Github上下载代码,然后安装,并注入应用启动所需的参数。接下来,我会完成应用注册,实现一个ElasticSearch三副本的自动部署,并且每个ES节点启动时,其他节点的IP自动注入。希望年底前能完成一个可以发布的版本!

今天,家里的门坏了,简单来说,就是门锁和挡板不匹配,不是关不上就关不牢,岳父大人自己一个人在那里琢磨,不让我们插手。后来,我从外行人的角度,提了一些意见,比如说把挡板拆下来矫正,在挡板里面垫纸片改善门的松紧问题。说起来,如果有人跟我建议,API不稳定就重试,超时就多等会儿之类的,我以前肯定是不能接受的,太外行了。但实际上,有很多问题就真的能够解决,而这些方案往往不是内行人的思路,而我们真的需要一些外行人的second opinion。

周五跟Jian一起吃饭,深入理解了下未来的发展方向,并深深感受到Kubernates对我们的冲击,有种随时被取代的感觉。回来以后,我打开了一个Kubernates的网页,下决心要好好学习一番。但是随着了解的深入,我产生了一个疑问,Kubernates真的是PaaS杀手么?如果说Docker是目前最先进的虚拟化技术,而Kubernates又能用Pod来抽象应用栈,那么问题就是,Pod是最先进的应用抽象技术么?答案我还在摸索中,也许等我自己的PaaS做好以后再做一个比较,不过就目前而言,Kubernates更像是IaaS杀手,如果IaaS团队的兄弟不急的话,PaaS团队自然也会有类似的应对之道,谁知道呢。

最近书房重新换了布局,心情也随之变换,从美西回来以后,终于再次进入状态。