 Live from Boston, Massachusetts, extracting the signal from the noise, it's theCUBE, covering Red Hat Summit 2015. Brought to you by Red Hat. Now your hosts, Dave Vellante and Stu Miniman. Welcome back to Boston, everybody. This is theCUBE, and we're here live at Red Hat Summit at the Heinz Convention Center. This is day two of theCUBE, day three of Red Hat Summit. Open source, OpenShift, Paz, no, Paz is kind of old schools, Stu, we're hearing, Docker, containers, all kinds of cool stuff going on. Delano Seymours here is the CTO of Sixth Fusion. Delano, thanks for coming on theCUBE. Thank you, thanks for having me. Yeah, so, a lot of good action going on here. Tell us, let's start with Sixth Fusion. What do you guys do? You're a partner of Red Hat, what's your shtick? All right, Sixth Fusion is a company that's set out to create a way to meter consumption for IT. We want to do it in a pretty interesting way, and that is meter IT, like you meter electricity. So we've created a standard unit of measure for consumption in the IT world, and then we apply that to allow people to use that unit to build their customers based on usage and consumption. So their objective is to make sure they're charging out appropriately, is that right? That's correct. So in some models you might, it's like that, trying to fill the box, you know, you have a box trying to fill it with rocks versus sand, so you don't necessarily fill the whole box if you're billing by the box. So what we do is try to measure exactly what you use, like water, you know, putting water in that. So it used to be easy, it used to be MIPS. How many MIPS you got in your shop? Exactly. Okay, so what's the measurement today? So we call it the Workload Allocation Cube, and Kilowack for short. It is similar, it creates a little grim and people heard that, but it's similar to a kilowatt, right? So we want to create that measurement for consumption similar to electricity. And it stands for Workload Allocation Cube. Cube? Yeah, like the cube. Like the cube. Yes. Okay. And then how does that translate into dollars, which is ultimately what people want to know? So what makes up that Workload Allocation Cube is six main resources that we measure, and then we combine that algorithmically to create that one unit of measure. The six resources is CPU, memory, storage, and then three IOs, disk IO, LAN IO, and LAN IO. So what we're trying to do is encapsulate what a particular workload or application consumes of a particular infrastructure. So disk LAN and WAN? Yes. IO? Okay. All right, and so that's all the infrastructure. Yes. Well, that's technically what the application itself or the workload is consuming out of the infrastructure. We look at infrastructures like generators. Okay, great. That's the way you should look at it. Exactly. It's the whole thing of utility. Exactly. And application focus, which is nice. I mean, so much, we spent for years at Wikibon trying to talk about charge back, but really even getting to show back was kind of tough. Exactly. I kind of understand it because usually you're starting from the infrastructure, the bottom and working up, and you're starting from the application layer and looking down. Exactly. That's exactly how we do it. And OpenShift presents a nice package for us. In fact, containers present a nice package for us because that container is closer to the processes versus trying to meter it at the sort of machine level. So being able to meter it higher up the stack makes it get us closer to the application and closer to the workload. So what is the meter? You somehow probe that system? Yes, so we build software for, we build meters. Software meters. That's what we do, yes. Software meters. And those meters basically are used to meter a particular infrastructure. Our premise is to meter from the outside. So we never want to be inside like an agent because then that affects the consumption of the actual thing we're metering. So we basically create meters that then interrogate the whole infrastructure. So be a group of virtual machines, containers, whatever, physical machines, and then report back to usage. So you're looking for, okay, what's the application doing? Exactly. And what resources is it consuming? That's correct. And then it gets to how much does that cost? And that's an internal cost. Exactly, so the way we do cost, we make it simple, right? It's a dollar per kilowatt. So you just add a dollar figure to the unit and some infrastructures are high-performing infrastructures. Some infrastructures are low-performing infrastructures. Therefore, you can adjust costs based on performance. So does a customer take their, you don't really care what they do. The system doesn't care. Put whatever input in you want it. But what do customers typically do? What's best practice? Do they take their capital budget? Do they take their operating budget? Do they take a blend? So what we sort of do is quote, unquote, start away, because it could, every company is different. They do their own ways of allocating resources. But the start away is to basically take your fixed costs and your operating costs and boil it down to a price per month that you use to, that it costs you to run that infrastructure. And then what we do is we have a methodology to find out the capacity, the productive capacity of your infrastructure. So now you know the productive capacity. You know what it costs you. You can divide that up and say how much per kilowatt you're going to charge. So most customers can probably get to that figure reasonably easily, right? Correct. I mean, it's when you ask them to figure out exactly what you're doing, right? I've dealt with a zillion customers before. How much does each application consume? They're like, hi, hi. Right, but that's what we do. So you know your costs. We know what the applications are consuming. But what they normally do is they call a PWC and they send in an army of people and they take six months. That's right, a million dollars and then they get the answer. Can you just walk us through kind of the scope of what infrastructure you can cover, what environments, as well as are there limitations as to which applications you can look through? Yeah, so currently we support virtualized environments. So VMware is one and Zen is another. And then we also support physical hardware but that's where we have to put agents unfortunately for physical hardware. So we support Windows and Linux. And then what we're working on now is to add OpenShift to our list of supported platforms to meter and monitor, meter containers. Okay, so great. So you've had this offer for a while and now you're getting into OpenShift. Why don't you walk us through what led you to OpenShift? Why is it a fit for what you're doing at Sixfusion and ultimately what's the benefit for your customers? All right, so what led us to OpenShift is that we created a prototype and said, I think this will work with OpenShift but we wanted to find out what the customers feel. So we met a couple of folks at OpenShift and they recommended us to the OpenShift commons where we did sort of a briefing of our prototype. And once the customers were able to see our prototype through OpenShift commons, then we got some feedback from the customers about what to do, how to make it better, what to change, what are they looking for? And we find that a lot of people find that they need the metering, especially with OpenShift because being able to meet a group of containers that are very transient, they come and go is kind of tough. Yeah, it's a great point. I mean, I think when we launched virtualization we worried about VM sprawl. And I've heard in the container world there's concern about microservices, you could have services that are just growing out, they're almost like a sprawl there. So having some way to understand it should be really useful. Exactly. And being able to track that. All right, go ahead. So that co-creation is really interesting too. Where are you along the development of this? How long do you think it'll take you to kind of fully embrace OpenShift? Right, so currently we're in the phase where we're doing the planning for our product. So we've done the prototype phase, we know what ideas we want to build, and now we're working towards the productization of our plans. So I can't really say when that will be released at this point, but we hope it's going to be released within the year. So this is a good example of internet of things. Yeah, exactly. In fact, we have lots of them. So, okay, so take us through a typical customer scenario. So you come in and say, okay, I have a problem. What's the typical problem that they'll tell you? I don't know what's going on in my infrastructure, where I'm spending, where I'm consuming, help me sort that out so that I can charge back or just so that I know. Right, so we have a lot of use cases. The main problem here, people say, I don't even know what my state of affairs are. So we have a bench line in process where we say, okay, great, we'll install our meters and we can tell you what you're consuming today. Create a baseline. Create a baseline. And then the next step is, okay, after I have a baseline, I then want to either optimize, might be a path that they take. I want to make my costs, I want to lower my costs by improving my consumption rates and my consumption patterns, or they might decide that they want to take that particular infrastructure and move it to a cloud platform or a pass or some other platform, because that's what they were thinking of doing and needed to know what that could potentially cost. Of course, in most common cases, that they just want to be able to charge back or build back the consumption to the constituents. What do you do with all the data that you collect? Well, we keep it all, number one. But we all, our company is theoretically a data company. So the meters are a means to an end. We want to be able to provide information to our customers about trends and about market consumption patterns of applications and trends in the market because our ultimate goal is to trade compute. To trade compute? Yes. Yeah, so I mean, I would think you could tell me, look, you're consuming this for these applications and you're way over consuming compared to the, here's the mean. Right. You're over here. Exactly. You should be here. If you want to get here, these are the things that you have to do. Exactly. We can basically say that, listen, you're 50% more than a particular company in your vertical or in your market. So you want to create a marketplace? That's correct. Kind of the, well, it's really not Uber, but it's Uber-like. It's got extra capacity here. Let's use it over here. That's correct. So what's the technology that is required to enable that? I mean, you got to, first of all, you got to have a transaction system. I guess that's probably the easy part, you got to have a way to share that resource. Right. So our goal is not to move from Berkeley to Ron. That's not the business we want to be in. Our goal is basically to track and provide reporting to our customers. We want to be similar to like the Bloomberg of IT. So we want to be able to help our customers, whether they be buyers of IT or suppliers of IT to get more informed information to make decisions on what they do. I'll give you an example. You might have particular application types that are common in the market or in the world, and you have to now decide if you want to build a new infrastructure. That design of that infrastructure should fit the common market workload types that exist, the common consumption patterns. So being able to give that information to suppliers is something that could be useful. Yeah, that's really interesting. You know, I think back to the early days of VMware. We knew that VMware could really consolidate workloads because we were hugely underutilizing what we had today. I'm curious, do you have, you know, what is kind of standard or best practice today? Because we argue internally, my CTO when I came on board, I said, oh yeah, customers are getting, you know, 25, 30% he's like, stoop, they're getting like 10% if they're good. And if they're heavily virtualized and use a lot, you know, maybe they're getting 20%. And the hyperscale guys, you know, maybe you're getting a 50% or more certain environments where they might bake some out to get a little bit higher, but it's rare to see somebody, you know, really utilizing what they have. And therefore that's a lot of, you know, kind of waste out there. That's correct. For us, when we go into customers, generally we find that they get around the 30 to 40% of their usage, of their capacity, I should say. And so what we want to encourage customers to do is understand that and then figure out what they can do to improve that. Now you can't just throw any workload on any box. It has to be workloads that fit together like a puzzle. And so being able to help customers, you know, mix and match the right workloads is also part of the benefits of our product. So, you know, from a success story, you know, it says 30 to 40% is kind of pretty good today. Well, you know, what do you get them up to? What was the success and, you know, do you give them some hero numbers that they go back that justified, you know, spending money with you? Right. So from my point of view, I can't really say that we changed that game for them. I think we're more of the company that helps them understand what to do next. And therefore we don't get the outcome after they make their decision, but I think that's something we could probably look into. How big a company are you? Employee size, revenue, whatever metrics you want to share with us? Yeah, we're a small company, we're a startup. So we have about 15 employees. One five. One five, very small. And private, obviously self-funded? Private, yeah, privately funded, yeah, privately funded. So we do have two venture partners, grow tech partners, grow tech ventures, and I can't forget them. So you're taking VC money, that's okay. We do have VC money. The other ones. So talk a little bit more about the tech behind Six Fusion. What's your role as CTO? What are you sort of cobbling together? What's the secret sauce? You want me to tell you the secret sauce? Well, I mean, just, you know, conceptually. Custom, I want you to get me, you know, all excited. All right. Without giving away the store. We'll get a little whiteboard for you if you could please show us the diagram. We'll take some pictures. It's like an episode of Silicon Valley. Yeah, I bet like that episode too. How do you do that? So I mean, our main secret sauce is the way in which we combine those six metrics together to make one. That's our main secret sauce. That algorithm that you use. That algorithm that we use. After that, it's simple. And that's our goal, is to make it simple. We want to make it just as simple as how you buy electricity, right? You just walk in, you say, I need you to hook a meter to my house and you pay every month what you consume. So just want to make it simple. And you don't unpack that algorithm for your customers? We don't, but we don't hide the six metrics either. So we give both the consumption numbers and the six metrics. So you get seven metrics out of that. Do people ever say, it doesn't look right to me? Do they ever say that? People... Or do they not say that because they just don't know? Well. If they just don't know, then you can tell them anything. Yeah, most people look at the six metrics and they're like, okay, this makes sense. Because it's not like we hide the six metrics. So they can go and look at it and say, okay, I understand what you're doing. But they don't challenge you how you got there. They don't really care at that point. Because they know it all adds up to a hundred percent. That's really what they care about. That's correct. So we don't have much challenge. Actually in a lot of ways they say, hey, it's not us. We have this independent software framework that allows us to do that. And we're not the buyers or the sellers in this equation. We have no ulterior motives here. We're not here to sort of get them to buy more of what they're already buying. Our goal is to just make it visible to you. So you can make a good decision. Is that tech patentable or is that? Yes, we do have a patent. You do, on the algorithm. Yes, it already exists. And approved. We could look it up then. That's right. Just go in line. It is public. So your software started out in the virtualized world and you're starting to look in containers. Is OpenShift what helps you to get there? You know, do we think containers is going to greatly change how utilization is done? And I just, what's your mindset around containers? So, first of all, containers, like I mentioned earlier, allows us to get higher up the stack, right? We can go into the machine and see what the applications and the processes are consuming. And what I like about OpenShift is that they allow, they take containers and turn that into services. And being able to see the, say, 10 or 100 containers that are operating together to perform a particular function is what we want to meter. What the customer cares about, right? The individual containers might not necessarily be that useful. Okay, cool. So you've been working the booth here at the show. Bring us in, what comes to your conversation we're having? You know, what are the challenges they're facing? You know, how many good conversations do you have and they kind of fit what you're looking at? Yeah, we're having a lot of good conversations. In fact, people, after seeing me on the comments, doing a video on the comments, they just walk up to me and say, hey, yeti guy, on the comments, talking about meter and microservices. And I'm like, yes, and I give them a little brief and they're saying this is exactly what we need. We're getting people from different countries as well, first from Singapore, came up to us today to talk about how they can use this in one of their customer engagements. So we are getting some good feedback. Of course, we were at prototype stage, so until we can actually get this product in their hands, we'll have to see what comes after that. All right, so what's next for you guys? You're trying to get into that sort of business of putting buyers and sellers together. What's the timeframe for that and when should we expect that? So we're already working with a partner we call UCX, partner named UCX, that is already working in parallel with us in order to get the idea of trade and compute in the minds of people. So I believe our timeline right now is to get it done in the next year to two years, is to get people using the WACC and being familiar with it in their everyday processes. And how about the last word on Red Hat Summit, your partnership with Red Hat? Yeah, I think Red Hat was awesome in sort of welcoming us into their partner ecosystem and through the comments, that was a great way to, one, get information about OpenShift and two, to meet some folks that potentially could be customers for us, so we're very appreciative of Red Hat. Delano, see more cool stories, Six Fusion, really interesting and solving a problem that's been around for a long, long time is what am I consuming? So thanks very much for coming in theCUBE, really appreciate it. Thank you very much for having me. All right, keep right there, everybody. We'll be back with our next guest right up to this. This is theCUBE, we're live from Boston, Red Hat Summit, we'll be right back.