惠普云服务因OpenStack获得转机

Paul Miller：先谈一下OpenStack。业界有不少的云解决方案可供惠普选择。惠普在历史上也选过它们。那现在为什么OpenStack成了正确的选择呢？

Margaret Dawson：功课做得很好，挑到一个小刺。其实我们两年前就策略性地选择了OpenStack。第一个产品是GA，也是我们的公有云。OpenStack现在是我们所谓的共同架构（common architecture）的基础，是我们所有云产品的技术基础。我们选了OpenStack有几个原因。原因之一是惠普和开源有不解的渊源。有些人忘记了我们和开源社区一起合作过的这些年头。几十年前我们就在客户的Linux机种里提供基础设施的支持。这是惠普的传统，对我们来说是再自然不过的事。但是，这些也是客户的需求。我们听到呼声：我们要开放，我们要透明，我们要可移植性的程序。这是另一个重要的原因。

还有一条，社区创新是一个值得重视的事。开源为什么会做得那么好？是因为每个人都回馈，因此，创新率会很高。我们的社区参与程度已经很高。我们一直以来都是是顶尖的贡献者之一。我们在持续整合方面也做了不少其他的工作。我们实际上是在基础上把这些从我们的产品中独立出来。我们在数据结构和基础设施上做了很多的测试。这些只是我们对社区贡献的一部分。坦率地说，我不觉得有必要再搞一个私有云黑盒。已经有很多类似的东西了。我认为要让客户有一个公开的、灵活的、便携式的环境。我们为其添加自己的价值。也并不是说所有用到OpenStack的公司推出的产品都是一样的。OpenStack是基础，API的用法和其内部的可操作性是一样的，但就像特别调味品，我们可以加进安全、管理、服务等等。我们提供专业服务，帮助征途上的客户。刚才谈的即是我们竞争力所在，也是我们与别人不同的地方。

Paul Miller：我觉得这个特别调味品的概念很重要。我们谈的是普通OpenStack，只是加些东西上去。

Margaret Dawson：加东西了就不是普通的了。普通的好。我开玩笑的。

Paul Miller：惠普在自己的公有云里部署OpenStack时，原始的代码还没达到可以以如此规模运行的程度，惠普加了东西，改了东西，与基本的解决方案有些不同，最后成了惠普味的OpenStack，以满足惠普和客户的需求。

Margaret Dawson：我想我不会同意。我觉得早期的时候，OpenStack还不是太成熟，有人说要不要跟随主干代码之类的。现在完全不用理会这一类的说法，原因是现在OpenStack绝对地、100%地可以运行了。我们跟随主干代码。现在都用到Havana了。我认为现在的平台已经成熟，社区也成熟了，几乎完全没有必要做修改这种事了。我们的惠普味OpenStack并没有改变核心组件。我们利用核心组件时，存储、网络、计算等等都是跟足主干代码。由于API的互操作性，这些东西动不得的。互操作性来自这些东西。我们加的只是共同架构层，用来让私有公有云交流以及管理云环境，再加上管理协议层建立一个共同的可视性和简化管理等等。还有安全和SLA，以及如何帮助客户部署和管理。

Paul Miller：我等一下到观众里去看有没有问题。怎么知道围绕OpenStack这些事确实有意义而且会在客户里产生共鸣？我现在是惠普的客户，那可以继续跟惠普和OpenStack在一起。这是一个方面。但是对于那些非惠普客户怎么做呢？你会如何把他们纳入你的OpenStack解决方案里而不是让他们去用别的解决方案呢？

Margaret Dawson：二者策略很不一样。对于现存的客户，我想他们已经部署了惠普的基础设施产品，诸如此类。我们讲到混合时，并不是指混合云，我们指的是穿过OpenStack的混合交付。只不过是将OpenStack视为对他们已经在做的东西一种扩展。我觉得要这样看这个问题，很重要。每当我想到云时，总是扩展，增加，附加，而不是撕裂和取代。没有谁是从传统基础设施一下就到云的。这是做不到的。都是一步步的，这样做让他们可以灵活地迁移环境，一开始只是把某些程序放在云里，真正地融合到他们已经在做的东西里。这样做的效果很好。他们已经知道是一个开放环境，但是有惠普的经验，有惠普的支持，有惠普的SLA，惠普的服务，都是我们以前用过的。

对于新客户，最重要的是要成为此生态系统的一部分。他们会说，那好，惠普的云是企业级别的，但是我的初创公司也可以做那些事。我已经有一些OpenStack合作伙伴，这些合作伙伴也跟惠普合作。使用的API是一样的。这样就会开始有新一代的客户，这些客户惠普在过去似乎是没有打过交道的。我们跟经销商协作，经销商可以把这些东西捆绑起来，经销商会想到说，我现在把这个备份设备和这个云整合到一起，做一个灾难恢复方案。他们瞄着工作负载，我们可以在整个生态系统里协助他们。