先自我介绍下，sina微博北京-小武，《云计算网络珠玑》作者，现就职于华为IT产品线云计算网络架构与设计部。
OpenStack现在非常火热，社区也集聚了大量的开发人员，各家厂商包括通信设备商、运营商、互联网公司、电商/店商(包括宝马、沃尔玛、苏宁等)都有参与，用其搭建公有云或私有云平台。那么我们如何将OpenStack的代码变成一份产品呢?
玩过OpenStack的人相信都对刚接触OpenStack有很深的印象，最开始真是迷茫一片，感觉是蚂蚁嘴啃天，既不知道如何下嘴，也更有一种遥不可及的高度;熟悉之后会感觉相对简单些;如果仅仅将OpenStack运行起来做个demo，已经非常不容易，做成产品更是要费很多功夫。
所以把OpenStack代码变成产品首先需要几个称职的程序员，如果按照分工至少需要多少人呢?这个话题最早个人讨论要追溯到上年和陈沙克老师的一次QQ聊天;现在应该需要14个人，具体是怎么安排计算出来的?
将整个OpenStack玩熟，需要部署、管理端、计算、存储、网络、运维等方面的职位需求，仅从开发的角度来列举下需求人及负责工作内容(不是熟悉特性，而是大部分问题能通过代码层面搞定)：
- 计算2人：负责虚拟化、linux内核系统相关、集群、NTP、消息队列(rabbitmq、zeromq、activemq、qpid)、Nova代码，Glance、Keystone代码;
- 存储2人：所用存储商家存储设备及driver(包括开源的ceph等)，mariadb， Cinder/Swift代码，Hadoop及Sahara(原来叫Savanna)、部署等等;
- 网络3人：所用网络商家设备(switch、router、、NGFW/F5)及Plugin或driver，linux协议栈(tcp /ip，tap/tun，linux bridge，ovs，iptables)，物理组网结构，Neutron代码及所用相关开源代码(keepalived/haproxy/lvs)，网络安全设计等等;
- 管理端2人，熟悉OpenStack API和其他云平台API，熟悉公司IT流程，熟悉管理平台架构和业务设计能力。
重复下，这些人不是说只熟悉特性，而是从代码到产品过程中的大部分问题都能通过代码层面搞定。
每个领域应加一名人员，一方面防止人员流动带来的损失，再一方面就是因为每个层面需要的人才都是通才的专家，多增加一个人力给组建团队减少困难，会很大程度上通过人员组合达到集齐所需技能的要求。
最后加上一名足够优秀的领导，当然也可以是CTO来兼任;需要其对云计算市场有足够深刻的认识、对客户需求有足够的积累、对技术人员有足够的了解、对技术方向和深度足够的把控等;但是这个人一定要有产品的思维，而不是仅仅懂技术和代码，不懂得如何为客户做产品的CTO不是好CTO。
如果需要程序员鼓励师就是福利了，节省成本角度，是不是可以考虑从HR或行政这块兼职下?
人有了，下面就是一步步代码来实现了：
首先要做个云平台的管理端来管理云平台，说白了，OpenStack的定位是云平台管理端，还需要Horizon来做OpenStack的管理端，通常是一个web portal;这个平台管理端的功能一方面体现了云计算商家做产品的思路，也体现了云计算商家产品的定位是哪一层(IAAS/PASS/SAAS)。
注：这里需要说明五点：
- OpenStack通常商家来做IAAS，但是OpenStack自己并没有这么定位，Sahara即是PAAS的一个体现，而且经过OpenStack定制化，完全可以做到SAAS的需求;
- 管理端对接OpenStack，也可以对接AWS或阿里云，所以云平台管理端本身就可以做成一个产品;这个也可以是某些公司的主打;
- 云平台本身只是个管理端，技术含量也并没有底层这么高，就像互联网的APP理念反而显得重要得多也高大上的多，自然如果底层不支持，管理端做的再好也不顶事;所以OpenStack自身、一些闭源或在OpenStack基础之上修改称之为自研的厂商，如果底层技术没有什么创新，云平台管理端也只能在业务编排上进行点更改，并不是什么技术革命，好比汽车的发动机原理甚至原料没有改变，只是可以调整下位置或形状让汽车的外观变得漂亮些;这点上讲，将来OpenStack会不会只剩下北向API也未可知;
- 结合第三点，云平台管理端是云平台的入口，固然重要而且也很专业，但这还并不是各家云计算厂商技术的差距体现;美观的页面往往对设计进行外包即可拥有;但是体现的云计算平台设计理念却需要人员的精髓外漏;
- 云平台管理端需要集合企业流程IT来做，尤其是私有云的需求，毕竟很多客户企业的内部流程已经用了很多年，对云平台的定制化需求是Horizon在很多情况下被客户或云计算厂商所抛弃的一个很大原因。
现在结合OpenStack的社区代码开发现状来说下一些注意点：
第一，OpenStack的整体代码较多，因为为了获取较多厂家的支持，采用了分布式架构上的 plugin/driver模式来支持，所以有很多层封装，导致了整体效率的低下;Nova和cinder基本是Driver的形式，但是Neutron 社区却是五花八门的plugin和driver，还有很多私有的厂家自己维护的plugin和driver，尤其是最近出现了很多SDN支持的 plugin，比如ODL等。如Neutron：Neutron有L2的core plugin(如现在常用的ML2)，L3有router的，通常是用linux的namespace实现(已有ML3的BP);L4-L7的 plugin几乎是一个功能对应一个;OpenStack原生态代码只保证功能可用，附带的test文件夹代码居然有人作为自建云平台的测试标准工具也是醉了;
面对如此多的plugin和driver如何选择?有钱怎么玩都成，没人可以招聘，有人自己做一款都没有问题;没钱有能力的可以选择 OpenStack的公有ML2等plugin自己优化，没有能力也没钱的的自己整两台PC搭建个demo看看就好了;其实一条路，自己能搞定的选择自己搞定的那款plugin或合作方提供的plugin，自己搞不定的跟着大众走，因为这个plugin用的人多，相当于被测试的比其他充分，这样自己用着有了问题能提出来，总有人来回答或解决，说不定别人都已经解决了;core plugin ML2使用ovs做租户vxlan之间的隔离是现在大家用的最多的。
这里单独提下Open vSwitch的子项目OVN，这个项目体现了老外一贯的开源思路，自己具备核心模块的掌控能力，其他商家的边缘参与建立生态圈;(支持自己的 ovsdb，无碍其他厂家设备的边缘支持)，新出现的OVN开源有目标来将L2-L7的plugin统一，但是道路还很漫长可能会错过商机;社区的政治也是很深。
公司参与开源可以拉投资，但对于求职者不能认为公司采用了开源，老板或公司就会很Open;个人参与开源能提高知名度，但是也并没有因为做了开源而提升程序员的人格或逼格，所以对做闭源的同学相比也没有什么高级的;这些都充分体现了忍狠滚里面的忍字诀，无他耳，参与社区开发的技术能力和水平也不见得都很高，但总有几个大牛在;很多人认为自己能看代码什么都能做，不就是几行代码么?如果仅是代码的话的确谁都可以做，但看得懂if else不一定能理解else之外还有没有else?业务技能和场景远比代码重要。
OpenStack的整体架构是网络的架构的设计，建议让做网络的人来做主(不是只懂tcpdump和ping命令的，而是参与过网络设备研发、设计过数据中心架构方面有经验的人)，做存储和系统的同事参与就行了，因为OpenStack的设计每一步考虑都涉及到网络的内容;
第二，OpenStack的开源代码质量真是不堪，仅仅是一个功能可用的状态，对于性能、架构等方面的优化还差很多，直接拿开源给客户搭建产品基本都是找死的节奏，所以需要有这么几个小观点：
a)云计算厂商的角色基本都是集成商，无论是有能力开发网络、存储或虚拟化底层的，还是没有能力的创业公司，都离不开这几个角色;所以想做full stack的公司需要看下自己真有这个必要和力量吗?希望大家多多继续发挥硬件的力量，仅仅是系统工程师从软件来实现的角度会让性能大打折扣，使用硬件也会加快项目进度，建立更好的生态圈;这一点有几家公司已经意识到做的很不错;
b)云计算厂商做OpenStack产品有两个方式，有关系来解除根据客户需求定制化产品，或者有经验理解客户痛点能够直接用于开发产品;但是仅仅靠云计算的情怀基本是走向末路;有些云计算创业公司刚起步对客户还挑拣，没有搭建过10台计算节点服务器的经验，却非要1000台以下计算节点的单子不接，除非你有很硬的关系信任你，不然只能靠双色球一等奖的概率了;
c)云计算做的好不好，和是否开源关系不大;一个事实是，UCloud的闭源却是创业公司中云计算做的最好的(个人观点，不喜勿喷)，AWS和 Azure是公有云的大哥大，却也是闭源(最近有AWS和OpenStack合作的消息);基于OpenStack的大量创业公司反而多是在整玄乎的概念，真正拿得出手的产品或商业案例却不多;很多公司宣扬的对社区贡献可能为争取公司融资方面做的贡献更多些;大公司开源贡献比如Redhat对于 Linux的产品化方面，有三方面做法：优化参数提升产品性能、掌控开源趋势降低客户成本、快速的Bug fix和版本回合能力;这点也是开源公司招聘开源达人的原因，但是对于小公司来说还无法一步到位的采用这种模式;
d)很多做开源的同学往往对政府意见都比较大(无论国内外)，一方面开源需要open这点政府确实很多时候做不到，另一方面其实是开源社区也有政治，只是这里的政治问题往往掩盖了经济利益问题;开源也是各大相关参与厂商利益竞争的过程;还有一点很多人都认为很使用了开源软件的公司都会很开放的原因;
e)毕竟OpenStack是开源代码，客户用的时候也会调研，包括架构和代码;但是不是因为他问的问题深入就能说明他很强，可能某些方面他们经验积累确实很丰富，但是如果他能搞得定还找你干吗?所以很可能他不如你但是接触商家多所以问的问题看起来很专业，如果你能问他问题，可能分分钟就能问倒他们(这就好比面试学习，很多情况下面试者和被面试者，都会有把对方问倒的交集知识点，知识场景限制双方的说话内容和方式)，你得忍，给他们讲懂，那才能说明你真懂，否则很难拿到单子，纵然你公司技术也很牛。这样客户见了很多商家，每个商家学一点，几乎说起来都很懂，但是动手能力就是上不去。
f)OpenStack也是软件开发方面的，和其他软件架构和代码方面没有什么差别，也需要从架构和性能方面不断优化，可以从以前的软件开发上吸取很多经验;从代码到产品，先是功能开发，然后是规模上去，接着就会性能下降，然后再优化，周始轮询，最终又比较良好的产品级实现;说白了，都是为了底层数据转发面功能，通过管理层来实现;为了实现大规模，通过管理层集群来实现管理层高性能，往往是牺牲了管理面的一致性;CAP这里依然存在;华为在社区提出了OpenStack级联方案，就是通过管理面的努力扩大数据层面的规模;
第三，OpenStack的部署、升级和运维都是大问题;首先说部署和升级，主要是OpenStack的版本快速发展，支持特性不断完善;所以客户的需求也是要跟随的上，仅仅是普通bug修复部署工具基本都能搞定，大的升级影响就会比较大，甚至会导致云平台底层管理网络和业务网络的重大变更;拿OpenStack的I到J举例，如果开启了DVR，想业务不中断只能是跨集群业务迁移;运维来说是云计算商家招牌之一，可以明确的说，OpenStack不会消灭运维，只会导致运维人员的技术要求提高和不努力运维的淘汰;对于OpenStack来说会导致其运维承包团队的出现，也会对OpenStack的培训及运维培训有很大需求，毕竟客户的运维人员对于OpenStack的理解都还不是很深入;某些公司说云平台基本没有运维，那么可以说有可能两点原因，是只有两个机架的设备不需要运维，另一个就是运维外包并且将升级扩容和灾备的事划到运维工作之外;完全没有一个运维这话，真正懂行的没一个敢这么给客户说的。
第四，简单说下SDN和OpenStack的结合;现在出现了很多SDN的plugin，大部分Neutron 是作为SDN控制器的APP或SDN 控制器的的一部分来使用，暂时还未看到第三种形态——作为SDN控制器的Underlay网络层面;对SDN的理解我也只有一种，不认为有狭义和广义之分，所谓云计算厂商说自己天然的云平台是广义SDN的，个人认为这都是对SDN没有理解透彻;SDN应用不仅仅是云计算或数据中心，企业网也可以有很多点，这里不多提了;但是随着各家SDN控制器的出现，SDN的网络开放之路似乎又到了收窄的方向上;希望SDN能尽快走过优胜劣汰的过程，减少中间的无谓成本，多多服务于需求;顺便说下，很多理解我是做SDN的，其实我是做云计算的，只是做网络出身，一直在跟SDN而已;
和自己原来很多技术出现一样，同样的功能各个商家都会取一个自己的名字，换汤不换药;但是说自己家名字的功能是业界第一或第一家实现的就不要这么理直气壮了，毕竟你家名字的功能只有你自己家这么叫，当然是业界第一或第一家喽!其实底层技术都是集成了第三方或开源的，别人家也都实现啦;只是名字不同而已。
其实挺佩服Intel的，无论是其有意为之还是偶然天成，总之现在你做云计算都不得不买Intel的CPU，存储设备，计算设备，甚至交换机现在的 CPU都很多是Intel的(顺便说下Intel也收购了交换芯片商开始做交换机);云计算如此，SDN的控制器也离不开，还有NFV甚至直接被人误解为就是基于X86的虚机，可见Intel在这些新兴领域的影响力。
最后就是希望再云计算领域里，希望大家都踏实些，少些“语不惊人死不休”，乔布斯也只有一个，商业推广的那一套来用到技术上，就真的没品了;狂妄的预测谁都可以说来博取眼球，不过仔细想想真的可能吗?OpenStack都被抛弃了才有可能将来实现的技术现在不提也罢。
原文链接：http://www.sdnlab.com/14573.html
关于OpenStack
OpenStack是一个由NASA(美国国家航空航天局)和Rackspace合作研发并发起的，是一个开源的云计算管理平台项目，由几个主要的组件组合起来完成具体工作。OpenStack支持几乎所有类型的云环境，项目目标是提供实施简单、可大规模扩展、丰富、标准统一的云计算管理平台。
OpenStack除了有Rackspace和NASA的大力支持外，还有包括戴尔、Citrix、Cisco、Canonical等重量级公司的贡献和支持，致力于简化云的部署过程并为其带来良好的可扩展性。
