 From New York, it's theCUBE. Covering Escape 19. Okay, welcome back to theCUBE coverage here in New York City for the first inaugural multi-cloud conference called Escape. We're in New York City, we're staying in New York. We're not escaping from New York, we're in New York. It's all about multi-cloud. And we're here Lisa Marie-Nampi, developer advocate for Portworx and Eric Han, vice president of products. Portworx, welcome back to theCUBE. Thank you, John. It's good to be here. Great to see you guys. So whenever the first inaugural of anything, we want to get into it and find out why. Multi-clouds certainly have been kicked around. People have multiple clouds, but is there really multi-clouding going on? So this seems to be the theme here about setting the foundation, architecture, and data, the two kind of consistent themes. What's your take on this multi-cloud trend? Yeah, I think it's something we've all been actively watching for a couple of years and suddenly it is becoming the thing, right? So we just had a customer event back in Europe last week and every customer there is already running multi-cloud. It's always something on their consideration. So there's definitely, it's not just a discussion topic, it's now becoming a practical reality. So this event has been perfect because it's both the sense of what are people doing, what are they trying to achieve, and also the business sense. So it's definitely something that is not necessarily mainstream, but it's becoming much more how they're thinking about building all their applications going forward. You know, you have almost two camps in the world want to get your thoughts on this guys because like you have cloud native and people that are cloud native, they love it, they're born in the cloud, they get it, everything's cranking along, the developers are on microservices, they're agile trained, but they're on microservices. And you got the hybrid IT, trying to be hybrid developer, right? So you kind of have two markets coming together. So to me, I see multi-cloud as kind of the combination of old legacy data center types of IT with cloud native, not just ops and dev, we're talking about like trying to build developer teams inside enterprises. This seems to be a big trend and multi-cloud fits into that because now the reality is that I got Azure, I got Amazon, well, let's take a step back and think about the architecture. What's the foundation? So that to me is, well, my opinion, but I want to get your thoughts and reaction on that because if it's true, that means some new thinking has to come around around what's the architecture? What are we trying to do? What's the workloads behavior outcome look like? What's the workflows? So there's a whole nother set of conversations that happen. I agree. I think the thing that the fight out there right now that we want to make mainstream is that it's a platform choice and that's the best way to go forward. So it's still an active debate, but the idea could be I want to do multi-cloud, but I'm going to lock myself into the cloud services. If that's the intent or that's the design architecture pattern, you're really not going to achieve the goals we all set out to do, right? So in some ways we have to design ourselves to have the architecture that will let us achieve the business goals that we're really going for. And that really means from our perspective or from a Portworx perspective, there's a platform team. That platform team should run all the applications and do so in a multi-cloud first design pattern. And so from that perspective, that's what we're doing from a data plan perspective and that's what we do with Kubernetes, et cetera. So from that idea of going forward, what we're seeing is that customers do want to build out a platform team, have that as the architecture pattern and that's what we think is going to be the winning strategy, right? Well, I think you also, when you have the definition of multi-cloud, you have to incorporate just like with hybrid IT the legacy applications. And we saw that throughout the years, those crucial applications, as we call them, people don't always want them to refer to as a legacy, but those are crucial applications and our customers are definitely thinking about how are we going to run those and where's the right place? Is it on-prem? We're seeing that a lot too. So I think when we talk about multi-cloud, we also talk about what is in your legacy, what is in your case? Yeah, I use legacy, I think it's a great word because I think it really puts the nail in the coffin of that old way because remember, if you think about some of the large enterprises, these legacy applications, they've been optimized for hardware, they've been optimized, they're full stack, they've been built up from the ground up. So they're cool and they're running stuff, but it doesn't always translate to say a new platform design point. So how do you, I mean containers is a great fit for their Kubernetes obviously, you know, it's the answer, you guys see that as well. But okay, I can keep that and still get this design point. So I guess what I want to ask you guys is as you guys are digging into some of the customer facing conversations, what are they talking about? Are they talking about the platform specifically? Certainly on the security side, we're seeing everyone running away from buying tools to thinking about platforms. What's the conversation like on the cloud side? Well, before you answer that question, I just want to say we did a talk, our multi-cloud for Reels talk at Barcelona KubeCon. Pretty sure Eric's three-year-old son Andrew named it for Reels of the Z. But we really wanted to talk about multi-cloud in the real world. And when we said show of hands in Barcelona, who's running multi-cloud, it was very, very few. And this was in, what, five months, four months ago. Whereas maybe our customers are just really super advanced because of our 100 plus customers at Portwares, we, Eric is right. A lot of them are already running multi-cloud or if they're not, they're in that planning stage right now. So even in the last five, six months, this has become a reality. And we're big fans of Kubernetes. I don't know if you know, Eric was the first product manager for Kubernetes. I just want to get that. You just. Okay, go ahead. GKE, he's too shy to say it, so I'll say it. And so, yeah, and we think, you know, and Kubernetes does seem to be the answer to making multi-cloud a reality right now. Well, I want to get back into GKE and Kubernetes because it's a very notable historic moment. So congratulations. But to your point about multi-cloud, it's interesting because, you know, having multiple clouds means things, right? So for instance, if I upgrade to Office 365 and I kill my exchange server, I'm essentially running Azure by their definition. If I'm building a stack on AWS, I'm an AWS customer. Let's just say I want to do some TensorFlow or play with Bigtable or Spanner on Google. Now we have three clouds. No, they're not necessarily, they have workload-specific objectives. I am totally no problem. I see that for the progressive customers. Some legacy B2B people like, maybe they put their toe in the cloud, anyone doing meaningful cloud probably has multiple clouds. But that's workload-driven. When you get into tying them together is interesting. And I think that's where I think you guys have a great opportunity in this community because if open source can be the gateway to minimize the lock-in. And when I say lock-in, I don't mean like lock-in on proprietary spec. If there's value there, great, use it. But if I want to move my data out of, say, Amazon. Well, you brought up so many good points. So let me go through a few and then Lisa jump in. I feel like lock-in, people don't want to be locked in at the infrastructure level. So like you said, if there's value at the higher levels of the stack and it helps me do my business faster, that's an okay thing to exchange. But if it's just locked in and it's not doing anything there, that's not an equal exchange, right? So there's definitely a move from infrastructure up to platform. So locking in an infrastructure is what people are trying to move away from from what we see. From the perspective of legacy, there is a lot of things happening in the industry that is pretty exciting of how legacy will also start to run in containers. And I'm sure you've seen that, but containers being the basis, it could run a VM as well. And so that will mean a lot for in terms of how VMs can start to be managed by orchestrators like Kubernetes. So that is another movement for legacy and I wanted to acknowledge that point. Now in terms of the patterns, there are definitely applications like a hybrid pattern where a connected car has to upload all its data once it docks into its location and move it to the data center. So there are patterns where the workflow does move the application data between on-prem into a public cloud, for instance. And then coming back from that year trip with Lisa, there is also examples where regulations require companies and enterprises to be able to move to another cloud in a reasonable timeframe. So there's definitely a notion that multi-cloud is both an architectural design pattern, but it's also a sourcing strategy. And that sourcing strategy is more a regulation type or in terms of not being locked in. And that's where I'm saying it's all those things, right? Yeah, Eric, I'd love to get your thoughts on this because I like where you're going with this because it kind of takes it to a level of, okay, standardization, Kubernetes nights, containers, everyone knows what that is. But then you start thinking about API gateways, for instance, right? So if I'm a car and I have five different gateways on my device, IoT devices, or I have multiple vendors dealing with control plane data, that can be problematic. I got to do something. So I'm starting to envision them. I just made that use case up. But my point is, is that you need some standards. So on the API side, we're seeing some trends there. Everyone's saying, okay, here's my stuff. I'll just pass parameters with API, you know, state and stateless are two dynamics. What do you make of that? What has to happen next to get to that next level of happiness and goodness? Because Kubernetes has got it there. Right. What's at the next level? I feel like, and Lisa, please jump in. I feel like from an automation perspective, Kubernetes has done that. From an API gateway and what has to happen next, there's still a lot of easy use that isn't solved, right? There's probably tons of opportunities out there to build a much better user experience, both from an operations point of view and from what I'm trying to do as an intent. Because what people aren't going to automate right now is the intent. They'll automate a lot of the infrastructure manual tasks and that's goodness. But from how I dock my application, how the application data gets moved, we're still at the point of making policy driven, easy to use. And I think there's a lot of opportunities for everyone to get better there. That's like low-hanging, it's priority. Low-hanging fruit, take care of the manual stuff. And Kubernetes was really good at the low-hanging fruit. That's a real use case that you brought up. Really, people are looking at the data now. And when you're talking about persistent, I mean, Kubernetes was great for a stateless, but for a stateful, that's really crucial data. So that's where we really come in and a number of other companies in the cloud-native storage ecosystem come in and have really fought through this problem and that data management problem. That's where this platform that Eric was talking about. Well, I'll get to that state problem. We'll talk about your company. I want to get back to the Google days. Many war stories around Kubernetes. We'll have the same fate as MapReduce. You know, the debate's internally at Google. What do we do with it? You guys made the good call. Congratulations on doing that. So what was it like to be early on because you already had large scale. You already had Borg. You already had all these things in place. What was it like there? What was it? Well, a few things I'll say. One is it was intense, right? It was intense in the sense that amazing amount of intelligence, amazing amount of intent. And right back then, a lot of things were still undecided, right? We were still looking at how containers are packaged. We're still looking at how infrastructure can get run. And a lot of the services were still being rolled out. So what it really meant is how to build something that people want, how to build something that people want to run with you and how to build the ecosystem community. And a lot of that the community got was done very well, right? You have to give credit to things like the SIG, a lot of things like how people like advocates like Lisa have gone out and made it part of what they're doing. And that's important, right? Every ecosystem needs to have those advocates. And that's what's gone well. As a flip side, I think there's a lot of things where we always look back in which we could have done a few things differently, but that's a different story for a different time. Yeah, we'll come back and get in the studio and follow up with that. I got to ask you, now that you're outside Google, was it culture shock? Oh my God, people are actually provisioning software. They provision a data center. What was it like? You had culture shock when you left Google? There's a little bit of culture shock. One thing is, the funny thing is coming full circle in Kubernetes now is that the idea of an application, right? The idea of what is an application is something that feels very comfortable to a lot of legacy traditional, I want to use the word traditional applications. But the moment you've spent so much time in Kubernetes and you say, what's the application? It became a very hard thing. And I used to have a lot of academic debates where I was saying there is no application. It's a soup of resources and such. So that was a hard thing, but funny thing is Kubernetes is now coming out with definitions around application and Microsoft announced a few things in that area too. So there are things that are coming full circle, but that just shows how the movement has changed and how things are becoming, in some ways, meeting each other halfway. Talk about the company, what you guys are doing. Take a moment to explain in context to multi-cloud, we're here, Portworx, what's the platform? What's the product? What's the value proposition? What's the state of the company? Yeah, so the company's, well, it's grown from early days when Lisa and I joined where we were probably a handful. Now we're in four or five cities, geographies, over 100 people, over 150 customers, and there it's been a lot of enterprises that are saying how do I take this pattern of doing containers and microservices and how do I run it with my mission-critical, business-critical workloads? And at that point, there's no mission-critical, business-critical workload that isn't stateful. So suddenly they're trying to say, how do I run these applications? And containers and data have different life cycles. So what they're really looking for is a data plane that works with the control planes and how control planes are changing the behavior. So a lot of our technology and a lot of our product innovation has been around both the data plane but a storage control plane that integrates with a compute control plane. So I know we like to talk about one control plane, but there's actually multiple control planes, and you mentioned security, right? If I look at how applications are running, we have to now securely access for applications and it's no longer I have access to the data before I get to use it, you have to now start to do things like JWT or much higher level bearer tokens to say, I know how to access this application for this life cycle, for this use case and get that kind of resiliency. So it's really around having that storage control. Well, it's more complexity. Absolutely. And you need abstraction layers and you got compute, luckily they don't work there, but you got to have software to do it. No, from a Portworx perspective, our product's entirely software, right? It downloads and runs using Kubernetes. And so the point here is we make Kubernetes able to run all the stateful workloads out of the box using the same common control plane, which is Kubernetes. So that's the experiences that we really want to make it so that the DevOps Kubernetes teams can run any workload. And that's in some ways been part of the mix. Lisa, we've been covering DevOps going back to 2010. I remember when I first was hanging around San Francisco, 2008, Joanie was coming out of the woodwork in all that early days. And if you look at the journey of how infrastructure is code, we're talking about that in 2008. And now we look at 11 years later, look at the advancements, you've been through this. Now the tipping point, it just seems like this wave is big and people are on it. The developers are getting it. It's a modern renaissance of application developers. And the enterprises, it's happening in the enterprise. It's not just like the denerging, the tier one, the alpha geeks or the cloud native, it's happening in the enterprise. Right, everyone's on board this time. And yeah, you and I have been in the trenches in the early stages of many open source projects. And I think with Kubernetes, Arab reference community earlier, I'm super proud to be running the world's largest CNCF user group. And it's a great community, diverse community, super smart people. One of my favorite things about working at Portworx is we have some really smart engineers that have figured out what companies want, how to solve problems. And then we'll go create a little open source project. Like we created a project called Autopilot, really largely because one of our customers, Esri, who's in the GIS space and who's running just incredible application. You can Google it and see what the work they're doing. It's all out there publicly. And we built an open source project for them to help them get the most out of Kubernetes, we can say. There's a lot of people in the Kubernetes system doing that. How can we make Kubernetes better? How can we make Kubernetes enterprise grade and not take years to do that? Like some of the other open source projects that we worked on and took. So it's a super exciting time to be here. And open source is growing so fast now. I mean, just think about how these projects being structured more and more, projects are coming online and user products. But a lot more vendor driven projects do. It used to be mostly end user, but now you have a lot of vendors who are users. So the line is blurring between vendor user in open source. It's really fascinating. Well, you look at the landscape on the CNTF, you know, the website. I mean, it's what, 400 vendors that are already on board. It's really important. They don't have enough speaking slashers for the demand that they have. Right, I know. And it's just, it is users and vendors. Everybody's in this community together. It's one of the things that makes it super exciting and it's how we know this was the right choice for us to base this on Kubernetes. Because that's what everybody is using. Well, you guys are practically neighbors. So we're looking forward to seeing the studio in Palo Alto. Eric, I want to ask you one final question on the product side. Roadmap, what are you guys thinking as Kubernetes goes to the next level? Obviously state, a lot of microservices, observability is becoming a key part of it. Obviously automation, configuration, management, things are developing fast. State, what's the roadmap for you guys? For us, it's been always about how to handle the mission critical and make that application run seamlessly, right? And then now we've done a lot of portability, so disaster recovery's been one of the biggest things for us is that customers are saying, how do I do a hybrid pattern back to your earlier question of running on-prem and in public cloud and do a DR failover into a public cloud? Some of the things that Lisa is pointing out that we're announcing soon is, or well announced here, is autopilot and the idea of automatically managing how applications scale from a volume capacity. And then we're actually going to start moving a lot more into some of what you do with data after the lifecycle in terms of backup and retention. So those are the things that everyone's been pushing us and that customers are all asking for. You know, I think data backup and recovery is interesting. I think that's going to change radically and I think if you look at the trend of how data backup and recovery was built, it was built because of disruption in the business. Floods are our gains, data center failure, but I think the biggest disruptions are ransomware, malware. So security's now a active disruptor. So it's not like an afterthought, hey, if we ever have a fire, we can always roll back so you're infected and you're just rolling back infected code, that's a ransomware dream, that's what's going on. So I think data protection, it needs to be redefined. What do you think? Absolutely, I think there's a notion of how do I get last week's data last month and then oftentimes customers will say if I have a piece of data of volume and I suddenly have to delete it, I still need to have some record of that action for a long time, right? So those are the kinds of things that are happening and is Kubernetes and everything, it gets changed. Suddenly the important part is not what was just that one pod, it becomes how do I reconstruct everything? Data protection is not one thing, it's everywhere. That's right. You have to protect data all through the platform. If it's a platform decision, it's not some element on the side. It can't be a single app, it has to be an entire solution and it has to handle things like where did it come from? Where is it allowed to go? And you guys have that philosophy? We absolutely, and it's based on the enterprises that are adopting Portworx and saying, hey, this is my roadmap, I'm basing it on Kubernetes, you're my data partner, how do we make it happen? This speaks to your point of why the enterprises and the vendors jumped in. This is what people care about, security. How do you solve those last mile problem storage networking? How do you plug those holes in Kubernetes because that is crucial to our customers? One personal, private moment, victory moment for me personally been a big fan of Kubernetes, obviously, you know, for years been there when we were kind of created and talked about, but one of the moments that got me, that was really kind of a personal heartfelt moment was talking to an enterprise buyer and the whole mindset of the enterprise has always been, you got to kill the old to bring in the new. And so there's always been that tension of, hey, the shiny new toy from Silicon Valley or whatever, I'm not going to just trash this and have a migration. It's a pain in the butt for IT, they don't want that to do that, they hate doing migrations. But with containers and Kubernetes, they can actually, they don't have to end of life to bring in the new project, they can do it on their own timetable or keep it around. So that took a lot of air out of the tension and on the IT side because they said, hey, great, I can deal with the lifecycle management of my app on my own terms and go play with cloud native. And so to me, I was like, that was to me like, okay, there it is. That was validation. That means this is real because now they can innovate without compromising. I think so. And I think some of that has been how the ecosystems embrace it, right? So now it's becoming all the vendors are saying, my internal stack is also based on Kubernetes. So even if you as an application owner are not realizing it, you're going to take a VM next year and you're going to run it and it's going to be backed by something like Kubernetes. Awesome. Lisa Marie Nymphy, Eric Hahn, thank you for coming on. Portworx, hot start of multiple cities, Kubernetes, big developer projects, open source, talking about multi-cloud here at the inaugural multi-cloud conference in New York City. It's theCUBE coverage of Escape 2019. I'm John Furrier. Thanks for watching.