采用云计算切忌削足适履
原题：云计算杂谈（二）
作者：王作敬 汪照辉 中国银河证券股份有限公司 信息技术部IT研发中心
作为云计算的客户/用户，我们更希望真正深入了解，而不是炒作概念、忽悠客户、忽悠投资。故整理了一些资料以及本身的一些思考，在这里与大家分享，希望对大家能有所帮助。
上篇：云计算杂谈（一）点击标题可回顾
云计算杂谈（二）
一、云计算之迁云
天下武功唯快不破，技术采用也是一样道理。早点掌握早点采用，就可以先于同行，创造价值，从而引领潮流，或者实现弯道超车。如果等大家都采用了，实施了，有效果了，再去跟着人家屁股后面做，不单单是失去先机问题，客户资源也会丢失，客户是衣食父母，衣食父母逐步流失了，还怎么创造利润怎么生存下去？
那赶快采用吧？也不是这个道理。新技术的采用，首先需要有相应的人员能够掌控这个技术，如果自身不能掌控，受制于人，也终究会付出巨大的代价。想我们国家武器研发装备思路：装备一代，定型一代，预研一代，就是一样的道理。在《微服务实施之道》中我们提到人才培养，有实力的企业必须考虑人才的竞争和人才的培养，软件科技，说到底，就是智力的比拼。我们要能认识到这些道理，着重规划和吸引人才、培养人才、为人才提供可以发挥的空间，同时需要引导、指导人才朝正确的方向努力。
这些要求似乎过高，企业都是想把人才拿来就用，谁愿意花大价钱培养人才，然后被人轻松挖去？这就要求企业和人才双方的智慧，我也一直说，做软件，是需要天赋的，虽然天赋有高低。对大部分软件从业人员不能强求过多，所谓千军易得，良将难求。真的人才也不需要企业花大力气去培养，其具有主观能动性自我学习的能力，人才自身就可以快速的自我学习和充实提高，需要的是及时的发现这样的人才，寻找这样的人才，用好这样的人才。千里马常有，伯乐不常有，企业的管理者需要有胸怀、有认知、有敏锐的眼光来识别人才，招揽人才，引导人才，使用人才。企业能做大，很大程度上也是不乏伯乐会识人用人的原因。
武功的最高境界是无招胜有招。其实也不是无招，是已经达到了随心所欲，不拘泥于一招一式达到身心与招式的融合统一的境界。有了相关方面的人才，再去做技术采用，去做实施，就会有自己独立的思考、分析和判断，就不会只是听厂商的介绍或者漫无边际的忽悠。两方都懂的人沟通起来更高效更快捷，做起事来也更容易成功，更容易达成目标。
有了懂的人，回到“迁云”，那就容易多了。什么应用可以迁云？理论上都可以。但是技术发展的不同阶段，每家公司的实际情况不同，方式方法也各有不同。举例说，一个公司财务系统运行的好好的，有没必要迁云上？迁云能带来什么价值？同样的应用迁移到云上和保持原状会带来什么不同？我们采用云计算的目的是为了适应业务需求，象财务系统，不管采用IaaS、PaaS、SaaS，目前来说没有紧迫性，它更适合SaaS系统提供完善安全的云服务之后再考虑迁云，不适合部署到IaaS和PaaS。如果是新成立的一家小公司，当然最适合的就是直接采用云服务，根据需要来选择不同的云服务类型。
这就是为什么我们需要相应的专业人才或顾问来做这个事情，最好是没有立场的人员，不被厂商影响，基于事实，实事求是的作出分析和判断。
这也是为什么存在三种云计算类型，因为每种类型都适合不同的场景，都有其价值。具体采用那种类型，还是要基于实际作出判断。一般原则，根据需要，比如我需要一些基础设施比如虚拟机、云存储等，当然选IaaS服务。如果需要自主开发应用、托管应用，那首选PaaS服务，如果没有相应的IT资源，只想使用云应用，那必须是SaaS服务。
虽然我们说云计算是好，有很多优点，迁云也是个趋势，但也不能盲目迁云。我们不能为了云而云，削足适履。厂商当然希望都用他们的云服务，当然希望都迁云，但是选择什么样的云服务，选择什么样的迁云路径，一定要有个清晰的认识。
二、云计算之“大化小，小拼大”
在和Oracle交流时，他们提出了“大化小，小拼大”的问题。这也是我们非常赞同的容器化、微服务化、分布式化面对的重要问题。容器化大化小容易，但我们的需求往往不是大化小能解决的，比如大数据运算，我们还需要把这些化小的容器拼成一个大的应用。分布式技术实现起来比我们想像的要复杂，容器化、微服务化反而使问题复杂化、带来了管理和运维的难度和额外成本。就象一张纸撕成小片容易，要把一小片一小片的纸拼成议长大纸，就需要付出更多的代价。这也是我们提出服务治理、微服务生态的一个原因。小拼大，不仅需要从容器化平台考虑，还需要从服务架构、服务编排、服务治理和管理、数据和数据模型等多个方面考虑，充分利用分布式技术来实现。
做过服务化的应该都有体会。服务化实施并不容易。我们为什么强调数据治理、数据模型、事件处理等在服务化实施中的重要性？万事万物存在都有其内在的联系，不能割裂来看，这就是生态。否则只能是盲人摸象，管中窥豹，只见树木不见森林。如果为了容器化而容器化，为微服务而微服务，其结果可想而知。
三、云计算之容器云架构
代码未动，架构先行。架构的重要性我们就不赘述。容器云、微服务、DevOps三者相辅相成，容器云是基础设施，DevOps提供开发运维方法论和实施指导，微服务是业务应用服务架构模式，其非常适合快速迭代和松耦合的互联网类应用场景。
容器云作为基础设施，目前主流的框架有Kubernetes， Mesos，Docker Swarm。基于这些主流的框架如何架构容器云平台？如何在容器云平台上支撑服务或微服务应用场景？容器云平台如何支持自动化的开发、测试、部署、运维流程？这是我们重点关注的内容。
容器云架构首先需要是松耦合的架构，插件化。既然是个平台，那么除了基本的容器编排调度管理、资源管理等功能之外，还需要提供对日志、监控、告警、安全等功能的支持。目前基本上各组件或各模块都是开源组件基础上的集成，实现时需要充分考虑组件的松耦合集成。我们测试过程中发现不少厂商紧密集成了部分组件功能，比如日志，使用Elastic Search，然后自己开发查询展示页面，集成到自己的容器云平台。第一这样实现极大的限制了日志功能的灵活性，难以充分展示ELK的特性。为什么不独立做一个日志中心？或者叫日志中心插件，和平台是松耦合，客户可以选用，也可以不选用。比如我们有自己的日志管理中心，就可以不用容器云平台提供的日志功能。
容器云架构目的是支撑服务或微服务，业务应用。我们采用容器云目的不是仅仅为了搭建个容器云平台，实施容器云的目的是为了服务于实际的业务应用。这就要求容器云在架构时需要充分考虑业务应用或服务的管理和治理需求。比如对服务编排的支持，对服务治理的支持，对全局权限的支持等。
采用新的技术架构，往往要求相应的组织架构的调整。但这往往是不现实的。新技术架构的采用不应该以牺牲组织架构为代价。容器云多租户的功能，就可以充分考虑到这点需求。
采用容器云，实施微服务，以大化下，那就需要把很多的工作实现自动化，以减轻相关人员的工作强度和压力。如何更好的使开发测试运维联动起来，也是容器云架构实现对DevOps的支持的需求。是否可以把镜像仓库作为开发、测试、运维的联结点？其实这点也和组织架构有关系。用最简单的方式来解决最复杂的问题，这才是客户最欢迎的。
我们也考虑过阿里的云效，飞天敏捷版容器云，大大小小十多个模块，非常适合阿里自身的文化和环境，但我们也说了，云计算采用不能削足适履，适合阿里的不见得就适合你我。不盲目追星，也不拒绝其优点。就象CMMI培训，重点是学其思想，而不是学其条条框框。
四、云计算之产品思维
周末参加CMMI培训，老师讲到Validation和Verification在项目中的区别，Verification需要从技术上、功能上验证是否都已实现；Validation则需要考虑到用户的使用场景、使用者角度、使用习惯、使用维度等方面来验证。一个想要满足用户需要的产品，就需要考虑用户的使用场景，不能闭门造车。
比如，我们发现阿里的多租户权限管理和应用服务管理思想跟我的想法和需求很像，但依然没有避免程序员思维。（请参照我们整理的《容器云多租户权限中心设计》）。不管我们做项目或者做产品，不能想当然的以为自己的想法就是客户用户的想法。比如容器云的实现，我是不是非要在容器云产品的菜单列出“容器”？我想说的是客户/用户关心的是容器还是他们的应用服务？谁应该去关心容器？我们接触的容器云厂商，无一例外都把“容器”放到容器云产品的首要位置。似乎没有“容器”二字就不是用容器技术实现的。深山藏古寺就好，其实作为客户，关注重点是在其部署发布的应用服务，对用户来说，这才是其价值所在。
至于容器云平台是用Kubernetes、Mesos、Docker Swarm或其他调度框架，至于容器云平台使用Docker或rkt或其他引擎技术，或者用什么语言开发等等都不是重点，重点是对应用服务的支持能力！我们也说仅仅一个容器云平台远远不够，它只是一个基础设施，如果要在容器云上支持应用服务，就需要建立相应的应用服务生态，否则也只能为建容器云而建容器云，最终会成为鸡肋。
软件项目最大的风险是不确定性。软件研发靠的是人，人不是机器，最难管理；重要的是发挥人的主观能动性，但这点受诸多因素影响。所以我们在采用容器云时，我明确建议采用容器云产品，虽然目前来说没有一家容器云产品让我们满意，但通过不断的沟通和交流，部分厂商已经逐渐在完善产品。
产品思维从另一方面也是个标准化的过程，对厂商来说，避免需求的频繁变化而导致项目超期预算超支；对用户来说，也可以节省大量的人力、时间和避免诸多的不确定性和风险。对客户可以说是风险转移了，但对厂商来说也是标准化、规范化，降低成本降低风险走向盈利成功的关键。
其实参考国外经验，产品不管大小，很少有我们国内做项目的情况。这也是我们需要学习的地方。
更多相关文章请点击阅读原文
长按二维码关注公众号