AP - Fotolia

OpenStack private cloud meets high IO demands

When costs of higher-IO workloads escalated in public cloud, media company Ooyala turned to a managed OpenStack private cloud.

While OpenStack has gained attention and popularity among cloud-savvy adopters, it is far from easy to implement and manage within the data center. When Ooyala, a media company that provides video technology to some of the largest broadcasters in the world, wanted to pull its higher-IO workloads back in-house, its team looked to OpenStack private cloud. But it didn't go it alone.

SearchCloudComputing.com spoke with Ilan Rabinovitch, engineering manager of infrastructure and reliability at Ooyala, about the company's decision to move to OpenStack nearly three years ago, how it operates in a multi-cloud environment and some of the quirks associated with that.

Why did you look to OpenStack? What was the first implementation?
Ilan Rabinovitch: Ooyala was born in the cloud. We've been using AWS as a cloud provider since 2007. Our co-founders were the winners of the first AWS startup challenge, so cloud and automation were very much in our DNA. As we were looking to make use of our own on-premises data centers, we had been spoiled rotten by the ease of use with APIs with things like AWS. There was just a lot of automation we were able to accomplish that sped up our work. We didn't want to go backward as we were coming back into our data center and expanding there. So OpenStack was a very natural decision. We wanted that same ease of use and automation that we were getting in AWS and other cloud providers.

Ilan Rabinovitch

What was the reason for going back into the data center?
Rabinovitch: In general, we were finding that cost for IO was a lot higher in a lot of the cloud vendors we were working with. And for a lot of the big data analytics needs -- where IO was really king in terms of our workloads -- that was helping us to be a lot more successful there.

A lot of your team members are contributors to the open source community. Does having an open source background make a difference with OpenStack?
Rabinovitch: We try to be active participants in the open source community -- sometimes we get to work with vendors like MetaCloud and Cisco to sort of be our karma cleansers, where we don't have the bandwidth to contribute but we do want to use [a technology]. The nice thing about working with Cisco/ MetaCloud, we get to treat our data center the same way we would treat AWS and Azure. We're consumers of the OpenStack service offered to us, it just happens to be running in our data center on the hardware we prefer. We didn't have to become experts in all of the bits and pieces of how OpenStack fits together. It's a fairly complex framework and if you go back two or three years, it was a fairly difficult task to get all these different pieces together to get a working private cloud. That would have taken a full-on team just within Ooyala.

As we were looking to make use of our own on-premises data centers, we had been spoiled rotten by the ease of use with APIs with things like AWS.
Ilan Rabinovitch, engineering manager of infrastructure and reliability at Ooyala

Has it gotten easier to put those pieces together?
Rabinovitch: I think there are a number of OpenStack distributions that have come together. I liken it to Linux distributions; you can build yours from scratch, but in many cases, that doesn't make sense. You're going to work with somebody who has already pre-packaged all of these pieces together for you. OpenStack, in general is a very open framework. You can build it in a number of ways.

Did you look at any other private cloud platforms?
Rabinovitch: We looked at some other OpenStack vendors at the time. We also looked at CloudStack and Eucalyptus. Looking at just the momentum OpenStack had, we knew that was the direction we wanted to go. With other vendors, there were a number of other organizations that would come in and be an OpenStack consultancy. They would come in and set up OpenStack for us and then they would hand it off to us to run moving forward. That's very different from a managed service. If and when there's an issue with OpenStack, we get on the phone and call MetaCloud. It's a very different situation than some of the consultancies that were out there. That, combined with the background of the MetaCloud team having come from a number of large-scale Web operations, made us trust in their abilities.

What other cloud providers does Ooyala use and how?
Rabinovitch: We rely on OpenStack as well as AWS and Azure. We have bits of every type of workloads in each environment. Some of the clouds are suited to different workloads. For example, some of our higher IO workloads have been a better fit for OpenStack environments in our data center. That being said, we also have international presence with OpenStack where some of the cloud vendors at the time did not have a point of presence, so we went to build something out with MetaCloud.

How do you manage this multi-cloud environment? Do you use third-party tools or native tools from each provider?
Rabinovitch: It's a mix. We've built quite a bit ourselves internally. So many of these tools are things we built back when we were EC2 only or primarily EC2. Now that we're working with other clouds, whether it's our own internal OpenStack or Azure, who has APIs present and we extended these tools to use them. There are a lot of great libraries out there that make that possible. We're very excited about tools like Chef Provisioning or Terraform from HashiCorp, which make it a little more straightforward to use the same language for resources across all clouds.

AWS has CloudFormations and OpenStack has things coming along with Heat; we could build using those, but we'd be building the same thing each time for each cloud. We are hoping to see a lot of these frameworks come together to offer a unified API across all vendors.

What are the biggest obstacles with being a multi-cloud company?
Rabinovitch: In many cases, we're working with effectively the lowest common denominator in terms of the technologies and services cloud vendors offer. I don't know if I would call that a challenge; I'd say it's an interesting quirk. A lot of companies, when you just get started in EC2 or Azure or OpenStack, you jump in and use CloudFormations and Elastic Load Balancing (ELB) and Auto Scaling Groups. If you're going multi-cloud, you have to decide early on that that's something you want to stick to your guns on so as not to lock one of those workloads into a particular place. Or you have to build that flexibility into your app so that you are able to work with the DynamoDB and Azure's equivalent data stores interchangeably. That's a big caveat.

The other is the tooling. For a long time, a lot of the [tool] vendors out there had picked one cloud to support, either on reporting or automation. That's starting to change, but effectively, we had to build a lot of these tools ourselves based on how early on we adopted these projects. I'd say that's been a big piece for us -- finding ourselves in the situation where we're building a lot of that automation and orchestration/tooling in house, rather than having a particular tool we could adopt. If you look at most cloud management vendors now, they support all of the clouds or many of the clouds, especially AWS, OpenStack and Azure. Over the next year or so, you'll see that simplifying the process of being a multi-cloud company.

Michelle Boisvert is Executive Site Editor for SearchCloudComputing.com. Contact her at [email protected].

Next Steps

How to find OpenStack development support

Pros and cons to open source cloud computing

Building an OpenStack storage cloud from scratch

Dig Deeper on AWS cloud platform