这年头，搞软件的不谈谈云计算和大数据，几乎都办法愉快地和人聊天了，但人云亦云的“云”，到底是什么玩意儿，要怎么落实到企业服务中，没几个人能讲清楚，讲起来都是唾沫星子乱飞，但效果基本都是云山雾罩。还好，这本书来啦：《让云落地：云计算服务模式（SaaS、PaaS和IaaS）设计决策》。
之前我回答过别人“什么是云计算”、“什么时候用云计算”之类的问题，看了这书之后，我觉得很惭愧，原来我也是孤陋寡闻又积极滥竽充数好为人师的……
书中有一些实际的案例，讨论了云落地的诸多问题，我只挑概念性的一些东西介绍一下吧，几分钟就能让你建立对云计算的基础认知。
>> 云服务模式
这书的第二章，介绍了三种常见的云服务模式，可以为不了解云服务模式的同学扫盲：
基础设置即服务（IaaS，Infrastructure as a Service）
平台即服务（PaaS，Platform as a Service）
软件即服务（SaaS，Software as a Service）
我参照书里的图，绘制了一张更简单一些的云服务堆栈图：
上图中，灰色的部分是你（云计算服务商的客户）需要做的事情。
可以看到，对于购买IaaS服务的客户来讲，他们还需要自己搞系统、搞应用服务器、管理数据库等繁琐的事情，但省去了买服务器、托管、找机架、安装、买带宽等等繁琐的事务。提供IaaS服务比较有名的服务商是亚马逊和阿里云。像阿里云主机，就属于IaaS。
对于购买PaaS服务的客户来讲，它只需要在PaaS服务商提供的平台上做自己的软件就行了，数据库、编程语言、Web服务器等等，都用PaaS服务商的，简单的几个API调用就搞定了，可以非常方便。比如国内百度的BAE，国外Google的GAE，都是这种PaaS服务。新浪也提供类似的服务，叫SAE。
最后一类客户，直接用SaaS，只需要登陆管理后台，做做配置，他们的专属应用就产生了。爽到爆。比如全时的云会议就是此类服务。还有很多公司，把CRM、ERP之类的企业服务，也做成了这种模式。
>> 何时用何种云服务模式
这是第五章，选择合适的云服务模式的内容。
在选择合适的云服务模式时，有许多因素要考虑，大概可以从以下5个方面来判断每种云服务模式的可行性：
技术
财务
战略
组织
风险
技术指的是性能、扩展性、安全性、监管、业务可持续性、灾难恢复等等。PaaS封装了底层基础架构，同时要适应大多数客户，在性能和扩展性上没有IaaS灵活。因此有些对性能和扩展性有超高要求的应用，比如Facebook、Twitter等，都会使用IaaS云服务模式。
战略也会影响选择，比如初创公司，想快速上线新产品，那采用PaaS或SaaS就很好。国内知名的产品小咖秀，就采用了PaaS服务（七牛的），初期开发只用了三个人。国内的另一个公司e袋洗，则采用了腾讯云的云主机、缓存、云存储、云数据库、CDN等资源，是IaaS和PaaS混合的模式。
Salesforce.com提供CRM服务，有PaaS模式，也有SaaS模式，Dell就利用了Salesforce的PaaS，与超过100000名渠道合作办班实现了10亿美元的销售机会登记。国内也有一家叫销售易的公司，在做和Salesforce类似的事。
对组织的评估可能也会影响云服务模式的选择，比如如果你的企业没有IT技术能力，不能自己做开发，那SaaS就是最好的选择（建立一个IT运维或软件研发部门成本太高）。全时的云会议是一个典型的SaaS，对于在各地都有办事机构的公司来讲是一个很好的选择，不但能提高提高沟通效果，还能有效降低因沟通而产生的差旅成本。
财务、风险这两个因素也会在很大程度上影响选择。
具体要使用哪种云服务模式（也可以组合），需要自己考虑，书里在这一章详细讨论了每种云服务模式的应用场景，很有参考意义。
>> DevOps是什么
DevOps也是炒得火热的概念，可是你知道别人谈论它时到底在谈些什么吗？
先看看当下以及之前的软件开发、交付和运维状况吧：
在过去，我们交付代码时会打包推给质量保证，质量保证完成自己的工作后再推给运维团队，而运维团队又必须采用某个适当的环境。由于竖井之间缺乏沟通和协作，运维为了手工搭建正确的环境，需要发起大量反复的会议、电话和电子邮件。这通常会导致瓶颈和环境问题，因为运维团队在最初的讨论中并没有参与进来。使情况变得更糟的是，一旦环境最终完成，部署在这上面的代码又是第一次运行在这个环境里，通常这又会在项目生命周期的晚期引入新的漏洞。在这个生命周期的晚期查找漏洞，会导致团队提高这些漏洞的优先级，只修复那些关键的问题，而其他问题就与大量先前发布版本的漏洞一起被推入待办事项中，或许永远不会出现在优先循序表的前列。显然，这不是创建质量和快速推向市场的方法。
在开发、测试、运维之间，存在竖井（silo），不同的团队被竖井分隔为孤岛，信息流动不畅，协作存在各种障碍，导致开发、测试、运维整个过程既漫长又痛苦。DevOps就是为了消除这种现状而诞生的。
DevOps不是一种IT职能，也不是某一种技术，它是一种关于如何更快地开发和发布软件的文化。DevOps运动企图填平团队之间的竖井，鼓励开发、运营、质量控制、产品和管理之间更好的沟通与协作，让整个软件的开发、发布、运营摆脱之前的痛苦体验。
DevOps有4点核心理念：
理解工作流程
始终寻求提高流程的方法
不向下游传递缺陷
取得对系统的深刻理解
传统意义上的每一个团队，开发、测试、运维、产品，每个人都应该完全理解系统的流程，积极主动地寻求提高流程、改善过程的方法。
系统的这个部分是这个人的，那个部分是那个人的，这种常见的思维习惯和误区需要被消除，系统是所有人的，每个人都担负着让系统更好更流畅的责任。缺陷不应该像球一样踢到下游，流向客户，最后再被客户倒逼回来，一级一级回溯。一开始就不能容许缺陷的长久存在，就不应该把缺陷传递给下游。
为了推广和应用DevOps，团队应该关注以下六点：
自动化基础设置
自动化部署
设计功能标签（feature flag）
测量
监控
快速试验和失败
为了支撑上面的6点具体化战术，需要很多的系统、工具、环境、制度。每一点都可能会引入新的理念，用到很多技术，书里针对此进行了概要讨论，感兴趣的可以细看。
>> 组织与文化的改变
在企业中引入云服务，不单单是技术的问题，组织和文化也需要与之适配。因为一种技术，对应一种思想，一种思想，对应一种组织架构和文化。组织和文化不变，新的技术就很难应用起来。
我曾经在程序视界送过的书，《架构即未来》，就有大量篇幅讲述这一点。而《让云落地：云计算服务模式（SaaS、PaaS和IaaS）设计决策》这本书的第15章和第16章，也简要的讨论了这个问题。