要说云，不能忘记传统的三层划分方法：IaaS、PaaS和SaaS。在企业级，大多谈的是IaaS层。当年AWS搞云计算的时候，无人喝彩。没想到几年之后，竟然成了趋势。微软、IBM等公司都在进入。中国的阿里、腾讯先后进入这个市场，增长迅速。
不过大多数软文写的都是概念和宣传，如果站在Siebel的小船上看过去，我们就抛开噱头和炒作，只且看技术和内容。
一、云的概念
现在的云计算市场很火，先了解下云计算领域的几个的概念：IaaS,PaaS,SaaS
IaaS: Infrastructure-as-a-Service（基础设施即服务）
第一层叫做IaaS，有时候也叫做Hardware-as-a-Service，几年前如果你想在办公室或者公司的网站上运行一些企业应用，你需要去买服务器，让你的业务运行起来。
但是现在有IaaS，你可以将硬件外包到别的地方去。IaaS公司会提供场外服务器，存储和网络硬件，你可以租用。传统一点的主要是电信的IDC机房，托管机房或服务器租赁。
而现在一些新的IaaS公司包括阿里云，Amazon, Microsoft 也开始做这块业务。这些大公司玩转IaaS一般都是由于自己本身的系统规模太大，已经有了PaaS、SaaS的分层雏形，而在这些大公司里，核心的资源就是IaaS ，在这块已经拥有成熟的技术能力，也是最适合变成计算能力租售给各行各业。正是在这批大公司的竞争中，逐渐孵化出了云计算目前的几个领域分类的概念。
PaaS: Platform-as-a-Service（平台即服务）
有两种含义：
（1） 可定制化的集成开发环境，一般会有以下几种特性：
1. 界面UI、字段、可定制，可扩展。比如不同角色界面显示及字段逻辑不同
2. 对象模型及基于对象的事件控制。例如对象CURD时执行某个脚本
3. 流程可定制。比如定制可图形化设计的业务流程，审批工作流。
4. 数据库对象模型的非SQL语法查询,例如Salesforce中 SOQL语法
5. 解释型语言动态编程扩展。例如SalesCloud中的Groovy，Salesforce中的ApexCode
6. WebService或Rest API集成框架。所有对象及字段可自动映射到API接口访问。
（2）平台生态效应
PaaS将作为一个平台，给功能开发者提供了集成开发环境和展示产品的场所（Market Place）。开发人员使用平台开发出具有特定功能的插件产品，发布到MarketPlace上，平台使用方在平台上*购买，组装各个产品插件，以构建符合自己特定需求的整体解决方案。在这样的PaaS生态环境中，平台利用双边效应让甲方和乙方形成*市场，整个平台最后达到合作共赢。
目前市场上这块做的比较完善的PaaS平台主要还是大公司，例如Oracle 的Marketplace 和Salesforce的AppExchange。Salesforce 和Oracle, 其实也可以这么看
SaaS: Software-as-a-Service（软件即服务）
有了上图其实第三层也可以理解了，就是各种App Store里的App。只是这里的App 卖的都是API，API即服务。而这些服务都是企业来买单，举个例子，比如现在某土豪老板要做个CRM，记录客户信息，客户分级，按级别定期给客户推销产品文章，定期做客户回访，查看文章阅读量统计报表，客户活跃度报表，回访统计报表等。
如果是传统的做法：需求评估，买服务器，买操作系统，买套装软件，找公司来实施，上线完成招专职运维一枚。周期长成本高风险大，后期升级扩展成本不可估。在云时代的做法，买个微信企业号（包含客户分组，可分组图文群发，支持报表统计），买个问卷星（支持微信集成，报表查看），客户数据可下载，总体按API调用次数收费，成本和业务成正比，支持试用，一键开通无需等待。如果你是老板你选哪种方案？
二、云的发展
云产品会越来越多，但是和传统产品不一样，云时代下的SaaS产品会逐渐往细分领域垂直发展。而大公司会逐渐往这两个方面发展：
1. 产品逐渐按行业领域或功能领域垂直细分，单个云产品功能有限但体验很好。原先大而全的产品如EBS，SIEBEL,SAP的概念会逐渐弱化，取而代之的场景可能是这样的
2. 强化PaaS平台，产品分的细了，组织和扩展起来才能更灵活。而PaaS工具强大了，合作伙伴才能利用其开发更好的产品
3. 对于实施公司来说，其实只是换了个产品，而这个产品并没有比大而全的传统软件功能强大，反而功能更零碎，系统间的关联性更复杂。实施公司要实现相同的需求可能会比以前做的更多，但时代总是进步的，产品功能的开发工具先进了，现在可以用PaaS去完成所有的客制化需求，SaaS先天具有接口集成标准化的优势，接口集成的成本更小了。
三、云的集成
如果说未来都是云的天下，那么未来可能有一种职业会非常抢手，就是数据集成架构师。未来系统间的数据链路会比较长，数据间的业务依赖会也会影响接口设计的复杂度。那么站在技术的角度，根据之前的项目经验，简单总结目前云产品下系统集成常见的几种场景及注意事项
（1）身份认证& 组织架构
云产品多了之后，每个系统都要登录，这里面就有两个问题
1. 人员信息每个系统如何统一登录。 做SSO？ 那么需要一个独立的SSO 身份认证服务器，比如能登录Oracle Sales Cloud后，也可以直接登录Siebel或Eloqua 。Oracle 提供了 Identity Management Cloud 解决方案，支持SSO，LDAP 等协议。
2. 组织架构角色如何统一。即使用了SSO拿到访问令牌Token后，对于数据的查看权限，各个云系统权限结构不一定一致，而能够基于上下级进行的数据访问控制就需要系统中预先拥有组织架构数据。这里就需要用系统集成将组织架构数据和各个云产品进行同步。 Oracle Identity Management Cloud 中也提供相关解决方案。
（2）接口方式
传统的接口一般都采用WebService的方式，但这种方式一般都是带Session会话模式，Login-Process-Logout , 大型软件一般都会在Session层面初始化很多内容，批处理接口还好点，但是遇到实时接口，效率相对比较低下，更别提采用负载均衡面对大数据量时的实时并发同步处理。现在的云产品都支持了Rest API模式，包括Oracle Sales Cloud ,Eloqua, RightNow 等产品，均提供了完整的接口方案。
Rest 接口的优势主要在于可以Stateless 无状态会话处理，系统只要每次通过Auth2的Token验证方式验证通过，就不用初始化Session了，很多场景下甚至把Token的验证搬到了Redis里，效率更高。无会话状态的另一个好处就是可以做负载均衡集群，而不用考虑Session复制，做N个节点处理数据只在乎过程，不注重是谁发起的，当然并发处理数据时需要考虑共享数据的写入锁。
（3）接口认证
目前云产品中比较流行的是Auth2.0 和 Basic 认证，在Oracle和salesforce中都有提供。要注意的是云产品对于数据传输加密非常重视，所以所有OutBound 和InBound 的接口都需要SSL 安全性要求，所以外部服务器接入云产品时，注意都需配置WebServer的HTTPS 访问。
Basic认证本身是不安全的，因为接近于明文传输密码，虽然已做MD5(Base64(Password))， 但一旦加密传被网络层捕获，也是可以用HTTP工具模拟身份直接向服务器发起请求的。 所以一般来说采用Basic认证的接口都会要求必须使用HTTPS加密。
OAuth2.0 已经是行业内比较成熟通用的认证解决方案了，详细就不说了，主要是你要有个地方存着Token。 示意过程如下：
（3）公有云和本地产品的数据同步
很多传统企业其实刚开始尝试使用云产品，过程中难免遇到和本地系统的数据同步问题
1. 本地系统由于企业安全性要求，不允许你外部公网系统直接访问本地系统的接口。
2. 本地系统不一定有支持基于Http协议的API接口暴露给外系统，说不定只是个数据库
3. 本地系统不一定能直接访问外部公共网络
以上三种情况我们经常遇到
一般来说问题1 和3 是内外网安全性访问问题，可以看是否有DMZ区域或堡垒机。在DMZ区中架设Web代理服务器（Apache 或 Nginx即可）通过NAT映射或反向代理转发到目标主机。
问题2 ，不能直接要求客户开放数据库端口给你, 你可以辛苦点在你的DMZ区域中自己搭个轻量级的代理应用(能连数据库就行）发布一下。不过类似DMZ区非实时性数据同步，大型企业数据量大时可以考虑用Informatica 或 Kettle 开源工具进行批量搬数工作。Kettle 支持Rest、WebService、FTP CSV等输入，输出到表，也支持Job作业，非常方便。