IAAS和PAAS是如何高度体现运维本质的没有比“可视化”更好的一个词能概括运维的本质，而“可视化”又应该分成两部分：可视化的服务交付和可视化的服务度量!第一部分：可视化的服务交付早期的运维是从ITIL开始的，那个时候大家都不知道运维是什么，怎么做，幸好找到了一个IT服务最佳实践--ITIL。于是就开始了运维的摸索之路，从CMDB、服务台、事件管理、变更管理、可用性管理、容量管理等等逐步去了解，逐步建设自己的系统。但我们很快发现，这一完备的流程框架遇到了大规模运维的时候，就无法应对，或者说过多的聚焦于流程以及规范，我们发现很难提升运维敏捷度和精细性，并且我们还是不知道一个完整的IT服务边界在哪儿?如何实现它?不过在ITIL的实践过程中，其实提出了一个很好的概念---IT服务。对于运维来说，提供一种高效、一致性、透明化的服务是运维的成功所在，这样就要求服务提供者屏蔽其提供的所有服务细节，因为对于服务消费者来说，很难对专业的运维服务内部细节掌握和了解。就拿服务器资源交付来说，从早期的研发要关心配置、OS初始化、自己安装系统、配置网络到最后交付到手里即插即用，服务的自动化程度和完整性越来越高。其实也是一种“架构及服务”的思想体现，把之前早期交付功能变成了交付服务的模式。另外从运维事务或者活动的角度来说，如何对其进行一次或者多次的组合封装，把它们变成一个完整的IT运维服务，是此时的运维自动化重点方向。毕竟繁杂的运维事务不进一步封装，对个人或者团队来说，都意味着很高的学习成本和事务执行成本。在传统的IT运维组织中，我们能看到彼此事务之间的割裂非常明显，比如说网络、机房、服务器、应用部署等等，都是在不同的团队完成，彼此工作独立进行。在大一点的运维团队中，可能会有一个专门的运维研发团队来给这些日常活动进行自动化的封装和实现。在大规模海量运维中，必须要求有一个集成的平台来实现把这些事务流调度起来，否则无法提高事务执行的效率和质量。对于如何封装这些事务或者活动，从DevOps中可以找到一些答案。DevOps提倡自动化一切，其中一条核心的主线就是持续交付。我把持续交付分成两类场景：一种是持续交付基础设施，一个是持续交付软件。当然持续集成更多的是偏重于后者。持续交付基础设施是目前IAAS平台要解决的，利用软件定义计算、存储、网络等技术来实现对上层应用所需资源的快速交付。其中虚拟化技术是IAAS层持续交付的一个核心技术，虚拟化能够快速的创建资源，交付资源，回收资源等等，在早期也有人错误的认为虚拟化就是云计算。最新的轻量级虚拟化技术更是热点，根本的原因是把应用的交付在镜像级别交付了，从而进一步降低了应用交付的成本。持续交付软件从代码产生的那一刻就开始进行管理，到编译、到测试、到灰度环境验收到正式环境部署，并且希望这条主线完全的自动化。具体的持续集成最佳实践如下【具体请参见--持续集成：软件质量改进和风险降低之道】：面向程序包的持续集成非常简单，现在有很多的开源解决方案来实现，jenkins、go平台等等，但有一种情况需要非常注意，就是程序包的配置管理问题，这个也往往是影响发布的重要环节。所以我们很多时候使用开源平台只是让他产生程序包即可，后续的包的管理和配置管理以及后续的实例化发布，特别是大规模集群部署，都是由单独的发布平台来解决而非持续集成工具(虽然它们也支持)。基于软件的交付解决之后，这个时候我们一定会想，如何实现全应用的交付，此时便有了PAAS平台和基于应用架构的可视化部署服务两种方案。这两种实现思路有很大的不同，我们知道完整的PAAS平台是提供了对底层服务的统一抽象，比如说数据库服务、存储服务、cache服务，但是对于许多开发者来说，好像又不愿意收到这么多的约束，这也是PAAS平台一直没有火起来的原因。PAAS平台最经典的实现应该是CloudFoudry了，国内很多PAAS平台基本上都是参考CF来实现。CloudFoudry概念模型如下：参照CF的基本架构，我们也有一个类似的PAAS平台实现(百度的PAAS平台也是如此)，示意图如下：而在现实的情况中，很少有公司有能力把Mysql、MC、Fastdfs封装一个服务供上层应用调用。在这种情...