Bill Hilf, Senior Vice President of Product and Service Management for HP Cloud, brings an interesting perspective to his job given his former role as General Manager of Product Management for Windows Azure, Microsoft's cloud platform. Network World Editor in Chief John Dix and Senior Editor Brandon Butler got Hilf on the line for his big picture view of the importance of OpenStack, why HP recently acquired Eucalyptus, the impetus to compete on price, and the various cloud delivery options customers are pursuing.
How do you position Helion and where does it fit into the market?
Helion is our brand name for our cloud product portfolio which allows customers to deploy in any cloud context, be it a private cloud or a public or a hosted cloud environment. The applications and data and virtual machines that are going to ride on top of that cloud infrastructure can behave consistently across those different environments.
Enterprises are really struggling trying to do the all-in-one cloud model. But they don't only use a single operating system or database or management tool, so we believe they will need to create a hybrid cloud environment. It's not so much because they want to, it's because they need to given the reality of their existing IT environments.
And what is fundamentally different with our approach is we're building a composable product portfolio so if a customer wants to have only, let's say, an application platform or only an infrastructure as a service platform, or wants to bring existing hardware, be it HP or non-HP, into a cloud environment, we need to have something that is composable and flexible.
That led us to probably the most important design decision we made, which was to build this product portfolio with a deep spine of open-source technologies. So we have OpenStack at the core of our IaaS layer and Cloud Foundry at the core of our development platform, but it's not limited to that. We also support a wide range of open source tools, different types of application technologies, different databases and multiple languages. Really our core DNA is building around open source, which means less vendor lock-in and more flexibility for enterprise customers.
We just started to ship the first production-ready GA version of the Helion OpenStack distribution and Helion development platform which we've been working on for the past year and a half, and there are a number of ways customers can pick it up. There is a community version users can download and play with for free, they can buy it as stand-alone software to run on their own gear, they can buy it pre-integrated with HP solutions, or they may consume everything as a service. The latter doesn't have to be a public cloud. It might be a hosted environment inside an enterprise so the customer can consume everything internally to meet regulatory requirements or policies.
So that's how it will manifest. Customers will have a choice of different cloud models.
So a customer could have you build a cloud within their organization and run it for them as a service?
There are all sorts of ways customers want the mathematics to work. Sometimes they'll want to be an internal cloud broker, providing services to internal customers. We have a big media customer doing this. They have an internal portal that says, "Hey, do you want compute or storage or networking?" And the internal end user has no idea what is actually providing that. Behind the scenes, based on the requirements and the price point and the constraints the end user describes, they can deliver the services either from their Helion OpenStack private cloud or, in some cases, they go out to a public cloud.
So, for example, if a customer wants extreme commodity storage pricing and they have very few constraints on how that data is stored or where, this internal broker might go back with AWS, but it's presented to the internal customer just as a storage resource. That's a really common pattern right now. We call it internal service providers' but it's kind of cloud brokering.
The capital expense is yours and the customer just pays a service fee?
There are all sorts of ways customers want the mathematics to work. Sometimes they'll want to be an internal cloud broker, providing services to internal customers. We have a big media customer doing this. They have an internal portal that says, "Hey, do you want compute or storage or networking?" And the internal end user has no idea what is actually providing that. Behind the scenes, based on the requirements and the price point and the constraints the end user describes, they can deliver the services either from their Helion OpenStack private cloud or, in some cases, they go out to a public cloud.
So, for example, if a customer wants extreme commodity storage pricing and they have very few constraints on how that data is stored or where, this internal broker might go back with AWS, but it's presented to the internal customer just as a storage resource. That's a really common pattern right now. We call it internal service providers' but it's kind of cloud brokering.
Can you describe the difference between Helion OpenStack and the Helion Development Platform?
Helion OpenStack is a distribution of OpenStack built around the current tree of Juno. We don't go in and swap out core components for HP proprietary stuff. We take the core of OpenStack and then do a whole bunch of work to make it easier to install, patch and configure, because that's where a lot of the pain points are right now in OpenStack. We also do a lot of security work on it and then run it at very large scale in the HP public cloud to test for reliability. We learn a lot from running OpenStack in a large public cloud environment.
Above that we have the Helion Development Platform, which is a PaaS layer, but think of it as using Cloud Foundry as the host, or the run time, for applications. So it supports all these different languages and you can publish your Java app or node.js app or Python app or Ruby app into that full application lifecycle environment.
Then alongside of that we have a set of application services. So, for example, if someone wants to use database-as-a-service, we have an easy-to-use DB service so a developer can quickly add a database to their app. Behind the scenes we do a binding between that database-as-a-service at the PaaS layer, all the way down into OpenStack's database-as-a-service offering called Trove. That way we can then offer that database-as-a-service at the development platform layer in a way that's automatically highly available, and automatically has disaster recovery built in because we're leveraging the Trove system underneath and providing that resilience to the database behind the scenes.
We'll do a lot more things like that where we basically illuminate the capabilities inside OpenStack at a higher level for developers to take advantage of. For example, there's this concept called affinity scheduling inside OpenStack where you can say, assign my VM to a high memory machine or assign these VMs to that data center because that is the only one that's HIPAA compliant. As that grows in OpenStack, we want to light up that type of capability higher in the platform so it becomes really easy for the developer.
Also, what we use behind the scenes in our Helion development platform is Docker. Every app you build on our Helion development platform instantiates as a Docker container so you can take those Docker containers and assign them wherever you want. We think this Docker + OpenStack combination is going to very powerful.
So, back to your question, they are two different architectural layers. One is targeted at developers, and one is targeted at IT ops. They can be used independently but we're doing a lot of work to make them better together.
When it comes to use cases for cloud, VMware is positioning its vCloud Air as a natural landing spot for ESX workloads, and Microsoft Azure is a natural spot for Hyper-V and System Center, so where do you see HP being the natural answer?
Because of my Microsoft background I can ask a company what versions of Windows Server and System Center they're using and I'll know right away if they're a Microsoft loyalist or not, and for those customers, the Azure story is compelling. And AWS is definitely the default if you're a startup and looking for the fastest onramp to getting some compute and storage resources that can scale wide. Where we win are with enterprises that have stepped all the way through the virtualization steps in the past three to four years, companies that have more than 50% of their environment virtualized. Now they're getting a lot of pressure on being able to go faster.
So what they're trying to do is take a first step into the cloud, but they are typically encumbered by a tremendous amount of existing IT or security requirements or other business or industry constraints. We have a customer, for example, who just did a few acquisitions, some of which have used public clouds. Their business policy doesn't allow the use of public clouds so now they have to repatriate those resources back inside their firewall. So we deal with a lot of people who are building private clouds first.
Private cloud on their premise?
Yes. The other big sweet spot for us are service providers and telcos. And there's a few reasons for that. One, telcos in particular are very open-source oriented. And two, many service providers and telcos are massively threatened by the public cloud vendors. So, if you are a telco or service provider in, let's say Europe or Asia, Amazon and Google can be really threatening, not just because of their cloud businesses, but because of the whole value chain, all the way down to the device. So they want to 'OEM' our public cloud technology because they need to build a competitive offering to an AWS or Google in their markets.
In the enterprise, how critical are network advances such as software defined networking and network function virtualization in supporting this whole hybrid vision?
Frankly, the network is either the enabler or the bottleneck in most cloud deployments because so much of a horizontally scalable distributed system are deeply tethered to network capabilities. So when you start moving to 100 to 1,000 to 10,000 to 100,000 nodes in a system, the network architecture becomes increasingly critical. In our distro of Helion OpenStack we make sure our networking functionality is great upstream in Neutron, which is the network component inside OpenStack, but we also need to be pluggable with other SDN controllers, with VMware NSX, with our own HP SDN, etc. And down the road we'll have to be pluggable with others that emerge because there won't be one SDN to rule them all, even though I'm sure some vendors would love to have that control point, but it's just not realistic.
This is one of the challenges of building commercial open-source products: you have to have as much value as possible without ripping out the flexibility that customers were originally interested in with open source, or without tainting that because it's very easy to go too far one way or the other where it becomes a Swiss Army Knife. It's good at a whole bunch of things but not really good at any one thing. Or it goes the other way and becomes extremely proprietary and you kind of lose the reason why you built on open source overall.
One way we're addressing the specific networking needs for one of our customer segments, communication service providers, is through a partnership with Wind River to integrate their carrier grade technologies into Helion OpenStack. This will provide communications service providers with an open source based cloud platform to meet their demanding reliability requirements and accelerate their transition to NFV deployments. All within our open source model and keeping OpenStack API compatibility.
Are all Helion private clouds based on OpenStack or do you sell some non-OpenStack private clouds as well?
Historically we had a private cloud infrastructure-as-a-service offering called Matrix that was not open source. This was actually before I joined. There are still customers that use that, but over time our plan is to evolve that product with our Helion OpenStack distribution. We will do it in a thoughtful manner so we don't force customers to rip and replace. But going forward we've made a company-wide commitment to OpenStack.
It's a fundamental bet. We actually got asked once at a very senior meeting, "What's Plan B if OpenStack doesn't work out?" I said there is no Plan B. If you have a Plan B, having lived through this at Microsoft, you end up hedging, doing things to secure the option. So you have to go all in if you really want a platform to take off. So it's a big, fundamental decision for us and a fundamental focus that we have to make OpenStack be what we need it to be for our enterprise customers. There's not a lot of "let's sit around and wait for it to evolve."
There are certainly still some big challenges with OpenStack, but we have many customers who are happily running 100s nodes, many thousands of VMs, in OpenStack for a private cloud and getting great benefit today.
In terms of hypervisor support, do you guys focus on one hypervisor or support a bunch?
At every layer we need to give customers choice. So we support KVM, which is the default people use in most cases, but with this release of our Helion OpenStack we support ESX and very shortly we'll support Hyper-V.
But at each layer we support choice. At the hardware layer, for example, we support our HP gear but have a certification test for third parties on non-HP gear, and a set of tests and benchmarks we give to third-party OEMs to validate against. We know we're not going to sell an HP server with every software sale that's not reality.
Then even further up the stack we have multiple programming languages and frameworks people can choose from, from Python or Ruby or Java or .NET. That polyglot environment is important for us.
So we're not only giving customers a choice of where to install and run their cloud, we also give them a lot of choice when it comes to the technology they can use because, at the end of the day, the VMware story is very vertical, the Red Hat story is very vertical, the Microsoft story, even though they talk a lot about open source, is really very vertical. Choice and a platform truly built on open source - that's a differentiation for us.
If you're pushing a high-end, enterprise-level story, why on the Helion website are you shouting about price so much? That kind of screams commodity.
As of 2014 less than 10% of enterprise IT is using cloud computing, so the growth opportunity is huge. And when you are trying to fight an early market battle for share, particularly for OpenStack oriented customers, you want to grab as much share as fast as possible.
One of the biggest advantages of a company like HP is we have all sorts of ways we can monetize. We don't need to sell software at huge margins. We don't need to sell a server for everything we do. We don't need to sell services for everything. We have all kinds of ways we can make money through the broad HP. So that gives us a bunch of freedom, actually more freedom than I had at Microsoft because we can do things on every dimension to compete and aggressively grab market share.
And one tool we can use is price. So we can go undercut the other guy because our P&L isn't solely based on software markets. We certainly compete with other OpenStack distributions like Red Hat. So one of the reasons we're coming in at the price point we are is because we want to make it zero friction for our customer when they do that comparison of OpenStack distro A versus OpenStack distro B, at every level of comparison.
But, that said, almost everything we do is through a larger enterprise relationship. Typically when an enterprise is buying from HP they're not making a singular decision for one piece of software or one server order or one set of services. So we talk about the big picture, what our cloud platform can do, how we indemnify our distribution of OpenStack, product capabilities, pricing, the whole thing.
This is really hard when you have a business model that is pegged to one thing like software because you end up between a rock and a hard place because you can't easily discount below your margin line because it's very difficult to make that up. Microsoft has a little bit more flexibility because they have such a breadth of software and they have such a breadth of offerings. For Red Hat and VMware it's a little different because they are bound to their business model, so they have some very hard floors and ceilings in terms of what flexibility they have.
You recently acquired Eucalyptus which doesn't have big OpenStack roots. They're mostly about AWS integration. How do you see that fitting in?
Eucalyptus was really two things for us. It was a good collection of people who know how to build cloud software, and it was the AWS interoperability piece. I keep talking about choices, and we realize the design pattern of AWS is hugely relevant. So we needed the ability to tell customers, if you have or are interested in that design pattern, we have a way to support that.
So where we typically see the Eucalyptus demand is where a customer wants to have the ability to move an app out of AWS back to a private or managed cloud environment, or where someone says, I don't know what's going to happen yet in terms of going to the public cloud so I'm going to first build my private cloud apps with Eucalyptus and the AWS design pattern (basically meaning using the EC2 APIs, the S3 APIs, etc.), and building it in a way that gives me the flexibility to locate the work where I want.
What should we look for this coming year?
You'll see us continue to build out our Helion distro of OpenStack and our Helion development platform, so you'll see new services, new capabilities, that kind of thing. You'll see us do a lot in the telco/service provider/NFV space.
And later in the year you'll hear us talk a lot about a new model for enterprises that want to consume managed cloud services but don't want to buy anything physical, don't want to own anything anymore, that just want to consume, but in a way that matches their business realities today. We'll be doing a lot in that space. I'm a believer that the cloud industry we have today is going to look very different in the future as the enterprise really starts adopting cloud technologies - and then all cloud vendors will shape their strategies to fit what enterprises want. So we're trying to skate to where the puck will be and start to invent some of those new models.
You mentioned that analysts say only 10% of enterprise needs are supported by the cloud today. What's the timeframe for change?
That's the multi-trillion dollar question, isn't it? But I see two enterprise patterns happening right now and this may inform the answer. One is the linear step. I'm going to move from virtualization to private cloud infrastructure-as-a-service, then I'll try out some of this PaaS stuff to see how that really makes sense. Then I'll see if I can run that across multiple data centers and then maybe see if a public cloud thing makes sense. So it's kind of a linear mode.
The other pattern I hear, and this is the riskier one, is where the CIO says any new app inside my enterprise will be built to platform-as-a-service and can have zero knowledge of an operating system underneath it. What they're trying to do is say, let's start building in the new cloud-native model so we don't have to worry about migrations and lift and shift and all of that.
But then there's another question, and that is, which platform-as-a-service? At some point you're binding to something, you're making some commitment to some API somewhere. It may not be at the operating system level anymore. It may be higher up the stack in the middleware.
Then frequently we see customers say, we won't move our existing resources to a cloud model. We'll build the next project or the next deployment in a true cloud model. We'll build that as a stand-alone system and then try to bridge back, usually through management tools, to the old. That is very common as well.