先回顾一段历史：2007左右开始吹SOA的风，在各大厂商的鼓吹之下，大家开始玩起了SOA，ESB、BPM、Webservice、SOAP、服务治理。。。，今天回头来看，不知道多少企业的SOA方案落地是真正解决了它自身的业务或者技术问题？不知道多少企业现在还坚守着它的SOA体系？

为什么说这么一段历史？是为了引出题目【迁移or重构】，为什么谈这么一个话题？因为这两年又刮起了一股风暴：云计算。

观点1：不管是以前的SOA也好，现在的云计算也罢，它不仅仅是一个概念，一项技术，一个平台，它是特定企业的IT发展到一定阶段，遇到了难以突破的瓶颈，而提出的一整套解决方案；

观点2：在引入这样一个量级的企业级解决方案的同时，对于企业对带来的是破坏性重构，而不是过渡性的迁移，从产品、研发、到运营都会面临聚变；

观点3：决策者们要清晰地看到，企业在当下或者未来将会面临怎么样的瓶颈是目前的架构和方案无法解决的，需要引入新的企业级解决方案来处理；

说完三个观点，再来说说自己对于云计算片面的了解：

1、专业名词：IASS、PASS、SASS、公有云、私有云、虚拟化、DOCKE。。。云计算相关的专业名词是在太多了，不胜枚举；

2、方案由来：与SOA是几大商业化软件公司为了自己软件产品的销量而推广不同，云计算缘起互联网公司和社区的分享【当然，也可能仅仅是披着马甲的同一拨人】；

3、云计算到底是什么？查了好多资料，都没有一个官方的解释，越查越不懂，所以就只能自己做个推演和假设，来阐述一下我想象中的云平台【文中不谈钱，不谈性价比】；

没有云计算之前，我们是怎么开发一个应用的？

a、明确业务需求，包括功能性需求和非功能性需求；

痛点：非功能性需求很重要，很大程度上决定了硬件资源的投入，但是非功能性需求的评估很难，无法在项目立项or需求阶段对业务量等给出一个客观的评估；往往给出的不是一个客观的业务直，而是一个我们常说的脑袋值；

如何让业务量的评估成为一个可选的环节，让资源跟着实际业务走？

b、研发业务系统，包括系统研发、测试、部署、上线；

痛点：应用研发阶段，无法聚焦于功能性的需求的实现，而是要考虑很多非功能性的需求实现，从应用角度，要考虑failover、要考虑系统额伸缩性、要考虑系统的安装、监控等管理功能；从中间件角度要考虑中间件的选型、中间件的部署等；从硬件的角度，要考虑硬件设备的计算力等等；

如何把非功能性的工作抽象归类、公共化、让软件工程师们聚焦在业务功能的研发？

c、运营业务系统，包括系统运维、监控、扩容、应急；

痛点：应用简化安装、设备池化管理，应用动态监控、系统伸缩扩展，可能这些工作在好多企业的运维过程中还是半人工在处理的；

如何让这些日常的运维工作变得规范化，自动化，让运维工作变得更加简单、可靠？

有了云计算之后，我们是怎么开发一个应用的？

描述一下希望的样子：

从应用的角度出发：

a、对外带宽资源、CPU资源、内存资源、存储资源等

b、中间件资源：数据库、缓存、应用服务器、消息队列等

c、自动化安装接口、应用启停接口、日志发送接口、健康检查接口、自动伸缩接口等；

从云平台的角度出发：

a、面向硬件资源的管理功能，包括资源登记、资源虚拟化、资源情况监控等等；

b、面向业务应用的管理功能，包括应用接口的实现、包括应用的自动化管理等等；

所以，云平台如果建成，很大程度上解开了对于开发部门和运维部门的束缚，大大缩短研发的时长，提高运维的效率，脱离了对于业务量评估值的依赖，从而进一步改善业务的发展；

4、云平台的迁移，内涵究竟是什么？

问题1：如果有一个存量的业务系统，要从小机平台迁移到云平台，那么它要做的工作是什么？是完成不同操作系统、不同数据库间的应用迁移？还是要完成从小机平台的设计和运维模式，到云平台的设计和运维模式的重构？

问题2：云平台的特点，我们该怎么去理解和使用？举一个简答的例子，云平台的一个卖点就是价廉，换言之，相同的钱可以买比较多的机器，从研发的角度，有了那么的机器，我的系统结构该怎么样设计才能物尽其用，可以解决小机时代解决不了的问题？可能带来的就是系统重构；从运维的角度，管10台机器和管1000台机器，完全是两个不一样的概念，应该做出一些怎么样的改变？

up方方土，一个混在金融行业的屌丝程序员，喜欢代码，喜欢咖啡，喜欢旅行