一、未知与挑战
OpenStack是开源的云计算操作系统，近年来，随着云计算概念的逐渐普及和企业业务创新的迫切需求，云计算技术得到了大面积的推广和应用，OpenStack也逐渐为人们所熟知。相应地，在构建云平台的实践活动中，OpenStack也被越来越多地被引入到企业的云计算环境中，成为IT基础设施架构的重要支柱。
在很大程度上，云计算平台已经或即将是企业IT基础设施架构的核心，其最根本的特征是成熟、稳定和高效。反观OpenStack技术，则具有开源技术的典型特点，即：在整体发展上是遵循着循序渐进和逐步演进的规律，而在具体技术细节上则处于高速推进和急剧变化之中。正是由于这样的独特背景和现状，OpenStack在企业的落地是充满未知性又极富挑战性的一项工作，既要充分开掘OpenStack的创新能力并应用于具体实践，又要研究、理解并牢牢把控住稳定和剧变之间的矛盾和冲突。
由此，在OpenStack落地应用于企业IT基础设施架构的过程中，必须充分地对其必要性进行分析和评估，进而对其具体建设方法作出与客观条件相适应的判断和抉择，最终，以开放和务实的精神去制定可操作的推进流程并予以具体实施。
可以肯定的是，由于企业IT基础设施架构的根本特征，OpenStack的落地应用必然是一个稳扎稳打的推进过程。
二、现实必要性
诚然，IT技术是业务创新发展的驱动力，但这并不足以回答“为什么要用OpenStack？”。实际上，更为具体的问题是：企业用户引入OpenStack技术去构建云计算平台，其内在的现实必要性又是什么？
总体而言，企业客户在这个问题上具有如下的高度共识：
（1）灵活敏捷的IT底层技术，必然会相应地带来业务上的灵活敏捷；
（2）基于开源架构，融合了最新技术的开源平台具有良好的可伸缩性，可以灵活地进行调整以适应业务的变化；
（3）避免被闭源商业软件产商“绑住”；
（4）采用开源技术构建云平台，可以极大地节省投入到IT基础设施的成本；
（5）极大地提升IT基础设施的执行效率。
在这些现实必要性的作用下，企业用户对OpenStack具有极高的期望，而且，这些期望也具有高度一致性：
（1）统一的整体性的云操作系统；
（2）一套具有良好整合性和互操作性的服务组件；
（3）与用户现有的硬件、软件和公有云可进行互操作。
令人遗憾的是，企业用户的这些期望至少在目前是落空的，或者说，客户根本就不应该有这样的期望，因为OpenStack不会成为统一的整体性的云操作系统，这也就决定了其它两个期望也是无法实现的。
实际上，先把对灵活性和敏捷性的要求放在一边，用户最想要的还是两点：降低成本和从闭源商业软件中解套，这是用户寻找通用的OpenStack的根本原因。
通用的OpenStack实际上就是指：
（1）纯正的“官方”OpenStack版本，很容易安装；
（2）安装后保持默认设置就可以使用的OpenStack，同时，有易于使用的图形化界面，根据实际需求，很轻松就能修改相关配置；
（3）不会涉及任何商用收费服务的OpenStack。
坦率地说，这种通用的OpenStack恐怕永远也不会出现，因为这与OpenStack的原生属性和生长方式相悖离。
最接近于用户期望的是：纯正的“官方”OpenStack（也就是原生的社区版）是可以自由地从OpenStack官方网站下载的，然而，即便是试验性质的安装也必须具备较强的技术能力，遑论应用于实际的生产环境。
仅仅是为了让OpenStack运行起来，就要进行大量的设置工作，保持默认设置是无法工作的，而且，OpenStack有500多个设置项，大多数的设置只能在字符界面里以手工输入命令的方式完成（注：目前比较新的版本的配置项已经减少很多，而且绝大部分默认的设置是不需要去手动配置或修改的，这个地方原作者写的有些夸张）。
除非最终用户具有将OpenStack自如运用的技术能力，否则，将构建云平台的工作交给专业的OpenStack产商（包括供应商和系统集成商）就是必然的选择。供应商提供专业的OpenStack商务发行版，这是经过专业技术优化的OpenStack版本，易于安装、升级和使用；系统集成商提供专业的OpenStack规划设计、安装部署、知识传递和日常运维等各项服务。当然，这是要支付相关费用的，是标准的商用收费服务。
三、自主建设还是引入产商
通用的OpenStack并不存在，因此，想要独立自主地去建设基于OpenStack的云计算平台，是极具挑战性的。这与一个人赤手空拳去独立组装一辆新车所面临的困难大致相当：没有组装必备的工具，你得自己购买；只有画得很潦草的组装图纸，你得弄清细节后再去尝试；面对几万个零部件，你至少得找几个内行人来帮你，而这可是一笔不小的开支。等到终于把车组装完成，还有可能开出几米就抛锚了……
从OpenStack官网上下载“纯正”的社区版OpenStack，使其运行在生产环境中，需要克服巨大的技术障碍才能实现，是非常复杂的过程。没有自动化的安装流程，几乎所有的安装步骤都要用键盘输入去完成（注：目前OpenStack的kolla项目已经解决了这个 问题）；安装完成后，想要升级成新版本OpenStack非常困难，还很有可能造成现有环境的崩溃；除了参与OpenStack社区的技术交流外，很难得到及时有效的技术支持，耗时耗力可能还是无法解决问题。
大型企业当然可以组建专门的技术队伍去做这项工作，只要付出足够的人力和代价，自主地掌控OpenStack技术并非绝不可能，这样，就可以按照实际需要及时地进行技术调整，也不会被某个闭源商业软件产商所“绑定”。只是，投入极大，等同于创建专业的OpenStack产商。
如果选择引入专业的OpenStack产商，可以在很短时间内就完成落地建设过程并提供给业务使用。这正如购买从专业生产线上已经组装好的汽车，可以立即投入到正常使用之中。
一方面，在专业技术力量的支持下，规划设计和具体实施部署的过程变得迅捷而流畅，建成后，基于OpenStack商业发行版的日常操作简便而高效，而技术支持和售后运维等各项重要事务都能得到专业级的服务支撑。另一方面，也必须看到，以企业既有的评价标准衡量，引入OpenStack专业产商，除了要支付不菲的商业费用外，仍有被产商“绑住”之虞，只不过，是被OpenStack开源软件服务产商“绑住”。
但是，引入原生OpenStack就不会“被绑住”，这是极端错误的观念。
对一般规模的企业而言，想要引入“纯正”的社区版OpenStack加以改造并应用于生产环境，存在着难以逾越的技术障碍，最后的结局不是被OpenStack“绑住”，而是被OpenStack拒绝。
大规模企业如果要组建专业技术队伍进行自主研发，由于涉及软件、硬件、存储、网络和安全等领域，必将面临着巨大的资源投入和难以预料的前景，一旦陷入技术泥淖，就不仅仅是被“绑住”，而是被OpenStack“困住”，鉴于此，源自理性分析的望而却步就会是必然的选择。
如前文所述，引入OpenStack专业产商，以企业既有的评价标准去衡量，又何尝不是“被绑住”了？然而，如果换一种开放的思维去看待这个选择，那不是“被绑住”，而是企业构建IT基础设施架构的一种常见方式，是正常形态的外包。
不仅如此，还应该进一步认识到，在生产环境中，必须以是否能充分推动业务发展的需要为最重要的准绳，根据实际情况，将开源软件和闭源商业软件有机地组合在一起，一味地拒绝闭源商业软件也是矫枉过正的。
要想以全新的思维去分析研究、引入和应用OpenStack开源云操作系统，就必须认清当前的技术发展趋势，对OpenStack落地应用的实际案例进行充分的研究，抛弃一些陈旧的固有观念，以全新的开放态度和理念去迎接新的云计算技术。
应该清醒地看到，一方面，OpenStack确实有广阔的发展前景，另一方面，全面掌控“纯正”的社区版OpenStack需要极大的投入，即便是AT&T、德国大众、沃尔玛、中国移动等大型公司也需要引入专业的OpenStack产商才能顺利完成技术落地实施和全面推广。OpenStack的落地应用实践已经证明并且还将继续证明：“术业有专攻”，不同的企业有各自专注的领域，如果引入专业队伍有利于企业的IT基础设施建设，进而极大地促进企业自身业务的创新和发展，那就应该坚决地予以施行。
四、大道至简原则
确切地说，OpenStack并不是单一的软件，而是一个整体性的框架，是一个由若干组件构成的可用于构建公有云和私有云的基础框架。
从2015年开始，“大帐篷(Big Tent)”模式被正式推出，这个模式把OpenStck的项目分类，其中，包括了6个Core Services（核心项目）、13个 Optional Services（可选服务）和许多正处于活跃状态的其它项目。
如此众多的服务组件，令人目不暇接，每一个都新奇而有趣，而且都有很强的实用性，极具吸引力，企业用户很可能会陷入贪大求全的泥潭之中而不能自拔。比如，尽管在实际上并不需要，但是想尝试和体验一下“数据库即服务”，可能就会迷恋于Trove组件却无暇提升核心服务的质量。然而，过于复杂的IT基础设施架构会空自耗费宝贵的系统资源，选择超载必将会导致决策瘫痪，因为，企业用户在面对大量的服务组件时，已经无法辨别与其自身业务密切相关的部分。
在OpenStack落地应用上，必须秉持“大道至简”的基本原则去选取必要的组件，将精力集中在核心服务上（比如：计算服务、存储服务和网络服务），具体而微地去分析理解企业自身的特定需求，以“实用、够用、好用”为标准，在保证简洁和高效的前提下构建基于OpenStack的云计算平台。
“大道至简”的基本原则落实于具体的实践中，就是：采用最简单清晰的技术架构，从最基本的服务组件集（比如：计算服务，对象存储服务，或者，计算+对象存储）开始，在实践中逐步总结，不断提高自身对OpenStack的理解。同时，在使用中不断确认新的需求，充分评估和分析能满足新需求的服务组件，在合适的时机，再将之投入到生产环境的正式运行中。
五、落地流程
企业用户在推进OpenStack落地应用时，就必须踏踏实实地学习、调研、分析、试验、推进和推广，只有这样，才能使得企业的IT基础设施架构稳若磐石，发挥承载和推进业务创新力的核心作用。
以下的分步流程是为全面评估OpenStack产商并最终确定最佳入选者而设置的，立足于步步为营的稳步推进：
（1）首先，企业应该确定负责推进OpenStack落地应用的团队负责人；
（2）在互联网上全面搜索并认真研读OpenStack的各类介绍文档、规划设计和实施方法论；
（3）团队下载OpenStack，将其安装在一个最简单的环境中，对照技术资料，完成若干技术任务，从中体验OpenStack的设计理念；
（4）团队对OpenStack有了基本理解后，应该着手组建企业项目团队；
（5）组织企业项目团队的成员协同工作，构建一个简单的OpenStack PoC环境，并在此PoC环境中不断地演练，深入地理解OpenStack的核心服务和可选服务等基本概念；
（6）如果条件允许，可引入专业的IT咨询人员，高度参与企业项目团队的具体工作，指导整体规划设计和系统集成等流程，保证项目建设过程中整体方向的正确，同时，在此过程中，完成面向企业项目团队成员的知识转移；
（7）设计一整套合理的评估机制和流程，确保对OpenStack产商进行评估的可信度；
（8）充分开展调研工作，弄清当前OpenStack市场的现状，在评估机制和流程的有效作用下，在国内外的几家OpenStack产商中选择入围者；
（9）在企业内部开展调研工作，梳理和分析各方需求和建议，整理出需求说明书，交予各入围的OpenStack产商；
（10）评估各OpenStack产商的技术方案，在条件允许的情况下，给出特定的技术任务，限定时间甚至限定地点，要求各OpenStack产商各自独立完成并展示实现效果；
（11）对各OpenStack产商的技术方案和完成技术任务的情况进行全面而细致的评估，给出技术评估结果；
（12）将技术评估结果交予采购部门，并与采购部门充分协商：尽可能向集供应商和系统集成商两种角色为一体的OpenStack产商倾斜；同时，为保证承建方在项目建设期间的资源投入，坚决杜绝开出不合理低价的OpenStack产商入选；
（13）确定入选的OpenStack产商，企业项目团队与之协同工作，共同完成项目的详细推进计划；
（14）企业项目团队和OpenStack产商项目团队共同推进项目的顺利完成。
本文转载自 Moehoo猛虎 微信公众号。有少许改动。对原作者深表感谢！