 Live from Seattle, Washington. It's theCUBE, covering DockerCon 2016. Brought to you by Docker. Now, here are your hosts, John Furrier and Brian Graceley. Hey, welcome back here when we are here live in Seattle for DockerCon 2016. This is SiliconANGLE Media is theCUBE. It's our flagship program. We go out to the events and extract the signal from the noise. I'm John Furrier with my co-host, Brian Graceley. My next guest is Gu Rao, who's the co-founder and CTO of PortWorks, W-O-R-X PortWorks. Welcome to theCUBE. Thank you for having me. So you're an entrepreneur. You're now in the middle of, you sold a company to Dell. You're back at the game again with PortWorks. This is your big unveiling. This is your public coming out party, if you will, you've been kind of in stealth. Take us quickly, take a spin a minute to describe what you guys have been doing when the company was founded and why now to come out. Yeah, we've been around for just a little bit over a year, but we've been investigating the space for a long time. Fundamentally, the company's been founded out of two principles. One is even when we were at Dell, we saw a need or request from customers to help move their data center to commodity infrastructure. Basically, if you wanted to get tier one capacity six, seven years ago, let's say 20 terabytes, it would almost come from your SAN or NAS vendor. Fast forward to today, Intel and its ecosystem have been making so many advances with their flash memory and I can go to Supermicro, Dell, HP, get that kind of capacity on server. Simultaneously, people have been moving towards service oriented architecture, so Docker and technologies like this make a lot of sense. So we've been working on building the storage infrastructure fabric that tied these things together, allow people to run containerized applications on bare metal servers, get the bare metal performance without a SAN or NAS. Just make it so brain dead to manage storage and that's been our mission. So was it because that years ago, it was a price of the hardware or is it more software because you could argue you go out there and get a boatload of storage, pile it up, rack and snack it. And you would have to hire a storage admin that would have to know how to configure these fiber channel switches. So it was a racket. Labor and software. That's right. Now, fast forward to today, we've sort of matured how we build software. We're no longer building monolithic application stacks with service oriented architectures. They're split into stateless services depending on stateful services, well-defined protocols, restful APIs, object interfaces. So it's easy to commoditize these things. Right? So the problem that you solve is? Storage for the commoditization era. As technology has matured, we're going to allow people to move away from legacy big iron infrastructure to just leveraging commodity infrastructure and the software tools that they use today, like Docker, the orchestration tools like Swarm. The fundamental problem we solve is allowing people to marry DevOps to their existing commodity infrastructure. How big a role does containers play in that? I mean, could you guys be at this point in your history if Docker wasn't growing at the numbers they were at? Would this work in a VM world or is it? Probably not. The timing of everything kind of lines up. Yeah, so I don't think so. And I think Docker has been really good in shining the light on how modern people build software in a more modular way. So I don't think, it would have been a lot more impedance for us to cross and because we would have had to deal with legacy, brownfield, monolithic applications. And at that point, there's less value in reinventing and storage. The existing stuff sort of just works. So the bottom line is you guys can help a customer get tier one bare metal storage. Exactly. For any app at any time as if they were provisioning cloud, if you will. Right, and we're delivered as software. We're delivered as a container. We work with your container orchestration. So we're behind the scenes and then now your teams can go back to doing what they do best, which is build their applications and manage. There's a cost perspective, but also, I mean, big cost savings. But really, it's a speed game, right? So it's more of like, if I'm scaling up, for instance, I could just... You hit the nail on the head, it's an agility game. What customers want these days is, nobody's trying to put penny pinch and cost cut. People want to be more agile. Basically, this notion of let's do things faster. If it's going to take me six months to realize that it was a failed project, I'd rather fail in days as opposed to take longer time. People want to iterate this way. Why not go to Amazon and say, just spin up Amazon? And they do. And so our storage platform is cloud native. We allow people to run their software in Amazon or on-prem and just deal with their application as a container. They don't have to re-architect something for Amazon. So you can come in with a cloud deployment. So let's just say I'm a developer and I build an app, I spin up some Amazon. Wow, this thing stuck against the wall. It's pulling everything. And it scales, wow, I'm booting up. Now I realize that I got to re-architect. So is that the use case that you guys would come in where I say, okay, I got to keep it in the cloud, but I got to bring it on-prem and stack it in the app. That's a very popular use case. People mostly, when somebody says they have cloud footprint, and they do, they'll use it for subsets of their application development, maybe even some production environments. So we don't want people to consciously say, if I'm going to run this in cloud, do I have to do things very differently? Do things the way you do it. It will run in cloud. It will run on on-prem as well. So if you want to move into cloud, come back to on-prem, or you want to move from cloud A to cloud B, all of that is possible. So when virtualization took off, people got stuck because you now put a bunch of applications, different IO profiles, and storage wasn't really built for that. It was the old sort of single lane. What are the gotchas that you guys are already seeing around containers and storage that people need to watch out for that you're good at solving? That's a great question because what containers do is they increase the density. So just to give you an example, if I could run 10 VMs on a server, when people move their applications to containers, they automatically saw that their utilization dropped because the VMs had so much overhead. So now they can pack 30 containers, or 40 containers per server. What this does is it imposes stress on the underlying infrastructure fabric. Actually, not just storage, even network. I'll give you an example. If I came to you and I said, I had 10 IP addresses per server, but now I need 30. It's more problematic for you to manage these things. And the same thing happened with storage. We've had to redesign our volume provisioning, volume management to deal with this kind of higher scale, higher density. Things are bursty. People tend to bring up containers faster, shut them down, move them around. That's got to have an impact on things like backups or snapshots or sort of everything in the storage life cycle. You've got to rethink all of that. They do because think about it this way. Before, if I had a monolithic VM, I can snapshot that VM and I'd get everything consistently. But today we've taken that code and re-architected it to run as multiple services that can run potentially on different servers. Let's just take one example that you brought up, snapshots, I want to protect it. Well, I want to protect now three or four different containers that are running on different servers. So how do you do this? And these are kind of things that you need to rethink. Your data structures are different. What's the, you know, pricing models and storages have sort of changed? It used to be massive over provisioning and then huge lock-in around maintenance and services. You know, Flash came along, you had deduplication stuff got, you know, much more somewhat efficient. What's the pricing look like around containers? Is that the right model? Are you guys looking at a different approach? Yeah, so this is a little bit less of a technical question. I think philosophically, people are moving more toward just making things simple. Just like containers are making application deployment simple. Also keep pricing simple and straightforward, easy to understand. I think server-based licensing makes a lot of sense. People don't want to be nickled and dimed on capacity because like you said, they don't know their journey. They may scale, they may burst into cloud, they may use more compute in the cloud, give them the flexibility, just have a flat server-based model and you know, things will make a lot more sense. Whether it's on-prem or in the cloud. Exactly, if it's on-prem or in the cloud, maybe you can have different prices but for on-prem or cloud, but you want to keep the pricing simple, the model simple. You were talking about the company. When have you guys funded, founded, launched? How many employees do you have? We were founded in November of 2014. We're just about 20 people. We were funded in April. Our lead investor is Mayfield. We also have an investment from Michael Dell personally. He's a big believer in the space. We've just been diligently working with customers, a couple of bellwether customers in the genomic space and in the media and entertainment. These are typically people that are indicative of where the next generation architectures are going to come from and they've been helping us build the feature sets on what we need to do. You guys are looking at the workloads. I mean, that's where you guys are probably doing well, right? I mean, the people who are doing your kind of deployments start with the app in mind and then go, okay, give me some storage. That's right. So these are typically engineering-oriented organizations. I'm not saying software engineering. Every organization has engineering of some sort. So I'm using the word engineers very broadly even to include data scientists. Yeah, they're very workload aware, very keen on how their data and compute are managed in a heterogeneous, multi-server environment. So you guys have on your website container-defined storage. Of course, we love software-defined data centers, software-defined networking. Is there going to be a container-defined data center? I think that's happening. What does that mean, by the way, container-defined? Yeah, what container-defined really embodies is let's acknowledge the fact that there's a different way in which we build and deploy software now. It's not a monolithic stack. Yes, everything is software, but the word container-defined actually justifies the fact that your application architecture in the data center looks different from what it looked yesterday. It's not VMware-based. It's your managing services deployed as containers. Your networking is aware of containers. For example, service discovery is something that you have to consciously think about. So I think the word container-defined is meant to encapsulate the different things that you're doing. Your scales are larger. You're cloud-native. You want to be aware of orchestration. You want to be DevOps-friendly, allow for people to programmatically deploy applications. Let's take the last few minutes to talk about your products. You have a DevOps product and an enterprise product. Status of the product, available price, examples of successes, customers. Yeah, sure. So the developer product, which is called PXDev, has been available for some time now. It's really meant for the DevOps teams to get a feel for what can be done. It's free for use. The limitations are lack of an enterprise user interface and reporting. While we are a scale-out block storage, we have additional features like a global namespace. So that's missing in the developer product. The enterprise product obviously comes with support, scales to many servers. It has the features that I talked about. There's container granular user interface reporting from a storage standpoint. So you can manage your servers. If drives are failing, we will notify you and things like that. And that's available too. And that's available. We announced general availability of that. We will be announcing our customer installs very shortly. Like I mentioned, we're in various stages of POC to semi-production with a couple of bellwether customers, media and entertainment, life sciences. You said some of them are walking around here. They're all taking it all in. So I'll ask a last question. So Michael Dell's got his hands pretty full with some storage things today. What does he see in you guys that he said, I want to make a personal investment in your technology, your people. What's that connection point that he sees? So I think, obviously Michael Dell doesn't need the investment return. But what he's very technically aware of what's going on in the industry. And he's got a good sense for next generation technologies. Obviously he's proven that. What his interest in this is to see how compute is going to change. And our whole value proposition has been, look as time goes on, maybe there's a less of a difference between the storage admin and a server admin. Like I mentioned, when you buy a server today, it already has tier one capacity. So we've been seeing a lot of storage purchase happen from the server procurement guys. And I think he wants to keep his eyes on what's going to happen, especially as containers allow these to become hyper-converged compute nodes. So I think that's been, and I'm obviously speaking out of school here, he would be the best person to ask this, but that would be my guess. Good, thanks for coming on theCUBE. Congratulations, Portworx launching products available. Congratulations, a new approach to storage. Container defined storage. Love the tagline. And I really think it's relevant, I think the application focus is great stuff. Thanks for coming on theCUBE, really appreciate it. Live here at DockerCon 2016, you're watching theCUBE. We'll be right back with more after this short break.