云服务的目标

【版权申明】：本专栏文章为chenlong828在开发工程中的一些思考和总结，谢绝转载！

---

目标在何方

云服务，到底是何种目标，从目前来看，应该是达到什么样的层次才算ok？打开业界标杆Amazon Web Service的网站看看，基本分为了计算、网络、存储等几个大类，每一个大类下面包含了林林总总的细分产品，共同组成了一张完整的云服务拼图。

但是，就是这些吗？把所有的产品都整合起来，算是提供了完整的公有云服务？

该是啥

在模拟城市中5中，有一个建筑，叫做信息塔，在一些面向高科技的设施都必须要有一定的信息点才能驱动，如核聚变发电站、污水净化站等等。信息点对于这些设备，就好像是水、电等基础资源一样，成为一个生产必需品。而信息点则是通过信息中心产生，通过信息中继器进行传输。突然有一天，恍然大悟，原来这就是云计算，而且还是标准的“电厂模式”。

但是从当前公有云服务普遍的产品体系来看，林林种种的VPC、RDS、ECache、MapReduce、NAS，看样子产品琳琅满目很多很丰富，但是实际上只是侧重于解决某一个方面的问题，本质上是对传统IT服务在云中环境的映射，功能和数量的映射，就如同家里的电器一样，有电冰箱、洗衣机、微波炉、电视机，都在消耗一度一度的电，但是却又提供亦一样的功能。

云服务的目标，应该是尽可能为开发者提供Cloud Native应用运行环境，这么一看来，好像大家都不看好的PaaS平台，反而应该算是公有云服务最终的样子。提供一个标准化的运行时环境，应用程序根据自己的需要，直接在对系统申请资源，需要大的时候多申请点儿，需要不高的时候少申请点儿，完全弹性。所有的度量，完全用一个成为“计算力”的计量单位来核算，使用了不同的云服务，代表了不同的“功率”，进而这算成不同的“计算力”，并且按此收费。但是，目前也没有“计算力”的统一标准出来。

那基本已经提供了类似服务的PaaS平台如GAE、BAE，为什么始终没有火起来？要学会跑步，先要学会爬，目前我们所在的技术栈层面上，相关的开发、调试、部署、运维等工具都不成熟，平台本身也没有经历过大型应用的适配和打磨，贸然在上面进行Cloud Native应用的开发，必然出现很多的问题。从某种程度来看，目前的公有云服务中所提供的各种小产品，反而是当前过渡环境下的一种必须过程。云服务，最终应该是简单而纯粹的：上传一段代码，自动执行。