 From around the globe, it's theCUBE with coverage of KubeCon and CloudNativeCon Europe 2020, virtual brought to you by Red Hat, the CloudNative Computing Foundation and ecosystem partners. Welcome back. This is theCUBE's coverage of KubeCon, CloudNativeCon, the European show for 2020. I'm your host, Stu Miniman. And when we talk about the container world, we talk about what's happening in CloudNative. Storage has been one of those sticking points, one of those things that has been challenging that we've been looking to mature and really happy to welcome back to the program. Two of our CUBE alumni to give us the update on the state of storage for the container world. Both of them are co-founders and CEOs. First of all, we have Shang Liang from Rancher Labs who of course was recently acquired by SUSE and the intention to acquire. And also joining us, Merlee, the Rumele who is with Portworx, Shang and Merlee. Thanks so much for joining us. Thank you. Thank you, Stu. All right. So Merlee, actually I'm going to start with you just because we've seen a couple of waves of companies working on storage in this environment. We know storage is difficult. And when we change how we're building things there's architectural things that can happen. So maybe if you could just give us a snapshot. Portworx was created to help attack this straight on here in 2020, where you see things in the overall kind of container storage landscape. Absolutely, Stu. Before I kind of jump into Portworx I just want to take a minute to publicly congratulate the whole Rancher team and Shang and Shannon and Will-Chan have known those folks for a while. They're kind of true entrepreneurs. They represent the serial entrepreneur spirit that so many folks know in the valley. And so great outcome for them. We're very happy for them. And a big congrats and shout out to the whole team. Portworx is a little over five years old and we've been kind of right from the inception of the company, recognized that to put containers in production you're going to have to solve not just the app orchestration problem but the issue of storage and data orchestration. And so in a nutshell, Kubernetes orchestrates containers and Portworx orchestrates storage and data. And more specifically by doing that what we enable is enterprises to be able to take apps that are containerized into production at scale and have high availability, disaster recovery, backup. All of the things that for decades IT has had to do and has done to support application reliability and availability, but essentially we're doing it with a purpose built solution for containerized workloads. All right, Shang, of course, storage is a piece of the overall puzzle that Rancher is trying to help with. Maybe if you could just refresh our audience on Longhorn, which your organization has, it's open source, it's now being managed by the CNCF is my understanding. So help us bring Longhorn into the discussion. Thanks Stu. So I'm really glad to be here. I mean, we've, I think Rancher and Portworx started about the same time and we started with a slightly different focus. I think more is exactly right to get containers going. You really need both sort of the compute angle, orchestrating containers, as well as orchestrating the storage and the data. So Rancher started with a slightly stronger focus on orchestrating containers themselves, but pretty quickly we realized as adoption of containers grow, we really needed to be able to handle storage better and like any new technology, Kubernetes and containers created some interesting new requirements and opportunities. And at the time, really, there weren't a lot of good technologies available. Technologies like Rook and Ceph at the time was very, very premature. I think we actually early on tried to incorporate the cluster technology and it was just not easy. And at the time, I think Portworx was very busy developing what turned out to be, you know, their flagship product, which we ended up partnering very, very closely. But early on, we really had no choice but to start developing our own storage technology. So Longhorn as a piece of container storage technology is actually almost as old as Rancher itself. One of our founding engineers we hired, he ended up, you know, working on it. And then over the years, you know, the focus shift, I think the original version was like returning C++ and over the years, it's now being completely rewritten in Goland. It was originally written more for Docker workload. Now, of course, everything is Kubernetes centric. And last year, we decided to donate the Longhorn open source project to CNCF. And now it's a CNCF sandbox project. And the adoption is just growing really quickly. And just earlier this year, we finally decided to, we're ready to offer a commercial support for it. So that's where Rancher is and with Longhorn and container storage technology. Yeah, it had been really interesting to watch in this ecosystem. Couple of years ago, at one of the CubeCon shows, I was talking to people coming out of the, I believe it was the SIG, the special industry group for storage, and it was just like, wow, it was heated. You know, words were, you know, back and forth. There's not a lot of agreement there. Anybody that knows the storage industry knows that, you know, standards and various ways of doing things often are contentious and there's differences of opinion. Heck, look at the storage industry. You know, there's a reason why there's so many different solutions out there. So maybe, I'd love to hear from Merley from your standpoint, sounds like things are coming to get a little bit more. There are still a number of options out there. So, you know, why is this kind of co-opetition actually good for the industry? Yeah, I think this is a classic example of co-opetition, right? Let's start with the cooperation part, right? The first part of that. The, you know, the early days of CNCF and even sort of the Google Kubernetes team, I think, was really very focused on compute and subsequent years, in the last three, four years, there's been a greater attention to making the whole stack work because that's what it's going to take to take a enterprise-class production and put it in, you know, enterprise-class application and put it in production. So extensions like CNI for networking and CSI Container Storage Interface were kind of put together by a working group and, you know, both in the CNCF but also within the Kubernetes Google community that you talked about, say, storage as an example. And, you know, as always happens, right? Like it looks a little bit in the early days like a polo game, right? Where folks are really, you know, seemingly, you know, working with each other on top of the pool but underneath, they're kicking each other furiously. But that was a long time back and we've graduated from then into really cooperating and I think it's something we should all be proud of where now the CSI interface is really a really, very, very strong and complete solution to allowing Kubernetes to orchestrate storage and data. So it's really strengthened both Kubernetes and the Kubernetes ecosystem. Now, the competition part, let's kind of spend, I want to spend a couple of minutes on that too, right? You know, one of the classic things that people sometimes confuse is the difference between an overlay and an interface. CSI is wonderful because it defines how the two layers of essentially kind of old style storage, you know, whether it's a SAN or a cloud, elastic storage bucket or all of those interact with Kubernetes. So the definition of that interface kind of lays down some rules and parameters for how that interaction should happen. However, you still always need an overlay like Portworx that actually drives that interface and enables Kubernetes to actually manage that storage. And that's where the competition is. And you know, Shang mentioned Seth and Gluster and Rook and kind of derivatives of those. And I think those have been around really venerable and really excellent products for a born in a different era for a different time, open stack object storage and all of that, not really meant for kind of primary workloads. And they've been trying to be adapted for us for this kind of workload. Portworx is really a built from right from the inception to be designed for Kubernetes and for Kubernetes workloads at enterprise scale. And so I think, you know, as I look at the landscape we welcome the fact that there are so many more people acknowledging that there is a vital need for data orchestration on Kubernetes, right? That's why everybody and their brother now has a CSI interface. However, I think there is a big difference between having an interface versus actually having the software that provides the functionality for HA, DR and for backup as the kind of lifecycle matures and doing it not just at scale, but in a way that allows kind of really a significant removal or reduction of the storage admin role and replaces it with self-service that is fully automated within Kubernetes. Yeah, if I can, you know, add something to that I completely agree. I mean, over the years, Longhorn's been around for a long time, like I said, but I'm really happy that over the years it hasn't really impacted our wonderful collaborative partnership with Portworx. I mean, Portworx has always been one of our premier partners. We have a lot of common customers and as far as I know, these guys rave about Portworx. I don't think they'll ever get off Portworx, Longhorn or not. Lee, exactly like Maury said, in the storage space, there's interface which a lot of different implementations can plug in and that's kind of how Rancher works. So we always tell people Rancher works with three types of storage implementations. One is, we call legacy storage, your NetApp, your EMC, your Pure Storage. Those are really solid, but they were certainly not designed to work with containers to start with, but it doesn't matter. They've all written CSI interfaces that will enable containers to take advantage of. The second type is some of the cloud block storage or file storage services like EBS, EFS, Google Cloud Storage and support for these storage backend, CSI drivers practically come with Kubernetes itself. So those are very well supported, but there's still a huge amount of opportunities for the third type of, we call container native storage. So that is where Portworx and Longhorn and other solutions like Open EBS, StorageOS, all these guys fitting is a very vibrant ecosystem of innovation going on there. So those solutions are able to create basically reliable storage from scratch, you know, from just local disks. And they're actually also able to add a lot of value on top of whatever traditional or cloud-based persistent storage you already have. So the whole ecosystem is developing very quickly. A lot of these solutions work with each other. And I think to me, it's really less of a competition or even co-op petition. It's really more of raising the bar for the capabilities so that we can accelerate the amount of workload that's been moved onto this wonderful Kubernetes platform in the end it'll benefit everyone. Well, I appreciate you both laying out some of the options. You know, Shane, just quick follow-up on that. And I think back, if you went 15 years ago, it was often, oh, okay, I'm using my EMC for my block. I'm using my NetApp for the file. I'm wondering in the cloud native space if we expect that you might have multiple different data engine types in there. You mentioned, you know, I might want port works for my high performance. You said OpenEBS, very popular in the last CNCF survey might be another one there. So do we think some of it is just kind of repeating itself that storage is not monolithic in a microservice architecture? You know, different environments need different storage requirements. Yeah, I mean, quick, I love to hear Mori's view as well, especially about how the ecosystem is developing. But from my perspective, just a range of capabilities that's not we expect out of storage vendors or data management vendors is just increased tremendously. You know, in the old days, if you can store blocks, store objects, store file, that's it, right? So now this is just table stakes. Then what comes after that will be three, four, five additional layers of requirements come all the way from backup, restore, DR, search, indexing, analytics. So I really think all of this could potentially all fall in the bucket of the storage ecosystem. And I just can't wait to see how this stuff will play out. I think we're still at very, very early stages and what containers did is they made fundamentally the workload portable, but the data itself still holds a lot of gravity. And there's just so much work to do to leverage the fundamental workload portability, marry that with some form of universal data management or data portability. I think that would really unleash the industry to the next level, Maury. Yeah, Shang, I mean, couldn't, you know, I've said it better, right? Let me kind of give you a sample, right? We're at about 160 plus customers now, you know, adding several by the month, just with Rancher alone, right? We have common customers in Qualcomm, NVIDIA, Expedient, Roche, Marchex, Western Asset Management, you know, charter communication. So we're in production with a number of Rancher customers. Now, what do these customers want and why are they kind of looking at a porkworks class of solution to use, you know, Shang's example of the multiple types, right? Many times people can get started with something in the early days, which has a CSI interface with maybe say 10 nodes or eight to 10 nodes with a solution that allows them to at least kind of verify that they can run the stack up and down with say, you know, a Rancher type orchestrator of workloads that are containerized and a network plugin and a storage plugin. But really once they start to get beyond 20 nodes or so, then there are problems that are very, very unique to containers and Kubernetes that pop up that you don't see in a non-containerized environment, right? Some, what are some of these things, right? Simple examples are how can you actually run 10 to hundreds of containers on a server with each one of those containers belonging to a different application and having different requirements. How do you actually scale not to 16 nodes which is sort of typically maybe max of what a sand might go to, but hundreds and thousands of nodes like many of our customers are doing, right? You guys like T-Mobile, Comcast, they're running this thing at 600,000 of nodes. So scale is one issue. Here is a critical, critical difference that something that's designed for Kubernetes does, right? We are providing all of the storage functions that Shang just described at container granularity versus machine granularity. One way to think about this is the old data center was a machine-based construct. Everything, you know, VMware is the leader sort of in that. All of the way you think of storage is via lunch. You think of compute and CPUs. Everything sub-subnets, right? All of traditional infrastructure is very, very machine-centric. What Kubernetes and containers do is move it into becoming an app-defined control plane, right? One of the things we're super excited about is the fact that Kubernetes is really not just a container orchestrator, but actually a orchestrator for infrastructure in an app-defined way. And by doing that, they have turned, you know, control of the infrastructure via Kubernetes over to a Kubernetes admin. The same person who uses Rancher uses Portworx at NVIDIA, for example, to manage storage as they use it to manage the compute and to manage containers. And that's marvelous because now what has happened is this thing is now fully automated at scale and actually can run without the intervention of a storage admin. No more trouble tickets, right? No more requests to say, hey, give me another 20 terabytes. All of that happens automatically with a solution like Portworx. And in fact, if you think about it, in the world of real-time services that we're all headed towards, right? Services like Uber now are expected in enterprises, machine learning, AI, all of these things, analytics that Cheng talked about are things that you expect to run in a fully automated way across vast amounts of data that are distributed, sometimes in the edge. And you can't do that unless you're fully automated and not requires storage admin intervention. And that's kind of the solution that we provide. All right, well, we're just about out of time. If I could, just the last piece is, you know, Merley and Cheng, to talk about where we are with Longhorn, what we should expect to see through the rest of this year. And I guess Merley, for you too, you know, what differentiates Portworx from just, you know, the open source version. So Cheng, maybe if we start with just kind of Longhorn in general, and then Merley from your standpoint. Yeah, so the goal of Longhorn is really to lower the bar for folks to run state for workload on Kubernetes. We want, you know, Longhorn is 100% open source and it's owned by CNCF now. So we, in terms of features and functionalities, it's obviously a small subset of what a true enterprise grade solution like Portworx or EMC or NetApp could provide. So there's just, you know, the storage feature set or the roadmap is very rich. I don't think it's not really Rancher's goal or Longhorn's goal to, you know, to try to turn itself into a plug-in replacement for these enterprise grade storage or data management solutions. But there are some critical feature gaps that we need to address. And that's what the team is going to be focusing on perhaps for the rest of the year. Yeah, Stu, I would kind of echo what Cheng said, right? I think folks may get started with solutions like Longhorn or even a plug-in, like a connector plug-in with one of their existing storage vendors, whether it's pure NetApp or EMC. From our viewpoint, that's wonderful because that allows them to kind of graduate to where they're considering storage and data as part of the stack. They really should, that's the way they're going to succeed by looking at it as a whole. And really, you know, there's a great way to get started on a proof-of-concept architecture where your focus initially is very much on the orchestration and the containerization part. But as Cheng pointed out, you know, what Rancher did, what Rancher did for Kubernetes was build a simple, elegant, robust solution that kind of democratized Kubernetes. We're doing the same thing for Kubernetes storage, right? What Portworx does is have a solution that is simple, elegant, fully automated, scalable and robust, but more importantly, it's a complete data platform, right? We go where all these solutions start but don't kind of venture forward. We are a full, complete lifecycle management for data across that whole lifecycle. So there's many, many customers now are buying Portworx and then adding DR right up front and then a few months later, they might come back and add backup from Portworx. So to Cheng's point, right? Because of the uniqueness of the Kubernetes workload, because it is an app-defined control plane, not machine-defined, what is happening is it's disrupting, just like virtualization did. Veeam exists today because they focused on a Veeam version of their backup solution. So the same thing is happening. Kubernetes workloads are causing disruption of the DR and backup and storage markets with solutions like Portworx. Wonderful, well, Merley and Cheng, thank you so much for the updates. Absolutely, the promise of containers, as you were saying, Merley, is that atomic unit getting closer to the application really requires storage to be a full and useful solution. So great to see the progress that's being made. Thank you so much for joining. You're welcome, Cheng. We look forward to working with you as you reach for the stars. Congratulations again. I look forward to that continuing partnership, Merley. And thank you Stu for the opportunity here. Absolutely, great talking to both of you and stay tuned, lots more coverage of theCUBE, KubeCon, CloudNativeCon 2020 Europe. I'm Stu Miniman and thank you for watching theCUBE.