[译] 企业级 OpenStack 的六大需求（第 2 部分）：开放架构和混合云兼容
全文包括三部分：
在本系列的第一部分，我介绍了企业级 OpenStack 的六大需求。现在，我会着重阐述接下来的两个主要需求：开放架构和混合云兼容性。让我们马上开始吧。
需求3 - 开放架构和减少厂商锁定
我们已经讨论过构造健壮的云控制平面和云管理系统。OpenStack 吸引人的特点之一是通过使用开源代码平台来消除厂商锁定。
“无厂商锁定”是蛇油推销技巧（Snake Oil Salesmanship）
你是不是被承诺过 OpenStack 可以避免厂商锁定？完全没有厂商锁定只是个不切实际的想法 - 就是那种可以想象得很完美但是永远不会实现的东西。任何系统，都有某种形式的厂商锁定。比如说，你们部分人都应该用过 RedHat 企业版本的 Linux 系统，一个完全 100% 开源 Linux 的操作系统，来作为你企业的默认 Linux 版本。你看，RedHat 就是一种形式的锁定。RedHat 的 Linux 是为了一个特定目标而设计的特定版本的 Linux。使用它，你就会被锁定进它们的特定的参考架构、打包系统、安装/系统引导等等，即使它是开源的。
实际上，在许多客户那里，我没怎么看到对锁定的担心，而更多的是对“更多锁定”的担心。打个比方，一个客户，他要求保持匿名，基于厂商锁定的考虑，对采用我们的块存储组件有意见，即使它是 100% 开源的。进一步了解后，我发现其实是客户想继续使用他们现有的存储提供商（NetApp 和 Hitachi Data Systems）而并不想再去培训他们的 IT 团队再去使用一个新的存储系统。可以看出来，他们对厂商锁定的担心，主要是不想有更多的锁定，而不是完全想要消除锁定。
因此，更重要的是，去了解你的企业所能承担的风险。转为使用 OpenStack, 就像前面 Linux 的例子一样，意味着你通过针对新的软件培训你的IT团队，以及可以从多个厂商去获取开源软件的支持，去减少某种风险。
换句话讲，OpenStack 肯定可以减少厂商锁定，但是不是彻底消除它。因此，去寻求一个开放的架构，然后期望收获一个企业级产品吧。
锁定一直存在，特别是使用企业产品
我希望锁定不存在，但是它确实一直存在，就像你从上文中所读到的那样。这意味着，与其一味去寻求没有锁定，不如去看看你能接受什么样的锁定。一个企业级的OpenStack 版本，会通过一个开放的架构来提供一系列的选项。然而，一个真正的云操作系统和企业产品，不会提供无限的选项。为什么不能呢？因为那样的话其支持模型是不可持续的，各个产品提供商最终都会离开这个领域。即使是大型的厂商，也不会向所有用户提供所有的选项。
如果你想围绕 OpenStack 打造你自己的定制的云操作系统，你可以尽管去做，但是那不是一个产品。它需要定制化的专业服务。就像那些在一段时间内推出了自己的Linux 发行版的公司一样，他们给行业带来的是某种程度的混乱，最终对行业和用户是有害的。而且自己做也需要很多的资源。你需要有个 20-30 人的 Python 开发团队，对基础架构（计算、存储和网络）都非常熟悉，他们需要全时间投入到你自己定制的 OpenStack 上。一个团队看起来大概象：
因此，最终地，如果你需要一个企业级 OpenStack 驱动的私有云方案的话，你需要选择一个厂商。
需求4 - 混合云兼容
混合云是个全新的世界。我们所交流过的大部分客户都已经意识到，他们需要向其开发人员提供最好的工具。需求不同，要求不同，想法不同，抱怨也不相同。每个企业都是独一无二的。有些企业希望从公有云开始，然后一段时间后再转移到私有云；有些希望从私有云开始，但是也缓慢的采用公有云；而有些公司在两个方向上齐头并进。RightScale 2014 年的报告对这方面有些非常好的调查数据支持：
我们来看看，为什么你的企业级 OpenStack 驱动的云操作系统提供商最好有一个优秀的混合云故事可以讲。
混合云优先战略
每个公司都需要一个混合云优先战略。这个的意思是，混合云应该是你第一个的和主要的需求。然后，围绕混合云，使用一个单一的、整合的监管模型，会给你带来最好的收益。最终，根据你的应用和需求，制定一个流程，来确定每项工作需要什么类型的云。下面这个图突出了这个流程，但是你要知道，每个公司情况不同因此数据也不会相同：
理解云的兼容性和企业级私有云在混合云中的角色
我做过不少兼容性方面的事情，最痛苦的莫过于 IPSec 和 VPN 之间的兼容。达到各厂商之间的兼容性是需要花成本的，往往需要大量的工作，而且往往最终很难取得一个好结果。而且不幸的是，兼容性往往被误解，特别是对于公有云/私有云/混合云。
混合云的挑战，是如何解决应用的移植性问题。如果你需要一个公有云和私有云组合而成的混合云，不管应用在某个云中被开发，还是要在两个云之间做迁移，或者从一个云到另一个云，应用的可移植性都是必须的。当你选定一个应用以及它的云原生的自动化框架，并将它们从一个云移动到另一个云中，一些关键的东西必须保持一致：
- 性能相对平稳
- 底层的存储、网络和计算架构保持一致或者近似
- 你应用的自动化框架必须和两个云中的 API 都兼容
- 每个云中，运行应用的总成本（TCO）都应该在1/2-2倍的范围之内
- 还有行为上的兼容性，意味着非 API 功能也需要吻合
- 支持与相关公有云 API 的兼容
下面这个表格将有助于解释这些需求：
当然，当你设计你的应用的时候，你还需要考虑避免和特定云的锁定，比如避免依赖 AWS 上的 DynamoDB，VMware 上的 HA/DRS，F5 上的 iRules 等等。
如果你不能满足这些需求，是无法获得兼容性的，应用的移植肯定会失败。应用的性能可能会在不同的云上变化很大，其中一个云上会最好；某些云可能缺少一些功能特性使得你的应用不能工作；如果没有行为上的兼容，你的自动化框架可能会不能工作。打个比方，如果应用中有个定时器，它假设虚机会在 30 分钟内启动，可是在一个云上虚机过了一到两个小时才启动起来。
所有这些问题，必须通过混合云兼容来解决。
OpenStack 需要一个参考架构
Linux 内核需要一个参考架构。实际上，每个 Linux 的主发行厂商都创造了自己的参考架构，因此，我们现在有不同的 Linux 操作系统分支。比如，有RedHat/Fedora/CentOS 分支和 Debian/Ubuntu 分支。这些纯粹的 x86 操作系统都有各自的参考架构型，在每个类型内的迁移是相对不需要怎么花费力气的。但是，当 RedHat 管理员去使用 Debian 时，他可能会有些迷茫，直到他完全知晓了两者的区别。OpenStack 的情况其实也没什么不同。
OpenStack，就像它的大多数开源同胞一样，是没有参考架构的。它只是云操作系统的内核。这既是它的优势，也是它的劣势。Linux 也是一样的。你可以给你的超级计算机获得 Cray Linux，你还可以给嵌入式 ARM 设备获得 Android。两者都是Linux，但是都有不同的架构，使得应用在两者之间无法迁移。OpenStack 是类似的，总有一天，大部分的 OpenStack 云之间没有兼容性，因为每个都有自己的架构。每个云都有自己的架构，是注定要成为 OpenSnowFlake（柜台里面各种不同款式的钻戒）。
OpenStack 驱动的企业级云操作系统需要有共同的参考架构。只有这样，你才能确保每个部署的云实例，都能和其它云实例兼容。目前，这些参考架构还没有出现。然而，假设 AWS 和 GCP 有一个单一的云参考架构（我们称之为“弹性云参考架构”），我们很难想象没有任何 OpenStack 参考架构会和这种架构非常类似。
说得更清楚一点，将来肯定会有多个参考架构最终脱颖而出。我也看到了在高性能领域出现的架构，以及别的行业比如石油和天然气行业。
企业级参考架构
最终，你需要打赌 OpenStack 企业级参考架构会在哪里落地，但是目前的数据表明，前10大公有云中，只有一两个是基于 OpenStack 的。
如果企业希望敏捷、灵活和多选择，看起来显而易见，OpenStack 需要支持一种企业级参考架构，该架构会致力于打造和公有云领域的终极赢家兼容的混合云。这只是我的个人意见，目前看起来象 Amazon, Google, and Microsoft。
企业级 OpenStack 意味着一个企业级的参考架构，它会保证混合云兼容性和应用移植性。
第二部分总结
设计一个提供混合云兼容性的开放架构是目前的一个结论。可能对于如何实现会有争论，但是对于实用主义者来说，可以肯定的是，公有云领域将会出现各种赢家，而且前十名的公有云已经被非OpenStack方案占据了。我们需要做相应的准备。
更重要的是，当你期望一个企业产品的时候，记得要求一个开放的架构。
下一篇文章中，我们讲探讨为下一代应用交付一个性能优异的、可扩展的和弹性的基础架构具体是指什么。
原文：The 6 Requirements of Enterprise-grade OpenStack，Posted on Apr 28, 2014 by
