 Live from Barcelona, Spain, it's theCUBE, covering KubeCon CloudNativeCon Europe 2019. Brought to you by Red Hat, the CloudNative Computing Foundation and Ecosystem Partners. Welcome back to theCUBE's live coverage of CloudNativeCon, KubeCon 2019. I'm Stu Miniman, my co-host is Corey Quinn and happy to welcome back to the program. Doug Davis, who's a senior technical staff member and PM of Knative, and happens to be employed by IBM. Thanks so much for joining us. Thanks for inviting me. All right, so Corey got really excited when he saw this because Serverless is something that he's been doing for a while, I've been poking in trying to understand all the pieces, I've done Serverless Conf a couple of times, and I guess lay out for our audience a little bit, Knative, I look at it kind of a bridging solution, but we've been talking, it's not the containers or Serverless, and we understand that IT world, there's spectrums and there's overlap, so maybe as that is a setup, what is the Serverless working group's charter? Right, so the Serverless working group is a CNCF working group. It was originally started back in mid-2017 by the Technical Oversight Committee in CNCF. They basically wanted to know what is Serverless all about, is new technology, is it something that you get involved with and stuff like that? So they started up the Service Working Group and our main mission was just to do some investigation. And so the output of this working group was a white paper, basically describing Serverless, how it compares with the other as is out there, what are the good use cases for it, when to use it, when not to do it, common architectures, basically just explaining what the heck is going on in that space. And then we also produced a landscape document, basically laying out what's out there from a proprietary perspective as well as open source perspective, and then the third piece was at the tail end of the white paper, a set of recommendations for the TOC or CNCF in general, what should they do next? And it basically came down to three different things. One was education. We want to educate the community on what Serverless is, when it's appropriate, stuff like that. Two, what should, wait, I'm sorry, I'm giving too many things in my head. Recommendations, what other projects we pull into the CNCF, other Serverless projects, getting encouraged in the joint to grow the community. And third, what should we do around interoperability? Because obviously when it comes to open source standards and stuff like that, we want interoperability, portable and stuff like that. And one of the low-hanging fruits that we identified was, well Serverless seems to be all about events. So is there something in inventing space we can do? And we recognize, well, if we could help the processing of events as it moves from point A to point B, that might help people in terms of middleware, in terms of routing events, filtering events, stuff like that. And so that's how these cloud events project got started. And so that's where most of the Serverless working group members are nowadays, is cloud events working group or project. And they're basically designing, as I said, specification around cloud events. And you kind of think of it as defining metadata to add to your current events, because we're not going to tell you, oh, here's yet another one-size-fits-all cloud event format, right? It's take your current event, sprinkle a little extra metadata in there just to help routing. And that's really what it's all about. One of the first things people say about Serverless is quoted directly from the cover of Missing the Point magazine. Serverless runs on servers. Wonderful. Thank you for your valuable contribution. Go away. Slightly less naive is, I think, an approach that I've seen a couple of times so far at this conference when talking to people that they think of it in terms of functions as a service, of being able to take arbitrary code and run it. I have a wristwatch I can run arbitrary code on. That's not really the point. I think you're right. It's talking more about the event model and what that unlocks as your application, more or less, starts to become more self-aware. Are you finding that acceptance of that viewpoint is taking time to take root? Yeah, I think what's interesting is, when we first started looking at Serverless, I think a lot of people did think of Serverless equals function of the service, and that's all it was. I think what we're finding now is this mode where people are more open to the idea of sort of as I think you're alluding to, merging of these worlds. Because when you look at the functionality that service offers, things like event-based, which really all he means is a message is coming in. It just happens to look like an event. Okay, fine. Message comes in, you auto-scale based upon load and stuff like that, scale down to zero is one of the key factors of Serverless. All these other things or all these features, why should you limit those to Serverless? Why not a PaaS platform? Why not containers of service? Why would you want those just for one little as column? And so my goal with things like Knative, I'm glad you mentioned it, is because I think Knative does try to span those and I'm hoping it kind of merges them all together and says, look, I don't care what you call it. Use this piece of technology because it does what you need to do. If you want to think of it as a PaaS, go for it. I don't care. This guy over here, he wants to think of it as a PaaS. Great. It's the same piece of technology. Does the feature do what you need, yes or no, ignore the terminology around it more than anything else. So I agree. We had a great discussion with the user earlier and he said, from a developer standpoint, I actually don't want to think too much about which one of these PaaS I go down. I want to reduce the friction for them and make it easy. So how does Knative help us move towards that ideal world? Right, and I think, so following with what I said earlier, one of the other things I think Knative does, aside from trying to bridge all the various as columns, is I also look at Knative as a simplification of Kubernetes because as much as everybody here loves Kubernetes, it is kind of complicated. It is not the easiest thing in the world to use and it kind of forced you to be an IT expert which almost goes against the direction we were headed when you think of Cloud Foundry and stuff like that where it's like, hey, you don't have to worry about this stuff anymore, just give us your code. Kubernetes says, nope, you got to know about networks, ingress and volumes and everything else. It's like, I'm sorry, isn't this going the wrong way? Well, Knative tries to back up a little and say, give you all the features of Kubernetes but in a simplified platform or API experience that you can get similar to Cloud Foundry, similar to Docker and stuff, but gives you all the benefits of Kubernetes. But the important thing is, if for some reason you need to go around Knative because it's a little too simplified or opinionated, you can still go around it to get to the complicated stuff and it's not like you're leaving a different world or you're entering a different world because it's the same infrastructure, the stuff that you deploy on Knative can integrate very nicely with the stuff you deploy through vanilla Kubernetes if you have to. So it is really nice to merge in these two worlds and I'm really excited by that. One thing that I found always strange about serverless is at first it was defined by what it's not and then quickly it came to be defined almost by its constraints. If you take a look at public cloud offerings around this most notably AWS Lambda, there are many others, it comes down to, well, you can only run it for X period of time or it only runs in certain run times or the cold starts become a problem and I think that taking a viewpoint from that perspective artificially hobbles what this might wind up unlocking down the road just because these constraints move and right now it might be a bit of a toy. I don't think it will be as it continues to become more capable. The big value proposition that I keep hearing around serverless and I've mostly bought into has been that it's about business logic and solving the things that are core to your business and not even having to think about infrastructure. Where do you stand on that viewpoint? I completely agree. I think a lot of the limitations you see today are completely artificial. I kind of understand why they're there because the way things sort of progressed. But again, it's one of the reasons I'm excited by Knative is because a lot of those limitations aren't there. Now Knative doesn't have its own set of limitations and personally I do want to try to remove those. Like I said, I would love it if Knative aside from the serverless features it offers up became the simplified Kubernetes experience. So if you think about what you can do with Kubernetes, you can deploy a pod and it can run forever until the system decides to crash for some reason. Why not do that with Knative? And you can today with Knative technically. I have demos that I've been running here where I set the min scale to one, it lives forever and Knative doesn't care, right? And so deploying an application through Knative versus Kubernetes, I don't care that it's the same thing to me and so yes, I do want to merge in those two worlds. I want to lower those constraints as long as you keep it a simplified model and support the 80 to 90% of those use cases that it's actually meant to address leave the hard stuff for going around it a little. All right, so Doug, oftentimes we get caught in this bubble of arguing over what do we call it and how the different pieces are. Yesterday, you had a practitioner summit for serverless. So what I want to hear is, what's the practitioner's viewpoint? What are they excited about? What are they using today? And what are the things that they're asking for to help it become more usable and useful for them in the future? So in full disclosure, we actually had kind of a quiet audience. So they weren't very vocal, but what little I did here is they seemed to be very excited by Knative. And I think a lot of it was because what we were just talking about, sort of the merging of the worlds. Cause I do think there is still some confusion around, as you said, when to use one versus the other. And I think Knative is helping to bring those together and I did hear some excitement around that. In terms of what people actually expect from us in going to the future, I don't know. To be honest, they didn't actually say a whole lot there. I have my own personal opinion and a lot of it is what I already stated in terms of the merging. Stop having me pick a technology or pick a terminology. Right, let me just pick the technology that gets my job done and hopefully that one will solve a lot of my needs. But for the most parts, I think it was really more about Knative than anything else yesterday. I think like Linux before it and any technology at some point, you saw this with virtualization, with cloud, with containers, with Kubernetes. And now we're starting to see it with serverless where some of its most vocal proponents are also the most obnoxious in that they are looking at this from a perspective of what's your problem? I'm not even going to listen to the answer. Solution is fill in favorite technology here. So to that end today, what workloads are not appropriate for serverless in your mind? So this is hard for me to answer because I have the IBM running me running through my head because what's interesting is I do hear people talk about serverless is good for this and not this or Knative is good for this and not this. And I hear those things and I'm not sure I actually buy it, right? I actually think that the only limitations that I've seen in terms of what you should not run on something like Knative or any of the platform is whatever that platform actually binds you to. So for example, on AWS, they may have time limits in terms of how long it can run. If that's a problem for you, don't use it. To me, that's not an artifact of serverless. That's an artifact of that particular choice of how they implement serverless. With Knative, they don't have that problem. You can let it run forever if you want. So in terms of what workloads are good or bad, honestly, I don't have a good answer for that because I don't necessarily buy some of the stories I'm hearing. I personally think try to run everything you can through something like Knative and then when it fails, go someplace else. It's the same story I had when containers first came around. They would say, when do you use VMs versus containers? My go-to answer was always try containers first. Your life will be a whole lot easier. When it doesn't work, then look at the other things because I don't want to try to pitch and hold something like serverless or Knative and say, oh, don't even think about it for these things because it may actually work just fine for you. I don't want people to believe negative hype in a way that makes sense. And that's very fair. I tend to see most of the constraints around this as being implementation details of specific providers and that will dictate answers to that question. I don't mean to sound like I'm coming after you in that sense. That was a very thoughtful and measured response. Thank you. That's an unusual response back to you. So Doug, I'll give you the tough one. The criticism I had in Seattle when I looked at Knative is there's a lot of serverless options out there. But when I talked to users, the number one out there is AWS Lambda. And number two is probably Azure Functions and as of Seattle, neither of those was fully integrated. Since then, I talked to a little startup called, I believe it was TriggerMesh that has made some connections between Lambda and Knative and there was an announcement a couple of weeks ago, KEDA or KEDA, that's Azure and some kind of future to get to Knative. So it feels like it's a maturity thing. And what can you tell us about the big cloud guys? Obviously, see Googles involved, IBM Red Hat and Oracle are involved in Knative. So where do those big cloud players sit tonight? So from my perspective, what I think Knative has going forward over the others is one, a lot of the other guys who run on Kubernetes, I feel like they're sort of like Kubernetes as well as everything else. Like some of them can run on Kubernetes, Docker, anything else. And so they're not necessarily as tightly integrated and leveraging the Kubernetes features the way Knative is doing. And I think that's a little bit unique right there. But the other thing that I think Knative has going for it is the community around it. I think people were noticing exactly what you said. There's a lot of other players out there and it's hard for people to choose. And what I think Google did a great job of is sort of bringing the community together and said, look, can we stop bickering and develop a sort of common infrastructure like Kubernetes is, that we can all then base our serverless platforms on? And I think that rallying cry to bring the community together across a common base is something a little bit unique for Knative when you compare it with the others. And I think that's a big draw for people. At least from my perspective, and I know it's from IBMs as well because community is a big thing for us obviously. Okay, so will there be a bridge to those other cloud players soon? Is there a roadmap for that? Within Knative itself? Yeah. I'm not sure I can answer that one because I'm not sure I've heard a lot of talk about bridging per se. I know that when you talk about things like getting events from other platforms and stuff, obviously through the eventing side of Knative we do, but from a serving perspective, I'm not sure I heard a lot from that perspective yet to be honest. All right. Well, Doug Davis, we're done for this one. Really appreciate all the updates there and definitely look forward to seeing the progress that the serverless working group continues to do. So thank you so much. Thank you for having me. All right, for Corey Quinn, I'm Stu Minin. We'll be back with more coverage here on theCUBE. Thanks for watching.