 The Cube at OpenStack Summit at Lata 2014 is brought to you by Brocade. Say goodbye to the status quo and hello to Brocade. And Red Hat. Here are your hosts, John Furrier and Stu Miniman. Okay, welcome back. We're here live in Atlanta for the OpenStack Summit. This is the Cube, our flagship program. We go out to the events, extract the silhouettes from the noise. I'm John Furrier, the founder of SiliconANGLE and my co-host, Stu Miniman at gubon.org. Our next guest is Sage Bielfounder, chairman and CTO of Ink Tank. That guy's doing some great work and all of a sudden gets bought by Red Hat. Now everyone wants to talk to you. You're popular. Welcome to the Cube. Thank you. Good to be here. It's always good to see an acquisition happen when you have such a good partner with Red Hat. Obviously Red Hat's been great sponsoring the Cube this week. Shout out to those guys. Really, you know, Linux has just become such mainstream part of the culture these days and it was just an alternative in the past. A cheap alternative to the big guys. And now it's obviously an industry. So I'm going to get your perspective on what you guys have done. So tell us, how did all of this go down? You're just minding your own business, doing your thing, and then all of a sudden, knock on the door. Hey, tell us a story. Yeah, so, I mean, CEP is a pretty old project. We've been working on this for, well, me, almost 10 years now. Ink Tank is about two years old. So it became clear at some point that we really needed a commercial organization to support the engineering effort behind CEP and to support customers who were trying to deploy it. And we were, you know, doing very well. We were sort of in the process at this two-year point of raising a brand of capital when Red Hat came knocking sort of unsolicited. And it turned out to be a very good opportunity for us. And it went down pretty fast? It was a very fast deal, yeah. Red Hat is a great open-source company. It's sort of one of the only companies that I really feel comfortable selling to in the first place. So the timing just worked out well. Yeah, Red Hat's got a good culture. I always kind of need them a little bit. They kind of do more at their marketing, but that's not the way you do it in open-source. You market with your code, especially in a noisy world like OpenStack right now. It's pretty noisy here. It's very noisy. What's your take on this scene here? It's madness. I think OpenStack is an interesting project because there are so many companies involved and there's so much marketing budget, frankly, that it is a little bit difficult sometimes to filter out all the signal from the noise. But I think at the end of the day, we have to look at the people who are doing the actual work, who are actually deploying to real customers and who are actually contributing the code. Well, certainly Red Hat sees greatness in the queue. We thank it for the sponsorship, but we were just commenting on our opening about Red Hat having that pole position, kind of using the NASCAR analogy there. You know, the race hasn't even started yet, but if you look at what Linux is doing right now, Red Hat has a deep bench in terms of what they have to offer while everyone's kind of jockeying. And Stu and I will always watch the cars on the track, if you will. But, you know, the thing is, I don't even think the game has started yet. I asked everyone yesterday that same question. Early, early. It just seems like it just hasn't started yet. The shot's not fired yet. The gun hasn't gone off. I mean, do you agree? I don't have a real strong opinion around the open space, frankly. I think if you look at sort of the broader computing ecosystem in Linux in particular, I think one of the great things about open source is because you have all of these open projects, you have a lot of infrastructure that makes it very easy for people to bootstrap, you know, real products that add real value on top of all these projects. So I think there's a lot of opportunity here, and there's a lot of room for people to really innovate and make a market themselves. So I don't see any foregone conclusion being, you know, any particular company. It's clear that everyone likes OpenStack. It's packed house, and there's a lot of work going on. It's not like it's not a lot of fluff here in terms of, you know, people just waving their hands. They're actually arguing some work. Oh yes, yeah. There's a lot of going on. Yeah, so Sage, I'm wondering if you can help dig into, for us, kind of an open source project versus the productization. So, you know, obviously you said, Seth's been around for 10 years. Ink Tank only the last two. Obviously Red Hat has a long history in this space, and it's what everybody's trying to do. So what advice do you give and, you know, what's your experience been? I think there are a couple different models, and people go down different paths. In our case, we made a very conscious, deliberate decision to separate Seth's project from Ink Tank, the company, because we felt that it was critical, particularly for something as important as storage, to build an open platform that lots of different organizations are contributing to. You have to have a robust ecosystem with lots of partners and people who are building on top of that code. And when you sort of try to, when you're starting a company, you can name the company after the project and you can get this sort of initial momentum based on that, but in the end, you're sort of starving out the ecosystem in the long run. And so, I think some of the most successful projects make that separation. On the other hand, it's also, the open source business model is a very tough one to crack. There aren't a lot of companies that have been wildly successful in doing it. And so you also see a lot of patterns where you have companies that, you know, go with the separate branding, for example, and after a while sort of merge them again. You know, that happens with Mongo and it happens with Chef and others. And that's, you know, sometimes that works for them, sometimes it doesn't. So I think there's no sort of one right way to do it. I think it really depends on what your goals are. All right. What about Chef and OpenStack? You know, there's a lot of storage projects out there. You know, are you guys contributing? You know, what do you fit in the OpenStack ecosystem? Well, we're definitely invested in making Chef, you know, a storage platform that works very well with OpenStack. And we've invested pretty heavily in making that work as part of intake sort of business strategy because of the traction that OpenStack was getting. And specifically, when our sort of end goal is getting Chef into the enterprise, we see a lot of organizations that are deploying private clouds based on OpenStack and having that be sort of the Trojan horse to get into the organization instead of going head to head with, you know, a sand solution or something like that and trying to compete with them directly. You want to get into the cases that are more green field and where you can get in the door and get administrators and IT departments comfortable with your technology and then expand from there. Anything you could share about specific deployments and what are the customers seeing when they're trying to pair up OpenStack and Chef? I think they're seeing good things. You should look at the OpenStack user survey to see what kind of traction we're getting. Chef is one of the most common storage platforms behind OpenStack, if not the most common. I haven't looked at the latest stats yet for this particular round. So overall, I think people are sort of seeing the value of having, you know, an open software defined storage platform that they can run a commodity hardware to. You know, when people sort of buy into the cloud thesis, they're realizing that it's not about buying these monolithic systems. It's really about, you know, having something that scales, you know, horizontally and then you can deploy, you know, as you need more resources. And once you sort of buy into that thesis, then systems like Chef that are, I hate the term, but software defined in that sense are our perfect fit. And so it's a very easy style in that case. Why do you think that term is software defined? It's meaningless. All storage systems are built with hardware and software, so there's a software component and everything. I think the key distinction that's always been software defined. Exactly. Every vendor is trying to define software defined to be what they're selling, whether it's an API that's open, or whether they're plugging into an open API, or whether it's their platform itself is open. Jeremy Burton said from UMC, don't fight fashion. You know, people want to come on. That's what's fashion, you know. Technically, it's software defined. That's convenient for them. Sage, I've got a better term for you then. So Wikibon, we actually, we originally called a software-led infrastructure, and what we actually came up with early this year is what we call server sand. So server sand is a scalable architecture that allows you to take compute and storage and scale it out, and we listed there are kind of appliances that do this, there are software products, and then there's data services, and Chef is actually one of the data services that can help build those environments. Can you talk a little bit about you know, helping to build that next generation, you know, kind of scalable architecture. It's a very different challenge than traditional storage. Yes, absolutely. Yeah, so I'm wanting to hear about what Chef did, I guess. So in our case, the sort of the motivations for the system were to build something that runs on commodity hardware and had no single point of failure. So instead of investing in sort of traditional HA environments where you have to have specialized hardware, you can just back in sands where you have cross connected hosts and all that stuff to do, sort of more of the traditional HA architectures. Instead of having to invest in that type of hardware infrastructure, you can buy sort of commodity off the shelf stuff, and you're handing all of the complexity of replication and failure detection in software, and so you sort of remove the dependency on the hardware. So we like the term hardware agnostic. Not that the hardware doesn't matter because it makes a huge difference whether it's attached to Splash or whatever. But the idea is that the software component, the SethBits, are the same in other cases, really just a matter of what your performance costs for reliability trade-offs. Yeah, so I mean there's a real discussion point in the industry as to where do the services live? If you look at the big web guys, they really let the application take care of everything. Virtualization has built a lot of things into the hypervisor layer and some software pieces just take care of things like replication without going with traditional raids. So where do you see all this playing out? What is the role of storage going forward? Yeah, I think you're going to see a mix, honestly, so this is probably not what I should be saying, but you're not going to see a sort of a one-size-fits-all. As much as we like to think that Seth is a very flexible platform, they can use a lot of these different environments, there are cases where it doesn't make sense, there are cases where you have an application that's architected from the top-downs to tolerate failure, and in that case your web instances, whatever in the cloud running on ephemeral storage, and that's just fine because you architected it that way. In other situations you have legacy applications that assume that the storage is reliable, and so you need to sort of build in that reliability and fault tolerance from the bottom up. I think one of the powerful things about Seth is that you expose APIs at a number of different layers, and so you can get different levels of complexity in your API and having sort of that basic notion that you have a pool of storage that is strongly consistent and durable and highly available is a hugely liberating, just building block upon which to build other systems. So instead of having to worry about a lot of that complexity you can focus on everything that happens above the storage layer. Obviously not every solution is going to fit for all environments. Even if we look at Red Hat, you're not the first acquisition that they've made in the storage space. Can you give us a little bit of where do Seth and Gluster fit in that solution set? Yeah, so today Ink Tank is selling an enterprise distribution of Seth that focuses on the object and block use cases. OpenSat is a big piece of that. That's like 70% of our customer base, but we also have people sort of using Seth in other contexts. Red Hat is primarily selling Gluster in the file space. So just from a current product perspective there's actually not a lot of overlap. Looking forward in how technology is very flexible and allow you to sort of use them in different ways. And so Gluster can do object block and file and Seth can do object block and file. But I think the key thing is that the architectures are pretty different internally and they speak to different use cases as a result. There are different types of applications that they'll perform better for and are better suited for. And one of the nice things about this acquisition honestly is that we're sort of not forced to compete at a business level which means that the engineering teams can sort of focus on making their technology look like they're best suited for. Can you speak to some of the top use cases that you're seeing from kind of the intank side? Well, today we see a lot of block storage in the OpenSat context. I think that's probably one of our strongest places. We also see a lot of object storage. So Seth is interesting in that we provide actually two object APIs. One of them is a REST interface that gives you S3 and Swift semantics. We see that used a lot in the context of OpenSat Clouds because we want to run the same storage infrastructure as a graphic storage. It's just a simpler deployment story. But we also expose a lower level object API called the RATOS that all these other services are built on internally. And we also see that being used in sort of larger web shops and people building their own sort of web scale applications. So we have a number of customers who have Dropbox-like services that they build all the front-facing file sync stuff and they're using RATOS as the back-end storage. We see big web shots doing image sites that are storing tens, hundreds of petabytes of photos and so forth that are using RATOS as the back-end. And the new version of Seth supports erasure coding now. So that's sort of adding a new factor into the equation for the total cost analysis and so forth. What do you take on the open source movement as it evolves? We always comment on this and we always want to get people in the trenches. In a couple of days you post code and then review it in committees and just different governance models. But what do you see changing in open source for the positive and what do you see that's concerning you? I see open source being embraced wholeheartedly in the enterprise which is a huge change even from five years ago. We had a recent conversation with a CIO of a major bank and they were saying that five years ago we wouldn't have gotten the door. But today they have a mandate across the company to adopt open source which is a world of difference I think for organizations especially like Ink Tank who are just trying to get plugged into the enterprise. What do you think the reason for that is more access to developers or just better code? I think it's both of those things. Honestly I think it's a cost thing though. Organizations are realizing that open source development is just simply a more efficient way to build software. And particularly for a buyer getting some of the walk-in that you get with particular vendors means that you have a choice of hardware vendors and with its open source software you typically have a choice of different organizations that you can go to to support it. Or if you're at a large scale you can support it yourself which is usually what the web shops do. We were kind of teasing that out yesterday when we were talking to some of the folks around there's a lot of vertical applications there's no more general purpose computing architecture anymore computing software. That's changed a lot now. Do you agree? Yes. What's the most exciting thing about the acquisition that you guys have kicked in yet? Have you realized it? Have you pinched yourself? It's early days. I haven't gotten my red hat yet. I'm holding out for that. I think the most exciting for me is a couple of things. One is just the idea of being able to bring the resources of a larger organization to bear in a project like CEPF that I think has a lot of potential. I think the biggest thing is that the storage industry as a whole is really ripe for the taking. You saw a huge transformation in servers and compute with Linux over the past decade and that same transformation hasn't yet happened in storage. How big is your team now? Ink Tank was 50 when we were acquired. And you were looking to raise around what has had staff, had more developers? Exactly. It's going to be a similar resource investment either way but we have sort of the larger organization efficiencies and so forth to bring the bear. I want you to tell the folks in your own words why is this year 2014 in the tech business so buzzed up and so exciting? What's going on? What is getting everyone all jazzed up? What's happening this year that's so game changing? Is this going to be the year of OpenSack? Or the year of Linux? No, just in general. Certainly mobile is obvious but certainly frothy marketplace, a lot of developer action going on. I have a bit of tunnel vision because I'm focused on the storage space but I think in this particular environment I see huge opportunities. We're just turning the corner and seeing some widespread adoption of software based storage platforms and I think it's going to bring out a huge change. Thanks for coming on theCUBE. We appreciate it. The Red Hat DL. This is theCUBE. Extracting the signal from the noise. We'll be right back after this short break.