Sheng Liang, Rancher Labs & Murli Thirumale, Portworx | KubeCon + CloudNativeCon Europe – Virtual

Just another WordPress site

Sheng Liang, Rancher Labs & Murli Thirumale, Portworx | KubeCon + CloudNativeCon Europe – Virtual

>> Announcer: From around the globe, it’s theCUBE with coverage of KubeCon and CloudNativeCon Europe 2020 – virtual, brought to you by Red Hat, the Cloud Native computing foundation and ecosystem partners >> Welcome back, this is theCUBE 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 Cloud Native, storage has been one of those sticking points, one of those things that has been challenging that we’ve been looking to mature and we’re really happy to welcome back to the program, to 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 Sheng Liang, from Rancher Labs who of course was recently acquired by Susay, the intention to acquire, and also joining us Murli Thirumale who is with Portworx, Sheng and Murli thanks so much for joining us >> Thank you >> Thank you Stu >> All right, so, Murli, I have to say, I’m going to start with you just cause 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 that 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 Sheng and Shannon and Will Chan I’ve known those folks for awhile they’re kind of true entrepreneurs They represent the serial entrepreneurial 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 for purpose, with a purpose built solution for containerized workloads >> All right, Sheng, of course, storage is a piece of the overall puzzle that Rancher’s 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, I think Rancher and Portworx started about the same time, and we started with a slightly different focus, and Murli 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, our 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 Roque and Seth 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 their flagship product,

which we ended up partnering very, very closely But earlier 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 working on it And then over the years the focus shifted, I think the original version was like written in C plus plus, and over the years it’s now being completely rewritten in golang, it was originally written more for a darker 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 action is just growing really quickly And just earlier this year, we finally decided to were ready to offer commercial support for it So that’s where Rancher is and with Longhorn and the container storage technology >> Yeah, it can… really interesting to watch in this ecosystem a couple of years ago at one of the Yukon shows, I was talking to people coming out of the… I believe it was the SIG the special interest group for storage And it was just like, wow, it was heated, words were back and forth, there’s not a lot of agreement there, anybody that knows the storage industry knows that standards and various ways of doing things often are contentious and there’s differences of opinion Heck, look at the storage industry, there’s a reason why there’s so many different solutions out there, so maybe I’d love to hear Murli here, from your standpoint, it sounds like things are coming together a little bit more, there are still a number of options out there, so, why is this kind of coopertition, actually good for the industry? >> Yeah, I think this is a classic example of coopertition, right? Let’s start with the cooperation part, right? The first part of that, 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 enterprise class application and put it in production So extensions like CNI for networking and CSI Container Storage Interface, we’re kind of put together by a working group and both in the CNCF, but also within the Kubernetes Google Community There’s… you talked about say storage as an example And as always happens, right? Like, it looks a little bit in the early days, like a polo game, right? Where folks are really, seemingly 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 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? 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, 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 Sheng mentioned Seth and Bluster and Roque, and kind of derivatives of those, and I think those have been around are really vulnerable and really excellent products born in a different era for a different time, OpenStack, 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 built right from the inception to be designed for Kubernetes and for Kubernetes workloads at enterprise scale And so I think, 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 life cycle matures and doing it, not just at scale, but in a way that allows kind of really 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 add something to that, I completely agree I mean, over the years and 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, exactly like Murli said, in a storage space there’s interface, which a lot of different implementations can plugin, 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, and 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, the 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… you know, we call Container Native Storage, so that is where Portworx and 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, went 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 coopertition, 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 of they’ll benefit everyone >> Well, I appreciate you both laying out some of the options Sheng just a quick followup 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, I might want Portworx for my high performance You said Open EBS 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 the storage is not monolithic and in a microservice architecture, different environments need different storage requirements >> Yeah, I mean, quick, I love to hear Murli’s view as well, especially about how the ecosystem is developing, but from my perspective, just the range of capabilities that’s now we expect other storage vendors or data management vendors, is just increased tremendously In the old days, if you can store a block, store objects, store a file, that’s it, right? So now this is just table stakes, then what comes

after that, there 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 four 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 then 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, Murli >> Yeah, Sheng I mean, couldn’t have said it better right? Let me kind of give you a sample, right? We’re at above 160 plus customers now, adding several by the month, just with Rancher alone, right? We have common customers in all common VIDEA, Expedient, Roche, Marchex, Western Asset Management, Charter Communications, 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 Portworx class of solution? To use, Shane’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, a Rancher type orchestrator, workloads that are containerized, and network plugin and 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? So 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 are sort of typically maybe max of what a SAN might go to, but hundreds and thousands of nodes, like many of our customers are doing, right? Like, T-Mobile, Comcast, they’re running this thing at 600 thousands 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 Sheng 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, VMware is the leader sort of in that all of the way you think of storage as via launch, you think of compute, NCPUs everything subnets, right? All of traditional, the 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 control of the infrastructure via Kubernetes over to a Kubernetes segment, 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 Sheng 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 node 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, Murli and Sheng, talk about where we are with Longhorn, what we should expect to see, through the rest of this year And I guess, Murli for you too, what differentiates Portworx from just the the open source version So, Sheng maybe if we start with just kind of Longhorn in general and then Murli 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 the Longhorn is a hundred percent open source and it’s owned by CNCF now So we… in terms of features and functionality is obviously a small subset of what a true enterprise grade solution, like what Portworx or EMC or NetApp could provide, so there’s just the storage feature set or the roadmap is very rich I don’t think it’s not really a Rancher’s goal, or Longhorn’s goal to try to turn itself into a plugging 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 Sheng said, right? I think folks may get started with solutions like Longhorn or even a plugin like a connector plugin with one of their existing storage vendors, whether it’s Pure or 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 we 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 containerization part, but as Sheng pointed out, 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 life cycle management for data across that whole life cycle 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 Sheng’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, Veem exists today because they focused on a VM 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 Murli and Sheng, thank you so much for the updates, absolutely the promise of containers, as you were saying Murli 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 >> Your welcome, Sheng, we look forward to working with you as you reach for the stars, congratulations again >> I look forward to the continuing partnership, Murli 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 (upbeat music)