本文讲的是如何理解容器技术平台的不同姿态【编者的话】最近，在微软加入CNCF基金会仅一个月之后， 亚马逊也宣布加入成为白金会员，至此，全球主要公有云服务商都加入了CNCF。可以说这是以Kubernetes为代表的容器技术平台的全面胜利。Kubernetes火爆之初，有人担心它会冲击Cloud Foundary为代表的PaaS平台。 事实上，作为PaaS一哥，Cloud Foundary依旧有着稳定的生态和忠实的用户。而有意思的是，一度如日中天的IaaS平台却意外受伤。同时，在AWS Lamda发布后，Serverless热度暴增，各大云平台纷纷推出Serverless服务。
无论Kubernetes、Cloud Foundary还是Serverless，其背后驱动都是容器技术，但技术热点快速轮动，常常也给开发者／用户带来困扰，究竟什么时候该用什么平台／技术？是否契合所面临的问题？本文希望围绕Kubernetes、Cloud Foundary和Serverless做一些粗浅分析，尝试提供一个理解不同容器化技术／平台的视角。
图 1 2014年7月至今，Kubernetes（蓝线）和Cloud Foundary（红线）的搜索趋势变化
图 2 2015年7月至今，Kubernetes（蓝线），Cloud Foundary（红线）和Serverless（黄线）的搜索趋势变化
开发运行一个应用，在Kubernetes、Cloud Foundary和Serverless平台上各需做哪些事情
假如一个工程师要分别在Kubernetes、Cloud Foundary和Serverless（例如，OpenWhisk）上开发／运行同一个应用，例如实现一个排序应用， 我们分析一下，大概各自要做哪些事情。
在Kubernetes上，开发人员一般需做以下几步：
- 编写应用代码；
- 构建应用容器镜像，并上传到相应的容器镜像中心；
- 创建一个Kubernetes集群；
- 把相应的容器部署到刚创建的Kubernetes集群中；
- 测试并确认应用成功上线。
而在Cloud Foundary或Serverless 上，所需工作可简化为三步：
- 编写应用代码；
- 更新配置文件并把应用发布到云上；
- 测试并确认应用成功上线
应用上线之后，考虑到应用弹性和业务可靠性，Kubernetes和Cloud Foundary应用还需再做一步，即扩展出多个实例，而Serverless则什么也不用做。
上述步骤总结如表1：
表 1 Kubernetes、Cloud Foundary和Serverless部署运行应用步骤
从这个简化的例子看，假如用Serverless实现，用户要做的最少，只需提供编写调试好的代码就可以了；使用Cloud Foundary，用户要关注的稍微多一点，如运行时设置弹性扩张；而用Kubernetes的话，用户要做的就相对复杂些，不仅要提供应用所依赖的runtime环境，而且还要自己制作容器镜像，并发布到相应的registry，同时还要考虑构建整个部署环境的Kubernetes集群等等。
图 3 各*aaS中用户管理和平台功能的划分
结合IaaS和SaaS，图3把三种基于容器的计算模式，从用户和平台两个角度作一个更为通用的描述。可以看到，从IaaS，CaaS（Kubernetes），PaaS（Cloud Foundary），FaaS（Serverless），最后到SaaS，平台提供的越来越多，用户要做的越来越少。下面通过理解Kubernetes，Cloud Foundary和Serverless的主要定位，再做进一步分析。
Kubernetes、Cloud Foundary和Serverless期望解决的问题
容器很重要的特点之一是快速构建一个跨平台运行的应用及所依赖的环境。无论Serverless、Cloud Foundary还是Kubernetes，都以其作为技术平台基础，但由于想解决问题不同，所以各自侧重也不同。
Kubernetes社区发展很快，也孵化了很多新项目，而所有这些都围绕其基本定位，即容器编排，或者说scheduling，即决定什么东西（pod）跑在哪儿（node），以达到相应的可用性（serviceability）。Kubernetes极大简化了用户对容器（应用载体）的管理，大大提升了应用维护的灵活性和可控性。此外，它对底层基础架构抽象相对较少，使得用户依然可对资源有较全面的管理；
Cloud Foundary作为PaaS，希望能为用户解决除了应用开发之外的所有事情。 它提供了几乎所有语言的buildpack，也提供了service broker的机制，方便应用集成外部服务，同时还自带容器管理组件，解决应用部署问题。对于开发者来说，开发应用之后，几乎只需执行Cloud Foundary push一条命令，其余的事情都可交由平台处理完成。这使用户更加专注应用本身，并从应用管理，中间件管理和部署环境等大量而繁琐的工作中解放出来。但由于平台对整个流程／Stack的完整封装，用户在享受巨大便利的同时，一定程度上也被限制了对底层资源的灵活调度，进而影响应用的可能形态。
Serverless按照Martin Fowler的定义，可以分为两类，一是极大依赖于第三方服务的应用（通常称作BaaS "Backend as a Service"）， 二是依赖于跑在非持久容器上特定代码的应用（通常称作FaaS “Function as a Service”） 。我们通常讨论的Serverless，如AWS Lambda，Apache OpenWhisk属于后者。FaaS类型Serverless的典型场景是触发-响应，即根据定义的事件执行相应的功能（一段代码）。用户只需关心事件定义和响应动作，所有其他事情交由平台处理，包括根据请求进行自动迅速地弹性扩张，响应结果保存所需的存储等。就像Serverless的名字一样，用户不需要关心任何服务器，无论是物理服务器，中间件服务器，还是数据服务器，就像它们不存在一样，甚至都不用关心应用，用户只需做好事件触发后的响应功能。
对于Kubernetes和Cloud Foundary，Ubuntun的 CEO Mark Shuttleworth曾说过，“对于我们而言，Kubernetes是引擎，是涡轮机，是PaaS平台的核心，而Cloud Foundary则是个完整的PaaS”（图4），而关于PaaS和Serverless，现在是AWS云计算战略副总的Adrian Cockcroft也曾有个同样形象的评论，“如果一个PaaS，为一个只需执行半秒的任务，可以在20毫秒之内启动许多实例，那就可称为Serverless”（图5）。
图 4 Mark Shuttleworth关于Kubernetes和Cloud Foundary的评论
图 5 Adrian Cockcroft关于PaaS和Serverless的评论
这两段评论可以帮助我们对Kubernetes、Cloud Foundary和Serverless之间的定位有更清晰的理解。Kubernetes只是对容器进行管理的一种技术，而非平台，Cloud Foundary则是完整PaaS平台，容器管理（Diego）是其重要组件，是平台整个技术stack里的一环，而Serverless则是某类特殊PaaS，它充分利用了容器瞬间启动和能快速弹性扩展的特性。
Mark的类比非常形象，我们不妨顺着他的思路联想一下。假如Kubernetes是个引擎，这意味着它是动力，可以构建拖拉机，也可以构建汽车，或者变成轮船的驱动；那么Cloud Foundary就是整车了，用户只能根据用户手册在适合的道路条件下使用它，换个胎是可以的，但想随时改底盘悬挂，换发动机是困难的。那Serverless呢？也许可以看作是固定线路班次的公共交通，比如飞机，高铁，按时间触发，从某地到另一地，如遇突发流量，管理部门就会增加班次或加挂车厢。
灵活度vs易用性——一切为了创新
既然三者之间有如此清晰的定位， 为什么貌似Kubernetes一枝独秀？为什么Cloud Foundary过时了或Serverless只能用于简单功能之类的声音会不时响起呢？ 根据上面讨论，可以看到，从Kubernetes，到Cloud Foundary，再到Serverless，其实是对底层stack不同程度的抽象，随着抽象程度提高，降低了对实现栈的控制，其目的就是把关注更集中于业务逻辑的实现。
抽象，用另一词来替代，就是封装。封装一般都会简化底层逻辑，屏蔽相应细节，限制对底层某些功能的访问，所以用户在获得便利性和易用性的同时，必然以失去一部分灵活性为代价，同时也影响了应用的适用范围，例如Cloud Foundry对IaaS资源的需求，由BOSH通过一个叫CPI（Cloud Platform Interface）的接口实现，这个接口把对计算，存储和网络的操作简化成十几种，一般情况下够用了，但操作粒度和灵活度的确值得商榷。
图 6 各*aaS上开发应用灵活度 vs 易用性的对比
我们在图3上加些标注，改成如图6所示。从IaaS，CaaS（Kubernetes），PaaS（Cloud Foundary），FaaS（Serverless）到SaaS，随着抽象程度提高，用户关注度越来越集中于业务逻辑本身，而代价就是对技术实现栈的控制越来越小，对应用调整的灵活度也越来愈弱。鱼和熊掌不可兼得，如何在灵活度和易用性之间进行折中，往往需要基于实际业务场景考量。
假如我们希望构建一个能服务于不同规模，不同类型的云计算服务平台， 把Kubernetes作为核心引擎显然是一个非常有吸引力的想法。通过把核心引擎的能力暴露出来，并围绕核心引擎，丰富完善基础服务，以微服务松耦合的方式组合，就能适应各种业务场景，构建复杂应用。
对于一个企业，如果其专注点不是提供云服务，而是迅速构建创新业务应用，那一个Cloud Foundary的PaaS平台能帮到很多。企业开发人员根据业务需求，利用Cloud Foundary平台开发应用，绑定所需服务，并通过集成的CI/CD流程，让应用从开发，测试，staging到生产，一气呵成，业务迅速发布。在一个业务需求变化迅速，应用生命周期越来越短的时代，把程序员从与业务实现不相关的工作中解脱出来意义巨大。
Serverless则完全从业务场景出发。设想一个大型企业集团的财务人员，每个月末或季末都要统计大量的财务数据，一般情况下，可以用财务软件，但当财务指标，报表格式发生变化，计算公式发生调整时，提交软件变更可能是个复杂的过程，这时采用公有的Serverless服务无疑是高效的做法。另外，Serverless以功能为对象，可以在某种程度上降低对代码能力的要求，业务人员也有可能直接参与功能实现，让功能不仅as a service，而且还是自助服务。相信这也是Serverless演进目标，即无代码功能实现，变成App-less。关于这点，我们似乎可从微信小程序看到些什么。
演进，容器技术平台还会发生什么？
以上分析讨论是基于Kubernetes、Cloud Foundary和Serverless的现状，如从演进角度看，它们之间的关系和定位也许很快会改变。
回想容器兴起之初，很多人觉得它的能力和性能还不足与虚机相比，但随着容器技术的迅速发展，尤其是容积编排技术的巨大威力，怀疑的声音已经很少了，甚至有硬件提供商宣称，今后出货的服务器不再预装虚拟化层，而改装容器管理平台。从这个意义上讲，CaaS/ Kubernetes更像是IaaS的升级，这也是为什么Kubernetes火了以后，IaaS受到一定冲击的原因。
同样，由于历史原因，Cloud Foundary虽也有优美的容器管理组件Diego，但它的能力却不能为应用开发人员充分利用。假如Cloud Foundary能开放Diego，或者能对其他容器管理技术开放，那Cloud Foundary push显然能做更多事情，服务于更复杂的应用场景，这无疑对技术人员和企业都是福音。
现在，技术越来越开源化、社区化，Kubernetes、Cloud Foundary和OpenWhisk都有各自非常活跃的社区。社区最大的优势是利于技术的迅速传播，而我们在各个社区里也看到很多相互借鉴或融合项目，无疑，这是推进技术快速演进的方法。
后记
这篇读书体会是一年多前写的《弯道超车：容器技术究竟为云计算带来了什么？》的下篇， 也是最近读了相关资料（链接如下）后的一点感想。出发点是试图理清一个困惑，即，如何能在迅速理解技术热点的同时，也能了解其相互关系和演进的内在逻辑。我想，这也是文中大牛，如Adrian Cockcroft、Mark Shuttleworth和Martin Fowler为什么总能有一言蔽之的金句的原因 。
参考
- Container vs Serverless -- https://www.slideshare.net/Dan ... tions
- Serverless Architecture: A Gentle Overview -- https://www.slideshare.net/Cod ... rview
- Mark Shuttleworth访谈1 -- http://www.datamation.com/open ... .html
- Mark Shuttleworth访谈2 -- http://www.datamation.com/clou ... .html
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
作者介绍
鄢达来，IBM云计算方案开发经理。
原文发布时间为：2017-08-21
本文作者：鄢达来
原文标题：如何理解容器技术平台的不同姿态