>>from around the globe. It's the Cube with coverage of Coop con and cloud, native con Europe 2020 Virtual brought to you by Red Hat, The Cloud Native Computing Foundation and its ecosystem partners >>Welcome back. This is the Cube coverage of Cube Con Cloud, native con, the European show for 2020. I'm your host to Minuteman. And when we talk about the container world, we talk about what's happening in cloud. Native storage has been one of those sticking points. One of those things that you know 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 oh, founders and CEOs. First of all, we have Xiang Yang from Rancher Labs, of course, was recently acquired by Sue Save it and the intention to acquire on and also joining us from early the relay. Who is with port works? Shang Amerli. Thanks so much for joining us. Thank you. Thank you. Alright. So early. I actually I'm going to start with you just cause you know we've seen, you know, a couple of waves of companies working on storage. In this environment, we know storage is difficult. Um, And when we change how we're building things, there's architectural things that can happen. Eso maybe if you could just give us a snapshot, you know, Port works, you know, was created to help unpack this. You know, straight on here in 2020 you know, where you see things in the overall kind of computer storage landscape? >>Absolutely. Still, before I kind of jump into port works. I just want to take a minute to publicly congratulate the the whole rancher team, and and Shang and Shannon And will China have known those folks for a while there? They're kind of true entrepreneurs. They represent the serial entrepreneur spirit that that so many folks know in the valley, and so, you know, great outcome for them. We're very happy for them and ah, big congrats and shout out to the whole team. What works is 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 gonna have to solve, not just the orchestration problem. But the issue of storage and data orchestration and so in a natural kubernetes orchestrates containers and what works orchestrates storage and data. And more specifically, by doing that, what we enable is enterprises to be able to take APS that are containerized into production at scale and and have high availability. Disaster recovery, backup all of the things that for decades I t has had to do and has done to support application, reliability and availability. But essentially we're doing it for purpose with the purpose build solution for containerized workloads. >>Alright, shaming. Of course, storage is a piece of the overall puzzle that that ranchers trying to help with. Maybe if you could just refresh our audience on Longhorn, which your organization has its open source. It's now being managed by the CN. CF is my understanding. So help us bring Longhorn into the discussion >>thanks to. So I'm really glad to be here. We've I think rancher and port work started about the same time, and we started with a slightly different focus. More is exactly right to get containers going, you really need both so that the computer angle orchestrating containers as well as orchestrating the storage and the data. So rancher started with, ah, it's slightly stronger focus on orchestrating containers themselves, but pretty quickly, we realized, as adoption of containers grow, we really need it to be able to handle ah, storage feather. And like any new technology, you know, uh, Kubernetes and containers created some interesting new requirements and opportunities, and at the time, really, they weren't. Ah, a lot of good technologies available, you know, technologies like rook and SEF at the time was very, very premature, I think, Ah, the You know, we actually early on try to incorporate ah, the cluster technology. And it was just it was just not easy. And And at the time I think port Works was, ah, very busy developing. Ah, what turned out to be there flagship product, which we end up, end up, uh, partnering very, very closely. But but early on, we really had no choice but to start developing our own storage technology. So Long horn. As a piece of container storage technology, it's actually almost as oh, there's rancher itself. When about funding engineers, we hired he he ended up, you know, working on it and Then over the years, you know the focus shift that I think the original version was written in C plus plus, and over the years it's now being completely re written in Golan. It was originally written more for Docker workload. Now, of course, everything is kubernetes centric. And last year we you know, we we decided to donate the Longhorn Open Source project to CN CF. And now it's a CN CF sandbox project, and the adoption is just growing really quickly. And just earlier this year, we we finally ah decided to we're ready to offer a commercial support for it. So So that's that's where rancher is. And with longhorn and container storage technology. >>Yeah, it has been really interesting to watch in this ecosystem. A couple of years ago, one of the Q con shows I was talking to people coming out of the Believe It was the Sigs, the special interest group for storage, and it was just like, Wow, it was heated. 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 in various ways of doing things often are contentious and there's there's differences of opinion. Look at the storage industry. You know, there's a reason why there's so many different solutions out there. So maybe it love to hear from early. From your standpoint, 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 coop petition? I actually good for the industry? >>Yeah, I think this is a classic example of Coop petition. Right? Let's let's start with the cooperation part right? The first part of time the you know, the early days of CN, CF, and even sort of the Google Communities team, I think, was really very focused on compute and and subsequent years. In the last 34 years, there's been a greater attention to making the whole stack works, because that's what it's going to take to take a the enterprise class production and put it in, you know, enterprise class application and put it in production. So extensions like C and I for networking and CS I container storage interface. We're kind of put together by a working group and and ah ah you know both both in the CN CF, but also within the kubernetes Google community. That's you talked about six storage as an example. And, you know, as always happens, right? Like it It looks a little bit in the early days. Like like a polo game, right where folks are really? Ah, you know, seemingly, uh, you know, working with each other on 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 CS I interface is really a A really very, very strong and complete solution tow, allowing communities to orchestrate storage and data. So it's really strengthened both communities 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? Um, you know, one of the classic things that people sometimes confuse is the difference between an overlay and an interface. CSC is wonderful because it defines how the two layers off essentially kind of old style storage. You know, whether it's a san or ah cloud, elastic storage bucket or all of those interact with community. So the the definition of that interface kind of lay down some rules and parameters for how that interaction should happen. However, you still always need an overlay like Port Works that that actually drives that interface and enables Kubernetes to actually manage that storage. And that's where the competition is. And, you know, she mentioned stuff and bluster and rook and kind of derivatives of those. And I think those have been around really venerable and and really excellent products for 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 they've been trying to be adapted for, for for us, for this kind of workload. Port Works is really a built from right from the inception to be designed for communities and for kubernetes workloads at enterprise scale. And so I think, you know, as I 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 that's why everybody and their brother now has a CS I interface. However, I think there's a big difference between having an interface. This is actually having the software that provides the functionality for H. A, D R. And and for backup, as as the kind of life cycle matures and doing it not just at scale, but in a way that allows kind of really significant removal or reduction off the storage admin role and replaces it with self service that is fully automated within communities. Yeah, if I >>can, you know, add something that that I completely agree. I mean, over the Longhorns been around for a long time. Like I said, I'm really happy that over the years it hasn't really impacted our wonderful collaborative partnership with what works. I mean, Poll works has always been one of our premier partners. We have a lot of, ah, common customers in this fight. I know these guys rave about what works. I don't think they'll ever get out for works. Ah, home or not? Uh huh. Exactly. Like Morissette, you know, in the in the storage space, there's interface, which a lot of different implementations can plugging, and that's kind of how rancher works. So we always tell people Rancher works with three types of storage implementations. One is let we call legacy storage. You know, your netapp, your DMC, your pure storage and those are really solid. But they were not suddenly not designed to work with containers to start with, but it doesn't matter. They've all written CS I interfaces that would enable containers to take advantage of. The second type is some of the cloud a block storage or file storage services like EBS, GFS, Google Cloud storage and support for these storage back and the CS I 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 you know, we call container Native Storage. So that is where Port Works and the Longhorn and other solutions like open EBS storage OS. 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, when you from 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 so the whole system, 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 Coop petition. It's really more off raising the bar for for the capabilities so that we can accelerate the amount of workload that's been moved onto this wonderful kubernetes platform in the end of the benefit. Everyone, >>Well, I appreciate you both laying out some of the options, you know, showing just a quick follow up on that. I think back if you want. 15 years ago was often okay. I'm using my GMC 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 open EBS, very popular in the last CN CF survey might be another one there. So is do we think some of it is just kind of repeating itself that storage is not monolithic and in a micro service architecture. You know, different environments need different storage requirements. >>Yeah, I mean quick. I love to hear more is view as well, especially about you know, about how the ecosystem is developing. But from my perspective, just just the range of capabilities that's now 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 to object store file, that's it. Right. So now it's this is just table stakes. Then then what comes after that? There will be 345 additional layers of requirements come all the way from backup, restore the our search indexing analytics. So I really think all of this potentially off or in the 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 very, very early stages, and and there, you know what? What, what what containers did is they made fundamentally the workload portable, but the data itself still holds a lot of gravity. And then just so much work to do to leverage the fundamental work load portability. Marry that with some form of universal data management or data portability. I think that would really, uh, at least the industry to the next level. Marie? >>Yeah. Shanghai Bean couldn't. Couldn't have said it better. Right? Let me let me let me kind of give you Ah, sample. Right. We're at about 160 plus customers now, you know, adding several by the month. Um, just with just with rancher alone, right, we are. We have common customers in all common video expedient Roche March X, Western Asset Management. You know, charter communications. So we're in production with a number off rancher customers. What are these customers want? And why are they kind of looking at a a a Port works class of solution to use, You know, Xiang's example of the multiple types, right? Many times, people can get started with something in the early days, which has a CS I interface with maybe say, $10 or 8 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 a rancher type orchestrator, workloads that are containerized on and a network plug in and a storage plugging. But really, once they start to get beyond 20 notes 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 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 make typically, maybe Max of what a San might go to. But hundreds and thousands of notes, like many of our customers, are doing like T Mobile Comcast. They're running this thing at 600 thousands of notes or scale is one issue. Here is a critical critical difference that that something that's designed for Kubernetes does right. We are providing all off the storage functions that Shang just described at container granted, granularity versus machine granularity. One way to think about this is the old Data center was in machine based construct. Construct everything you know. VM Ware is the leader, sort of in that all of the way. You think of storage as villains. You think of compute and CPUs, everything. Sub sub nets, right? All off. 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 were 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, uh, you know, control off the infrastructure via communities over to a kubernetes segment. The same person who uses rancher uses port works at NVIDIA, for example to manage storage as they use it, to manage the compute and to manage containers. And and that's marvellous, because now what has happened is this thing is now fully automated at scale and and actually can run without the intervention off 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 the solution like port works. 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 that change talk 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 and not really the storage admin intervention. And that's kind of the solution that we provide. >>Alright, well, we're just about out of time. If I could just last piece is, you know, early and saying to talk about where we are with long for and what we should expect to see through the rest of this year and get some early for you to you know, what differentiates port works from Just, you know, the open source version. So And maybe if we start with just kind of long or in general and then really from from your standpoint, >>yeah, so it's so so the go along one is really to lower the bar for folks to run state for workloads on on kubernetes we want you know, the the Longhorn is 100% open source and it's owned by CN cf now. So we in terms of features and functionalities is obviously a small subset of what a true enterprise grade solution like Port Works or, um, CEO on that that could provide. So there's just, you know, the storage role. Ah, future settle. The roadmap is very rich. I don't think it's not really Ranchers go Oh, our Longhorns goal to, you know, to try to turn itself into a into a plug in replacement for these enterprise, great storage or data management solutions. But But they're you know, there's some critical critical feature gaps that we need address. And that's what the team is gonna be focusing on, perhaps for the rest of the year. >>Yeah, uh, still, I would I would kind of, you know, echo what Chang said, right? I think folks make it started with solutions, like longer or even a plug in connector plug in with one of their existing storage vendors, whether it's pure netapp or 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 by looking at it as a whole and really with, You know, it'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 container ization part. But But, as Xiang pointed out, you know what what rancher did, what I entered it for Kubernetes was build a simple, elegant, robust solution that kind of democratized communities. We're doing the same thing for communities storage right? What Port works 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 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 life cycle. So there's many many customers now are buying port works and then adding deal right up front, and then a few months later they might come back and I'd backup from ports. So two shanks point right because of the uniqueness of the kubernetes workload, because it is an app defined control plane, not machine to find what is happening is it's disrupting, Just like just like virtualization day. VM exist today because because they focused on a VM version off. You know, the their backup solution. So the same thing is happening. Kubernetes workloads are district causing disruption of the D r and backup and storage market with solutions like sports. >>Wonderful. Merlin Chang. Thank you so much for the updates. Absolutely. The promise of containers A Z you were saying? Really, is that 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 us. >>Welcome, Shannon. We look forward to ah, working with you as you reach for the stars. Congratulations again. We look >>forward to the containing partnership morally and thank you. Still for the opportunity here. >>Absolutely great talking to both of you And stay tuned. Lots more coverage of the Cube Cube Con cloud, native con 2020 Europe. I'm stew minimum. And thank you for watching the Cube. Yeah, yeah, yeah, yeah, yeah, yeah