做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团队自然也会有类似的应对之道，谁知道呢。

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