(upbeat music) >> Hello, welcome to this Cube Conversation here in Palo Alto, California. I'm John Furrier, host of theCube. We have a returning Cube alumni, Ramesh Prabagan, who is the co-founder and CEO of Prosimo.io. Great to see you, Ramesh. Thanks for coming in to our studio, and welcome to the new layout. >> Thanks for having me here, John. After a series of Zoom conversations, it's great to be live and in the flesh! >> Great to be in person. We also got a new stage for our Supercloud event, which we've been opening up to the community, looking forward to getting your perspective on that soon as well. But I want to keep the conversation really about you guys. I want to get the story down. You guys came out of stealth, Multicloud, Supercloud is right in your wheelhouse. >> Exactly. >> You got to love Supercloud. >> Yeah. As I walked in, I saw Supercloud all over the place, and it just gives you a jolt of energy. >> Well, you guys are in the middle of the action. Your company, I want you to explain this in a minute, is in the middle of this next wave. Because we had the structural change I called Cloud One. Amazon, use case, developers, no need to build a data center, all that goodness happens, higher level service of abstractions are happening, and then Azure comes in. More PaaS, and then more install base, now they're nipping at the heels. So full on hyperscale, Cap Backs growth, great for everybody. Now comes new use cases. Cloud to cloud, app to app, you see Databricks, Snowflake, MongoDB, all doing extremely well by leveraging the Cap Backs, now it's an ops problem. >> Exactly. >> Now ops and security. >> Yeah. It's speed of applications. >> How are you guys vectoring into that? Explain what you guys do. >> Absolutely. So let me take kind of the customer pain point first, right? Because it's always easier to explain that, and then we explain what is it that we do. So, it's no surprise. Applications are moving into the cloud, or people are building apps in the cloud in masses. The infrastructure that's sitting in front of these applications, cutting across networking, security, the operational piece associated with that, does not move at the same speed. The apps sometimes get upgraded two, three times a day, the infrastructure gets touched one time a week at best. And so increasingly, the cloud platform teams, the developers are all like, "Hey, why? Why? Why?" Right? "I thought things were supposed to move fast in the cloud." It doesn't. Now, if you double click on that, really, it's two reasons. One, those that won't have consistency across the stack that they hired in the data center, they bring a virtual form factor of that stack and line it up in the cloud, and before you know it, it's cost, it's operation complexity, there are multiple single panes of glass, all the fun stuff associated... >> Just to interject real quick. It is fast in the cloud if you're a developer. >> Exactly. >> So it's kind of like, hurry up, slow down, wait. >> Correct. >> So the developers are shifting left, open source is booming. Things are fine for developers right now. If you're a developer, things are good. >> But the guy sitting in front of that... >> The ops guys, they've got to deal with things like lock-in, choice, security. >> Exactly. And those are really the key challenges. We've seen some that actually said, "Hey, know what, I don't want to bring my data center stack into the cloud. Let me go cloud-native. And they start to build it up. 14 services from AWS, 15 from iGR, 14 more from GCP, even if you are in a single cloud. They just keep it to that. I need to know how to put this together. Because all these services are great, but how do I put this together. And enterprises don't have just one application, they have hundreds of these applications. So the requirements of a database is different than a service mesh, different than a serverless application, different than a web application. And before you know it, "How do I put all these things together?" And so we looked at this problem, and we said, "Okay. We subscribe to the fact that cloud-native is the way to go, right, but something needs to be there to make this simple." Right? And so, first thing that we did was bring all these cloud-native services together, we help orchestrate that, and we said, "okay, know what, Mr. Enterprise? We got you covered." Right? But now, it doesn't stop there. That's like, 10% of the value, right? What do you really need? What do you care about now? Because the apps are in the center of the universe, and who's talking to it? It's another application sitting either in the same cloud, or in a different cloud, or it's a user connecting into the application. So now, let's talk about what are the networking security operational requirements required for these apps to talk to each other, or the user to talk to the application. That's really what we focus on. >> Yeah. And I think one of the things that's driving this opportunity for you, and I want to get your reaction to this, is that the modern application movement is all about cloud-native. Okay, they're obviously doing great. Now, kind of the kumbaya moment in enterprise is that the security team and ops teams have to play ball and be friends with the developer, and vice versa. So harmony's coming there. So the little harmony. And two, the business is driving apps. IT is transforming over. This is why the Supercloud idea is interesting to Dave and I. Because when we coined that term, multi-cloud was not a market. Everyone has multiple clouds, 'cause they have Microsoft Office, that's now in the cloud, they got SQL Server, I mean it's really kind of Microsoft Cloud. >> Exactly. >> So you have a cloud. But do you have ops teams building on the stack? What about the network layer? This is where the rubber meets the road. >> Absolutely, yeah. And if you look at the challenges there, if you just focus on networking and security, right? When applications need to talk to each other, you have a whole bunch of underlying services, but somebody needs to put this thing on top. Because what you care about is "can these group of users talk to these class of applications." Or, "these group of applications, can they talk to each other," right? This whole notion of connectivity is just table stakes. Everybody just assumes it's there, right? It's the next layer up, which is, "how do I bring Zero Trust access? How do I get the observability?" And observability is not just a bunch of pretty donut chats. I have had people look to me in my previous company, the start-up, and said, "okay, give me all these nice donut chats, but so what? What do you want me to do with this?" And so you have to translate that into real actions, right? "How do I bring Zero Trust capabilities? How do I bring the observability capabilities? How do I understand cloud-native and networking and bring those things together so that you can help solve for the problem." >> It's interesting, one of the questions I had here to ask you was "what does it mean to be cloud-native, and why now?" And you brought up Zero Trust, trust and verify, these are security concepts. But if you look at what's going on at KubeKon and CNCF and Linux Foundation, software supply chain's a huge issue, where trust is the issue. They want trust there, so you got Zero Trust here. What is it? Zero Trust or trust? I mean, what's there? Is one hardware based, perimeter, networking? That kind of perimeter's dead, ton of... >> No, the whole- >> Trust or Zero Trust. >> The whole concept of Zero Trust is don't trust what is underlying, just trust what you're talking to. So if you and I talking to each other, John, you need to trust me, I need to trust you, and be able to have this conversation. >> You've been verified. >> Exactly, right? But in the application world, if you talk about two apps that are talking to each other, let's say there is a web application in one AWS region talking to a database in a different region, right? Now, do you want to make sure you are able to build that trust all the way from the application to the application? Or do you want to move the trust boundary to the two entities that are talking to each other so that irrespective of what they go on underneath the covers, you can be always sure that these two things are trusted. >> So, Ramesh, I was on LinkedIn yesterday, I wrote a comment, Dave Vallante wrote a post on Supercloud, we're talking about it, and I wrote, "Cloud as a commodity," question, and then a bunch of other stuff that we're going to talk about, and Keith Townsend jumped on that, and got on Twitter, put a poll, "Is cloud a commodity? Source: me." So, it started a big thread. And the reaction was interesting. And my point was to be provocative on "Cloud isn't commodity, but there's commodity elements." EC2 and S3, you can look at that and say, "that's commodity IaaS," but Amazon Web Services has done an amazing job for higher level services. Okay, so how does that translate into the use cases that you see that you guys are going after and solving, because it's the same kind of concept. IaaS and SaaS have to work together to solve problems, but that's in an integrated environment, say, in a native-cloud. How does that work across clouds? >> Yeah, no, you bring up a great point, John. So, let's take the simple use case, right? Let's keep the user to app thing to the side. Let us say two apps need to talk to each other, right? There are multiple ways in which you can solve this problem. You can build highways. That's what our customers call it. I'll build highways. I don't care what goes on those highways, I'll just build highways. You bring any kind of application workload on it, I just make sure that the highways are good, right? That's kind of the lowest common denominator. It's the path to least resistance. You can get stuff done, but it's not going to move the needle, right? Then you have really modern, kind of service networking, where, okay, I'm looking at every single HTTP, API, n:point, whatnot, and I'm optimizing for that. Right? Great if you know what you're doing, but, like, if you have thousands of these applications, it's not going to be really feasible to do that. And so, what we have seen customers do, actually, is employ a mixed approach, where they say, "I'm going to build these highways, the highways are going to make sure that I can go from one place to another, and maybe within regions, across clouds, whatnot, but then, I have specific requirements that my business needs, that actually needs tweaking, right? And so I'm going to tweak those things. That's why, what we call as like, full stack transit, is exactly that, right, which is, I'll build you the guts of it so that hey, you know what, if somebody screams at you, "Hey, why is my application not accessible?" You don't have that problem. It is always accessible. But then, the requirements for performance, the requirements for Zero Trust, the requirements for segmentation, and all of that are things that... >> That's a hard problem. >> That's a hard problem to solve. >> And you guys are solving that? >> Absolutely, exactly. >> So, let me throw this at you. So, okay, I get that. And by the way, that's exactly what we're seeing. Dave and I were also debating about multi-cloud as what it is. Now, the nirvana definition is, "Well, I have a workload, that's going to work the same, and just magically just shift to Azure." (Ramesh laughs) >> Like, 'cause there's better resources. >> There is no magic there. >> So, but this brings up the point of operations. Now, Databricks and Snowflake, they're building their software to run on multi-cloud seamlessly. Now they can do that, 'cause it's their application. What is the multi-cloud use case, so that's a Supercloud use case in your mind, because right now it's not yet there. What is the Supercloud use case that's going to allow this seamless management or workloads. What's your view? >> Yeah, so if you take enterprise, right? Large enterprise in particular. They invariably have some workloads that are on, let's say, if the primary cloud is AWS, there are some workloads in Azure. Maybe they have acquired a new company, maybe a start-up that uses GCP, whatnot. So they have sprinkles of workloads in other clouds. >> So that's the breed kind of thing. >> Yeah, exactly. That's not what causes anybody to wake up in the morning and say, "I need to have a Supercloud strategy." That's not the thing, right? But now, increasingly you're seeing "pick the right cloud for the appropriate workload." That is going to change quite a bit. Because I have my infrastructure heavy workloads in AWS. I have quite a bit of like, analytics and mining type of applications that are better on GCP. I have all of my package applications work well on Azure, right? How do I make sure all of this. And it's not apps of this kind. Even simple things like VDI. VDI always used to be, "I have this instance I run up" and whatnot. Now every single cloud provider is giving you their own flavor of virtual desktop. And so, how do you make sure all of these things work together, right? And once again, what we have seen customers do is they settle on one cloud as their primary, but then you always have sprinkles of workloads across all of the clouds. Now, you could also go down the path, and you're increasingly seeing this, you could go down the path of, "Hey, I'm using cloud as backbone," right? Cloud providers have invested massive amounts of dollars to make sure that the infrastructure reaches there. Literally almost to the extent that every user in a metro city is ten milliseconds from the public cloud. And so they have allowed for that. Now, you can actually use cloud backbones to get the availability, the liability and whatnot. So these are some new use cases that we have seen actually blew up in customers. I was just doing an interview, and the topic was the innovator's dilemma. And one of the panelists said, "It's not the innovator's dilemma, it's the integrator dilemma." Because if you have commodity, and you have choices on, say, backbones and whatnot for transit, the integration is the key glue now. What's your reaction to that? >> Absolutely. And we have seen, we used to spend quite a bit of time in kind of what is the day zero problem, right? Like, how do I put this together? Conversations are moved past that, because there are multiple ways in which you can do that right now, right? Conversations are moving to kind of, "this is more of an operational problem for me." It's not just operations in the form of "Hey, I need to find out where the problem is, troubleshoot it, and so forth. But I need to make like really high quality decisions." And those decisions are going to be guided by data. We have enterprise customers that acquire new companies. Or they have a new site that they open up. >> It's a mishmash. >> Yeah, exactly. It's a New York based company and they acquire a team out in Sidney, Australia, right? Does your cloud tell you today that you have new users, or new applications that are in Sidney, and naturally just extend? No, it doesn't. Somebody has to look at the macro problem, look at "Where are all my workloads?" Do a bunch of engineering to make that work, right? We took it upon ourselves to say "Hey, you know what, twenty-four hours later, you're going to get a recommendation in the platform that says, 'okay, you have new set of applications, a new set of users coming from Sidney, Australia, what have you done about it?' Click a button, and then you expand on it. >> It's kind of like how IT became the easy way to run the data center. Before IT you had to be a PhD, and roll out, I mean, you know how it was, right? So you're kind of taking that same approach. Okay, well, Ramesh, great stuff. I want to do a followup, certainly with you on this. 'Cause you're in the middle of where this wave is going, this structural change, and certainly can participate in that Supercloud conversation. But for your company, what's going on there? Give us an update, customer activity, what's it like, you guys came out of stealth, what's been the reaction, give a plug for the company, who you going to hire, take a minute to plug it. >> Oh, wonderful, thank you. So, primary use cases are really around cloud networking. How do you go within the cloud, and across clouds, and to the cloud, right? So those are really the key use cases. We go after large enterprises predominantly, but any kind of mid enterprise that is extremely cloud oriented, has lot of workloads in the cloud, equally applicable, applicable there. So we have about 60 of the Fortune 500s that we are engaged in right now. Many of them are paying customers as well. >> How are they buying, service? Is it... >> Yeah. So we provide software that actually sits inside the customer's own administrative control, delivered as a service, that they can use to go- >> So on-premise hosting or in the cloud? >> Entirely in the cloud, delivered as a service, so they didn't need to take care of the maintenance and whatnot, but they just consume it from the cloud directly, okay? And so, where we are right now is essentially, I have a branch of repeatable use cases that many customers are employing us for. So again, building highways, many different ways to build highways, at the same time take care of the micro-segmentation requirements, and then importantly, this whole NetDevOps, right? This whole NetDevOps is a cultural shift that we have seen. So if you are a network engineer, NetDevOps seems like it's a foreign term, right? But if you are an operational engineer, then NetDevOps, you know exactly what to do. So bringing all those principles together, making sure that the networking teams are empowered to essentially embrace the cloud that I created, the single biggest thing that we have done, I would say done well, is we have built very well on top of the cloud provider. So we don't go against cloud-native services. They have done that really, really well. It makes no sense to go say, "I have a better transit gateway than you." No. Hands down, an AWS transit gateway, or an Azure V1 and whatnot, are some of the best services that they have provided. But what does that mean? >> How do you build software into it? >> Exactly, right? And so how can you build a layer of software on top, so that when you attach that into the applications, right, that you can actually get the experience required, you can get the security requirements and so forth. So that's kind of where we are. We're also humbled by essentially some of the mega partners that have taken a bet on us, sometimes to the extent that, we're a 70% company, and some of the partners that we are talking to actually are quite humbling, right? >> Hey, lot more resource. >> Exactly, yeah. >> And how many rounds of financing have you done? >> So we have done two rounds of financing, we have raised about 55,000,000 in capital, again, really great set of investors backing us up, and a strong sense of conviction, on kind of where we are going. >> Do you think you're early, or not? 'Cause, that's always probably the biggest scary, I can see the smile, is that what keeps you up at night? >> So, yeah, exactly, I go through these phases internally in my head. >> The vision's right on the money, no doubt about it. >> So when you win an opportunity, and we have like, a few dozen of these, right, when you win an opportunity, you're like, "Yes, absolutely, this is where it is," right, and you go for a week and you don't win something, and you're like, "Hey man, why are we not seeing this?" Right, and so you go through these cycles, but I'll tell you with conviction, the fact that customers are moving workloads into the public cloud, not in dozens but in like, the hundreds and the thousands, essentially means that they need something like this. >> And the cloud-native wave is driving big time. >> Exactly, right. And so, when the customer as a conversation with AWS, Azure, GCP, and they are privy to all the services, and we go in after that and talk about, "How do I put this together and help you focus on your outcomes?" That mentally moves them. >> It's a day zero opportunity, and then you got headroom beyond that. >> Exactly. So that's the positive side of it, and enterprises certainly are sometimes a little cautious about when they're up new technologies and so forth. It's a natural cycle. Fortunately, again we are humbled by the fact that we have a few dozen of the pioneering customers that are using our platform. That gives you the legitimacy for a start-up. >> You got great pedigree on clients. Real quick, final question. 30 seconds. What's the pain point, for people watching, when do they call you in? What's their environment look like, what are some of the things that give the signals that you guys got to get the call? >> If you have more than, let's say five or ten VPCs in the cloud, and you have not invested in building a networking platform that gives you the connectivity, the security, the observability, and the performance requirements, you absolutely have to do that, right? Because we have seen many, many customers, it goes from 5 to 50 to 100 within a week, and so you don't want to be caught essentially in the midst of that. >> One more final final question. Since you're a seasoned entrepreneur, you've been there, done that previous times, >> Yeah, I've got scars. (laughs) >> Yes, we've all got scar tissue. We've been doing theCube for 12 years, we've seen a lot of stuff. What's the difference now in this market that's different than before? What's exciting you? What's the big change? What's, in your opinion, happening now that's really important that people should pay attention to? >> Absolutely. A lot of it is driven by one, the focus on the cloud itself, right? That's driving a sense of speed like never before. Because in the infrastructure world, yeah you do it today, oh, you do it six months from now, you had some leeway. Here, networking security teams are being yelled at almost every single day, by the cloud guy saying, "You guys are not moving fast enough, fast enough, fast enough." So that thing is different. So it helps, going to shrink the sale cycle for us. So second big one is, nobody knows, essentially, the new set of use cases that are coming about. We are seeing patterns emerge in terms of new use cases almost every single day. Some days it's like completely on the other end of the spectrum. Like, "I'm only serverless and service mesh." On the other end, it's like, "I have a package application, I'm moving it to the cloud." Right? And so, we're learning a lot as well. >> A great time for Supercloud. >> Exactly. >> Do the cloud really well, make it super, bring it to other use cases, stitch it all together, make it easy to use, reduce the complexity, it's just evolution. >> Yeah. And our goal is essentially, enterprise customers should not be focused so much on building infrastructure this way, right? They should focus on users, application services, let vendors like us worry about the nitty-gritty underneath. >> Ramesh, thank you for this conversation. It's a great Cube conversation. In the middle of all the action, Supercloud, multi-cloud, the future is going to be very much cloud-based, IaaS, SaaS, connecting environments. This is the cloud 2.0, Superclouds. And this is what people are going to be working on. I'm John Furrier with theCube, thanks for watching. (soft music)

>> Narrator: Live from Austin Texas. It's theCUBE, covering KubeKon and CloudNativeCon 2017. Brought to you by Red Hat, the Linux Foundation, and theCUBE's ecosystem partners. >> Welcome back everyone, live here in Austin Texas, theCUBE's exclusive coverage of CloudNativeConference and KubeKon, for Kubernetes' Conference. I'm John Furrier, co-founder of SiliconANGLE and my co-host Stu Miniman, our analyst. And next is Matt Klein, a software engineer at Lyft, ride-hailing service, car sharing, social network, great company, everyone knows that everyone loves Lyft. Thanks for coming on. >> Thanks very much for having me. >> All right so you're a customer of all this technology. You guys built, and I think this is like the shiny use cases of our generation, entrepreneurs and techies build their own stuff because they can't get product from the general market. You guys had a large-scale demand for the service, you had to go out and build your own with open source and all those tools, you had a problem you had to solve, you build it, used some open source and then give it back to open source and be part of the community, and everybody wins, you donated it back. This is, this is the future, this is what it's going to be like, great community work. What problem were you solving? Obviously Lyft, everyone knows it's hard, they see their car, lot of real time going on, lot of stuff happening >> Matt: Yeah, sure. >> magic's happening behind the scenes, you had to build that. Talk about the problem you solved. >> Well, I think, you know, when people look at Lyft, like you were saying, they look at the app and the car, and I think many people think that it's a relative simple thing. Like how hard could it be to bring up your app and say, I want a ride, and you know, get that car from here to there, but it turns out that it's really complicated. There's a lot of real-time systems involved in actually finding what are all the cars that are near you, and what's the fastest route, all of that stuff. So, I think what people don't realize is that Lyft is a very large, real-time system that, at current scale, operates at millions of requests per second, and has a lot of different use cases around databases, and caching, you know, all those technologies. So, Lyft was built on open source, as you say, and, you know Lyft grew from what I think most companies do, which is a very simple, monolithic stack, you know, it starts with a PHP application, we're a big user of MongoDB, and some load balancer, and then, you know-- >> John: That breaks (laughs) >> Well, well no but but people do that because that's what's very quick to do. And I think what happened, like most companies, is, or that most companies that become very successful, is Lyft grew a lot, and like the few companies that can become very successful, they start to outgrow some of that basic software, or the basic pieces that they're actually using. So, as Lyft started to grow a lot, things just didn't actually start working, so then we had to start fixing and building different things. >> Yeah, Matt, scale is one of those things that gets talked about a lot. But, I mean Lyft, you know, really does operate at a significant scale. >> Matt: Yeah, sure. >> Maybe you can talk a little bit about, you know, what kind of things were breaking, >> Matt: Absolutely, yeah, and then what led to Envoy and why that happened. >> Yeah, sure. I mean, I think there's two different types of scale, and I think this is something that people don't talk about enough. There's scale in terms of things that people talk about, in terms of data throughput or requests per second, or stuff like that. But there's also people scale, right. So, as organizations grow, we go from 10 developers to 50 developers to 100, where Lyft is now many hundreds of developers and we're continuing to grow, and what I think people don't talk about enough is the human scale, so you know, so we have a lot of people that are trying to edit code, and at a certain size, that number of people, you can't all be editing on that same code base. So that's I think the biggest move where people start moving towards this microservice or service-oriented architecture, so you start splitting that apart to get people-scale. People-scale probably usually comes with requests per second scale and data scale and that kind of stuff. But these problems come hand in hand, where as you grow the number of people, you start going into microservices, and then suddenly you have actual scale problems. The database is not working, or the network is not actually reliable. So from Envoy perspective, so Envoy is an open source proxy we built at Lyft, it's now part of CNCF, it's having tremendous uptake across the industry, which is fantastic, and the reason that we built Envoy is what we're seeing now in the industry is people are moving towards polyglot architectures, so they're moving towards architectures with many different applications, or many different languages. And it used to be that you could use Java and you could have one particular library that would do all of your networking and service discovery and load balancing, and now you might have six different languages. So how as an organization do you actually deal with that? And what we decided to do was build an out-of-process proxy, which allows people to build a lot of functionality into one place, around load balancing, and service discovery, and rate limiting, and buffering, and all those kinds of things, and also most importantly, observability. So things like tracing and stats and logging. And that allowed us to actually understand what was going on in the network, so that when problems were happening, we could actually debug what was going on. And what we saw at Lyft, about three years ago, is we had started our microservices journey, but it was actually almost, it was almost stopped, because what people found is they had started to build services because supposedly it was faster than the monolith, but then we would start having problems with tail latency and other things, and they didn't know hot to debug it. So they didn't trust those services, and then at that point they say, not surprisingly, we're just going to go back and we're going to build it back into the monolith. So, we're almost in that situation where things are kind of in that split. >> So Matt I have to think that's the natural, where you led to service mesh, and Istio specifically and Lyft, Google, IBM all working on that. Talk a little bit about, more about what Istio, it was really the buzz coming in with service mesh, there's also there's some competing offerings out there, Conduit, new one announced this week, maybe give us the landscape, kind of where we are, and what you're seeing. >> So I think service mesh is, it's incredible to look around this conference, I think there's 15 or more talks on service mesh between all of the Buoyant talks on Linker D and Conduit and Istio and Envoy, it's super fantastic. I think the reason that service mesh is so compelling to people is that we have these problems where people want to build in five or six languages, they have some common problems around load balancing and other types of things, and this is a great solution for offloading some of those problems into a common place. So, the confusion that I see right now around the industry is service mesh is really split into two pieces. It's split into the data plane, so the proxy, and the control plane. So the proxy's the thing that actually moves the bytes, moves the requests, and the control plane is the thing that actually tells all the proxies what to do, tells it the topology, tells it all the configurations, all the settings. So the landscape right now is essentially that Envoy is a proxy, it's a data plane. Envoy has been built into a bunch of control planes, so Istio is a control plane, it's reference proxy is Envoy, though other companies have shown that they can integrate with Istio. Linker D has shown that, NGINX has shown that. Buoyant just came out with a new combined control plane data plane service mesh called Conduit, that was brand new a couple days ago, and I think we're going to see other companies get in there, because this is a very popular paradigm, so having the competition is good. I think it's going to push everyone to be better. >> How do companies make sense of this, I mean, if I'm just a boring enterprise with complexity, legacy, you know I have a lot of stuff, maybe not the kind of scale in terms of transactions per second, because they're not Lyft, but they still have a lot of stuff. They got servers, they got data center, they got stuff in the cloud, they're trying to put this cloud native package in because the developer movement is clearly pushing the legacy guy, old guard, into cloud. So how does your stuff translate into the mainstream, how would you categorize it? >> Well, what I counsel people is, and I think that's actually a problem that we have within the industry, is that I think sometimes we push people towards complexity that they don't necessarily need yet. And I'm not saying that all of these cloud native technologies aren't great, right, I mean people here are doing fantastic things. >> You know how to drive a car, so to speak, you don't know how to use the tech. >> Right, and I advise companies and organizations to use the technology and the complexity that they need. So I think that service mesh and microservices and tracing and a lot of the stuff that's being talked about at this conference are very important if you have the scale to have a service-oriented microservice architecture. And, you know, some enterprises they're segmented enough where they may not actually need a full microservice real-time architecture. So I think that the thing to actually decide is, number one, do you need a microservice architecture, and it's okay if you don't, that's just fine, take the complexity that you need. If you do need a microservice architecture, then I think you're going to have a set of common problems around things like networking, and databases, and those types of things, and then yes, you are probably going to need to build in more complicated technologies to actually deal with that. But the key takeaway is that as you bring on, as you bring on more complexity, the complexity is a snowballing effect. More complexity yields more complexity. >> So Matt, might be a little bit out of bounds for what we're talking about, but when I think about autonomous vehicles, that's just going to put even more strain on the kind of the distributed natured systems, you know, things that have to have the edge, you know. Are we laying the groundwork at a conference like this? How's Lyft looking at this? >> For sure, and I mean, we're obviously starting to look into autonomous a lot, obviously Uber's doing that a fair amount, and if you actually start looking at the sheer amount of data that is generated by these cars when they're actually moving around, it's terabytes and terabytes of data, you start thinking through the complexity of ingesting that data from the cars into a cloud and actually analyzing it and doing things with it either offline or in real-time, it's pretty incredible. So, yes, I think that these are just more massive scale real-time systems that require more data, more hard drives, more networks, and as you manage more things with more people, it becomes more complicated for sure. >> What are you doing inside Lyft, your job. I mean obviously, you're involved in open source. Like, what are you coding specifically these days, what's the current assignment? >> Yeah, so I'm a software engineer at Lyft, I lead our networking team. Our networking team owns obviously all the stuff that we do with Envoy, we own our edge system, so basically how internet traffic comes into Lyft, all of our service discovery systems, rate limiting, auth between services. We're increasingly owning our GRPC communications, so how people define their APIs, moving from a more polling-based API to a more push-based API. So our team essentially owns the end-to-end pipe from all of our back-end services to the client, so that's APIs, analytics, stats, logging, >> So to the app >> Yeah, right, right, to the app, so, on the phone. So that's my job. I also help a lot with general kind of infrastructure architecture, so we're increasingly moving towards Kubernetes, so that's a big thing that we're doing at Lyft. Like many companies of Lyft's kind of age range, we started on VMs and AWS and we used SaltStack and you know, it's the standard story from companies that were probably six or eight years old. >> Classic dev ops. >> Right, and >> Gen One devops. >> And now we're trying to move into the, as you say, Gen Two world, which is pretty fantastic. So this is becoming, probably, the most applicable conference for us, because we're obviously doing a lot with service mesh, and we're leading the way with Envoy. But as we integrate with technologies like Istio and increasingly use Kubernetes, and all of the different related technologies, we are trying to kind of get rid of all of our bespoke stuff that many companies like Lyft had, and we're trying to get on that general train. >> I mean you guys, I mean this is going to be written in the history books, you look at this time in a generation, I mean this is going to define open source for a long, long time, because, I say Gen one kind of sounds pejorative but it's not. It's really, you need to build your own, you couldn't just buy Oracle database, because, you probably have some maybe Oracle in there, but like, you build your own. Facebook did it, you guys are doing it. Why, because you're badass, you had to. Otherwise you don't build customers. >> Right and I absolutely agree about that. I think we are in a very unique time right now, and I actually think that if you look out 10 years, and you look at some of the services that are coming online, and like Amazon just did Fargate, that whole container scheduling system, and Azure has one, and I think Google has one, but the idea there is that in 10 years' time, people are really going to be writing business logic, they're going to insert that business logic >> They may do a powerpoint slides. >> That would be nice. >> I mean it's easy to me, like powerpoint, it's so easy, that's, I'm not going to say that's coding, but that's the way it should be. >> I absolutely agree, and we'll keep moving towards that, but the way that's going to happen is, more and more plumbing if you will, will get built into these clouds, so that people don't have to worry about all this stuff. But we're in this intermediate time, where people are building these massive scale systems, and the pieces that they need is not necessarily there. >> I've been saying in theCUBE now for multiple events, all through this last year, kind of crystallized and we were talking about with Kelsey about this, Hightower, yesterday, craft is coming back to programming. So you've got software engineering, and you've got craftsmanship. And so, there's real software engineering being done, it's engineering. Application development is going to go back to the old school of real craft. I mean, Agile, all it did was create a treadmill of de-risking rapid build scale, by listening to data and constantly iterating, but it kind of took the craft out of it. >> I agree. >> But that turned into engineering. Now you have developers working on say business logic or just solving, building a healthcare app. That's just awesome software. Do you agree with this craft? >> I absolutely agree, and actually what we say about Envoy, so kind of the catchword buzz phrase of Envoy is to make the network transparent to applications. And I think most of what's happening in infrastructure right now is to get back to a time where application developers can focus on business logic, and not have to worry about how some of this plumbing actually works. And what you see around the industry right now, is it is just too painful for people to operate some of these large systems. And I think we're heading in the right direction, all of the trends are there, but it's going to take a lot more time to actually make that happen. >> I remember when I was graduating college in the 80s, sound old but, not to date myself, but the jobs were for software engineering. I mean that is what they called it, and now we're back to this devops brought it, cloud, the systems kind of engineering, really at a large scale, because you got to think about these things. >> Yeah, and I think what's also kind of interesting is that companies have moved toward this devops culture, or expecting developers to operate their systems, to be on call for them and I think that's fantastic, but what we're not doing as an industry is we're not actually teaching and helping people how to do this. So like we have this expectation that people know how to be on-call and know how to make dashboards, and know how to do all this work, but they don't learn it in school, and actually we come into organizations where we may not help them learn these skills. >> Every company has different cultures, that complicates things. >> So I think we're also, as an industry, we are figuring out how to train people and how to help them actually do this in a way that makes sense. >> Well, fascinating conversation Matt. Congratulations on all your success. Obviously a big fan of Lyft, one of the board members gave a keynote, she's from Palo Alto, from Floodgate. Great investors, great fans of the company. Congratulations, great success story, and again open source, this is the new playbook, community scale contribution, innovation. TheCUBE's doing it's share here live in Austin, Texas, for KubeKon, for Kubernetes conference and CloudNativeCon. I'm John Furrrier, for Stu Miniman, we'll be back with more after this short break. (futuristic music)

>> Narrator: From Austin, Texas. It's theCUBE, covering KubeKon and CloudNativeCon 2017. Brought to you by Red Hat, the Linux Foundation, and theCUBE's ecosystem partners. >> Hello everyone, welcome back to our live exclusive coverage of the CloudNative Conference and KubeKon, put on by the Linux Foundation. I'm John Furrier, the co-founder of SiliconAngle Media. My co-host Stu Miniman, we're here breaking down all the action in the tsunami of open source developers, a renaissance of software development. As you know I've been talking about our next guest. We're excited to have Kelsey Hightower, who's the co-chair of the committee here for the program for this awesome conference that's exploding, but is also a staff engineer at Google, known in the industry as a very active participant. Kelsey, great to have you on. >> Awesome, happy to be here, feel like I've made it now. >> Well, not really, you make it every day on Twitter, we follow you, I mean, you've been an active voice, and it's been fun to watch this community. We've been present at the creation of KubeKon, and we've been watching the evolution, really kind of, the, it's like jello that kind of forms in the refrigerator. A couple years ago, you saw it come together, containers, microservices, the drive or the tailwind for now Kubernetes orchestration opportunity, it's changed the game. What is the bottom line? How is Kubernetes, because, everything was all about containerization, that was going to change the world, but it kind of did, but it's evolving. What's so important about Kubernetes? >> I think Kubernetes is really an actual thing you can use that takes all the ideas we've been working on for the last 20 years, and just gives us a new starting point. So, less about changing the game, but actually making the game available to everybody, right. So, we always talk about containers as this revolution, but you think about containers as more like, let's take VMs and make them faster to use, shrink them down, and then the configuration management world of deploying those things, Kubernetes wraps all that hard-to work into a single thing, and if you start there it feels like you just leapfrog where you were. >> Kelsey, I want to ask on that, so much we get excited about, you know, the cool little tool, but it's about the patterns, it's about what I can build with it. When I look at this community, you know, that boring infrastructure stuff is important, but it's about building the applications and what I can do with it that we seem to really see coming out of this event. >> Yeah, Kubernetes represents the experience of like the Red Hats, the CoreOS's, the Googles of the world into a thing you use. So when I talk about Kubernetes, is like when we solve a new problem, just like in Linux, it rolls back into the platform, but it covers this big problem set that almost anyone writing software has, and I think this is why the traction of Kubernetes is so big so fast. >> So many successes, I mean, I just love watching the tech evolution. Uber, Lyft, Netflix, building scale software on open source. And there are a lot of success stories. Two things jumped out at me in the keynote. Pluggable architectures and service meshes, two dynamics that are pretty instrumental and part of it. It sounds intoxicating and it's cool, but then if I'm just a practitioner out there, and like, all the other stuff I'm used to is hard, what about security and storage? So, there is a lot of other things that are important to customers, the blocking and tackling, storage networking, whatever, and then new things are coming to the table. So you've got new vocabulary, new concepts, combined with the existing, pre-existing, old guard concepts like storage, networking. How does that, how do you connect that? So, for the person who's running IT, or the CIO or the person doing technical architecture in a large, big IT department or company, they got to grok this. How do they figure it out, how do you dissect it? >> So the problems didn't change. Your app takes input, does something, produces output. About 30 years in the making now, that doesn't change. Kubernetes doesn't change that, containers doesn't change that. So I think all this stuff, if you look at what you've been building your whole career, all the bash scripts, all the tools that you brought in, their whole goal was to let you focus on building those applications. We've taken all of those things, realized what the patterns were, so if you look at Kubernetes and you lay out OS on top of all the storage, the compute and the networking and just says hey, here's a new set of primitives, and we're going to make it easy to consume those. And then the next level on top of that, security, is inherently baked in for the most part. So, I used to work in finance. When you look it and say, what's running? Most people can't answer that question. Not easily, or with a straight face. In Kubernetes, we have a declarative object that tells you, these are the things running, they were started at this time by this person. That's what you get by default, even though we don't talk about it as a security primitive, it totally is. >> How, hold on, so declarative continues innovation and integration, how is, why is that important? Does that speak to the distributed nature of it? I mean, why is declarative piece so important? >> So, distributed, I think a lot of times people have been dealing with distributed systems for a long time without understanding how to actually deal with the patterns. So we've just been doing it badly. Once you add more than one machine to your stack, you now have a distributed system. But we've been able to deal with this with like the meet cloud, through a bunch of people at it, right. And everyone just deals with their subsection of the servers. Now we're just laying a thing that lets you treat it like one, single machine, that's how we now start to think about this new problem. So, once you start to have that kind of, those primitives at your disposal, it just changes the way you tackle this particular problem. So, I'm not sure that this is like a whole new mind shift required. It's just that now you can just rebase, right. Like with the mobile phone, you're not necessarily writing apps at the very low level anymore, you're writing way up here with a bunch of new abstractions. >> So you brought up security hits. You know, one of the hot button topics, you know there's the low level, like, wait, do I put it in a VM, or do I do it at the container level, you know, what do you see as kind of the state of security in this space. What do we still need to do? >> There's two levels of this, right. There's the security in my app, so no matter how great Kubernetes gets, no matter how great we do at the very low level of like, this container shouldn't do these things, you still have this layer where your app will set requests from your users, and more than likely, that's where your problems are going to be. No one's doing brute force anymore, I'm just going to come in, on the port that your security team opened, and I'm going to abuse your app, because there's probably some hidden behavior that you are unaware of. So that level of security, we hope that that industry starts to have more people focus at that real value layer, than the stuff down here. So Kubernetes may take care of this down here, so we talk about the declarative piece. I know that this is what's running on these machines, and I can be assured of it, you can actually assert things, and that's part of security. Is it working the way you intended it to work? >> So it decouples security, is what you're saying. Do it, keep it at the declarative level, infrastructure, let the app guys fend for themselves, or is that. >> It's more it's like, let's make it easy to do the right thing. Kubernetes doesn't solve all the problems, but the problems it does solve we make security just be a built-in primitive. >> That's a good argument, it should solve its own problem, not try to do too much. >> But the pattern's now, we start talking about security, if you think about Istio, that goes a little bit higher up the security stack, it also takes a declarative approach. So when you say only these apps can talk to each other, you can declare that, and let the system do the enforcement rather than people. >> Okay I got to give you kind of the question on demographics shift in the developer community here. Obviously the growth is big, the numbers are here, better than all the other events combined. How do you break down the, if you had to draw a line in the sand, kind of infrastructure developers, configuration management, provisioning, all that stuff, to kind of pure app developers who say, hey, I'm devops, I don't really, I'm just want serverless, I want a full pool of resources, all that stuff's taken care of. How would you kind of, 60 40, 30 to 70, how would you, because we've got a lot of new people in here. What's the numbers in your mind? Just guess. >> In my mind I would probably say, this movement has about 70% of people who identify themselves as I'm a developer, I really want a different set of primitives so I can move on. If you look at the last maybe five to ten years where you've been brought into devops, you now have been exposed to infrastructure, and if you're going to be exposed to infrastructure, you want this kind of infrastructure, and not what you had before. And I think the ops people took a little longer. They were like, ah, I don't know, this just looks like something that doesn't solve my problems, or it's only for startups. Now we're starting to see that it'll work for almost any workload, if you understand what Kubernetes is trying to do >> It's hard to parse through the developer definition. >> Well, I mean, look it's 4,000 people here this time, right. We started with 300 people, maybe 500, and now we're at 4,000. You're starting to see everyone say all right, Kubernetes has a spot for me, here's how I contribute and leverage the platform. >> Kelsey, what do you say to people that look at this environment and say it's too complex. There's layers and layers, and I learn one piece, and it's changing constantly. This opportunity, threat, you know-- >> Here's the thing, everything is life is too complex. Anything you don't understand is too complex, okay. But if I go to your company and say, how long will it take me to learn all of your systems? Years, probably. Not everyone knows everything, so I think all these things by their very nature are complex. But if you think about what Kubernetes does, it at least takes all that complexity and gives it an API. You can now reason about it. So if you take the time to learn Kubernetes, all of this stuff from how do I deploy my app, to how we manage the hardware, at least has a defined API for the first time. It isn't going to be random from corporation to corporation, we're now aggregating the complexity and giving it a name. >> In your mind, how you would you define a high-quality pluggable architecture to leverages the goodness of Kubernetes. What does that look like, how should someone kind of check their, checksum their code, if you will, look at it and say okay, that's a pluggable architecture? What does it look like? >> So Kubernetes, if you think about it, the whole thing is extensible. So when people talk about the complexity, it's because there are a lot of moving pieces. So it was designed to leverage its own API since day one. So if you want to add a new scheduler, the thing that does, where does this application run, our current scheduler uses the Kubernetes API to do that, you can bring in your own, and Univa's a good example from two years ago, adding their own scheduler to Kubernetes. If you want like a TLS certificate from Let's Encrypt, there's a very obvious way that you would do that in Kubernetes. So our whole platform is API-driven from the outset. >> John: And the benefit of that is integration, right? >> Integration, extensibility, like, one thing that has always plagued our industry is, you buy this big software package, you want to do something custom, and now you're screwed. Now what you have is, we expect it to be extended, and your technology partner of choice will be able to extend it in a way that you can actually upgrade the thing. >> All right, so slightly different area. Kubernetes now, there's what, 42 certified partners out there. Will anybody make money on it? I come in saying, I don't think it's directly, I think it more like the cloud platforms, the other platforms. What's your take on the whole business aspect of this? >> I think it's kind of like Linux. How many people make money on Linux. I think even the people that do make money on Linux, it's the support, it's the service, and I think Kubernetes sets the stage for technology partners. You can't just sell me Kubernetes and walk away. You have to give me Kubernetes and envision how my business will extend on top of it. So, I want to do machine learning. Kubernetes is a great platform for doing machine learning. The value is above that, with the machine learning and all that other stuff. What's your take on the dynamic of all contributors here. I know joining Google, one of the reasons if I remember right from reading, you know, it's just, their participation in open source. Microsoft, big on open source, Adrian Cockcroft was in the keynote this morning, talking about AWS's participation. What your take? >> Honestly if you're a big provider, the value is not proprietary software for you. I'm in a cloud provider, we sell CPU cycles. If you want to use Mesos to spin those CPU cycles, that's great. We happen to believe in Kubernetes, so we provide that based on our experience. So to me, Kubernetes is much more part of our experience, than it is something just, we're all here trying to compete in the market. So, that's why I think people find it valuable, it solves problems that you have and share amongst your peers. >> What's your advice to app developers? Because the impact seems to be obviously to the value creation is going to be on solving problems in a way, new creative way, and again, we're predicting in theCUBE that we're going to see a swing back to the craftsmanship of software development. I mean Agile's great, and it kind of took that craftsmanship, but it de-risked it because you could make it run faster. But we're seeing a renaissance around craft, artisanship. Not just UI, I'm talking about real value. Style change, cultural impact, that's in a value opportunity. Your thoughts? >> When you talk about craftsmanship, the thing that we always look at when craftsmanship, we always talk about how long it takes to do something. I made this by hand. This was aged for 50 years before we drink it. And I think what we're doing now in the enterprises, we don't have time now to focus on the craft, I need it by Friday. And I also got to figure out the infrastructure first. So when you get things like Kubernetes, and then you layer on platforms like serverless and these PaaS's that sit on top, now you can actually focus on craftsmanship. Let me get this library right. Or, if there's another company that has already figured it out, and they've taken 10 years to get that library perfect, I get to actually use their hand-crafted piece in my hand-crafted piece, and then we start to get to the actual visions. So, I think the key missing element today is time. These platforms get you your time back, then you can actually invest in that craftsmanship. >> All that heavy lifting around redundant stuff that you shouldn't have to do, I mean, hell, I'm old, I remember how we used to have to do our own graphics libraries, now it's like, the artisanship is coming back. I 100% agree with you, but this is an opportunity that no one's yet monetized because it had never existed before, at this level of speed, reliability. >> They're monetizing, you're seeing the business monetizes. So remember, I don't necessary think that the vendors, the traditional IT vendors will be the one that monetize this, it's going to be the Netflixes of the world, the people that have an idea and they to market and then within two years, they have this large control of the market, because now they look at it and say, start with Kubernetes, grab Prometheus, grab these pieces that have been handcrafted by a large community that cares, and we're just going to focus on my business piece. That's who's cashing in. >> The value is shifting, the value is shifting. >> Kelsey, you mentioned time. First of all I want to say thank you for giving us some time and this community. I've seen so many examples, people are like, Kelsey Hightower gave me a call and talked to me for 10 15 minutes, you know, I'm nobody, podcasts, writing, everything else. How do you keep on about it, how do you look and see kind of this community continue to grow? >> Honestly you got to be, I'm a people person. And people are like, no, no, you work at a vendor, you're super biased. It's like, no, I am actually a people person >> You work at a vendor? >> Yeah, exactly. So for me, the people are first, because these people helped me get to where I am today, and I'm super appreciative of it. So when I get a chance, someone DMs me on Twitter and says, hey, Kelsey, I'm trying to reinvent my career. If I'm busy, I say call me. And I pick up the phone and say hey, how are you doing? Here's what worked for me. I'll listen for a while and say hey, here's my professional opinion, and I don't actually mind when other people do well. And I think a lot of times you want to shine by ourselves so much that we don't want to give away the secret sauce too early, because then I might be able to shine. I actually find it very enjoyable if I helped you with your talk, and you go and you rock the stage, and you go back to work and you get promoted, and then you tell me, hey, I really appreciate that. I found the ability to say you know what, you win, I win. >> You know, pay it forward in community is critical, that is a great example. More people should do it, congratulations. Paying it forward is all about selflessness. >> But it feels good when you do it. People don't understand, it feels good when you're around people that also feel good. >> You're so selfish with your selflessness. >> There you go (laughs). >> All right, final question for you. By the way, everyone should be like that because that's what communities do, good, thriving, robust communities help each other, they might be a little bit cocky but that's swagger, I like that, but, helping people's key. You have some good swagger, we appreciate your work on Twitter. My final question, your talk. What are you going to be talking about?6 What's the keynote like? Give a preview. >> So the preview is that I was going through the release notes of Kubernetes, and it's actually boring. 1.9, if you look at what we're shipping, it's all about stability, it's all about delivering the promises we made years ago, they're finally becoming V1 now. That's about it. There's nothing that I'm going to change in my cluster because of 1.9, and that's the major feature. We've been talking about getting infrastructure to become boring, and when I can look at a new release of Kubernetes and not freak out that I have to go change a bunch of stuff, we've finally done it. We've done the part that we're designed to do. So what I want to do is say hey, if Kubernetes is boring, where does the excitement live, and what does it look like? So I'm going do a lot of live demos of here's what it looks like when you're doing it correctly from my point of view, based on experience. >> Boring is calm, boring is reliable, the action is on top >> There you go. >> All right. Kelsey Hightower, thank you so much, it's been a time. Appreciate you coming on theCUBE, and sharing your insights and commentary. You'd be a great CUBE analyst, we'd love to have you on anytime. I'm John Furrier, Stu Miniman here at CloudNativeCon KubeKon live in Austin, Texas. Back with more live coverage after this short break.