>> live from Barcelona, Spain. It's the key covering Cook Con Cloud, Native Con Europe twenty nineteen by Red Hat, The Cloud, Native Computing Foundation and Ecosystem Partners. >> Welcome back to the Cubes Live coverage of Cloud Native Con Cube Khan, twenty nineteen I'm student of 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 a native and happens to be employed by IBM. Thanks so much for joining. Thanks for inviting me. Alright. So, Corey, I got really excited when he saw this Because server lists, uh, is something that, you know he's been doing for a while. I've been poking in, trying to understand all the pieces have done marvelous conflict couple of times and, you know, I guess, I guess layout for our audience a little bit, you know, Kay native. You know, I look at it kind of a bridging the solution, but, you know, we're talking. It's not the, you know, you know, containers or server. Listen, you know, we understand that world, they're spectrums, and there's overlap. So maybe is that is a set up. You know what is the service. Working groups, you know, Charter, Right. So >> the service Working Group is a Sand CF working group. It was originally started back in mid two thousand seventeen by the technical recite committee in Cincy. They basically wanted know what is service all about his new technology is that some of these get involved with stuff like that. So they started up the service working group and our main mission was just doing some investigation. And so the output of this working group was a white paper. Basically describing serval is how it compares with the other as is out there. What is the good use cases for when to use? It went out through 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 proprietors perspective as well is open source perspective. And then the third piece was at the tail end of the white paper set of recommendations for the TOC or seen staff in general. What should they do? Do next and basic came down to three different things. One was education. We want to be educate the community on what services, when it's appropriate >> stuff like that >> to what should wait. I'm sorry I'm getting somebody thinks my head recommendations. What other projects we pull into the CNC f others other service projects, you know, getting encouraged in the joint to grow the community. And, third, >> what should we >> do around improbability? Because obviously, when it comes to open source standards of stuff like that, we want in our ability portability, stuff like that. And one of the low hang your food so they identified was, Well, service seems to be all about events. So there's something 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, of events, filtering events, stuff like that. And so that's how these convents project that started. Right? And so that's where most of service working group members are nowadays. Is cloud events working or project, and they're basically divine, Eva 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 of in format, right? It's Take your current events. 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 server list is quoted directly from the cover of Missing the Point magazine Server list Runs on servers. Wonderful. Thank you for your valuable contribution. Go away slightly less naive is, I think, an approach, and 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. It's, I think you're right. It's talking more about the event model and what that unlocks As your application. Mohr less starts to become more self aware. Are you finding that acceptance of that point is taking time to take root? >> Yeah, I think what's interesting is when we first are looking. A serval is, I think, very a lot of people did think of service equals function of the service, and that's all it was. I think what we're finding now is this this mode or people are more open to the idea of sort of as you. I think you're alluding to merging of these worlds because we look at the functionality of service offers things like event base, which really only means is the messages coming in? It just happens to look like an event. Okay, fine. Mrs comes in you auto scale based upon, you know, loaded stuff like that scale down to zero is a one of the key. Thought it was really like all these other things are all these features. Why should you limit those two service? Why not a past platform? Why not? Container is a service. Why would you want those just for one little as column? And so my goal with things like a native though I'm glad you mentioned it is because I think Canada does try to span those, and I'm hoping it kind of merges them altogether 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 pass. Go for I don't care. This guy over here he wants think that is a FAZ Great. It's the same piece of technology. Does the feature do what you need? Yes or no? Ignore that, nor the terminology around it more than anything else. >> So I agree. Ueda Good, 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 pass I go down. I want to reduce the friction for them and make it easy. So you know, how does K native help us move towards that? You know, ideal >> world, right? And I think so fine. With what I said earlier, One of the things I think a native does, aside from trying to bridge all the various as columns is I also look a K native as a simplification of communities because as much as everybody here loves communities, it is kind of complicated, right? It is not the easiest thing in the world to use, and it kind of forced you to be a nightie expert which almost goes against the direction we were headed. When you think of Cloud Foundry stuff like that where it's like, Hey, you don't worry about this something, we're just give us your code, right? Cos well says, No, you gotta know about networks, Congress on values, that everything else it's like, I'm sorry, isn't this going the wrong way? Well, Kania tries to back up a little, say, give you all the features of Cooper Netease, but in a simplified platform or a P I experience that you can get similar Tokat. Foundry is Simo, doctor and stuff, but gives you all the benefits of communities. But the important thing is if for some reason you need to go around K native because it's a little too simplified or opinionated, you could still go around it to get to the complicated stuff. And it's not like you're leaving that a different world or you're entering a different world because it's the same infrastructure they could. This stuff that you deploy on K native can integrate very nicely with the stuff you deploy through vanilla communities if you have to. So it is really nice emerging these two worlds, and I'm I'm really excited by that. >> One thing that I found always strange about server list is a first. It was defined by what it's not and then quickly came to be defined almost by its constraints. If you take a look at public cloud offerings around this, most notably a ws land other there, many others it comes down well. You can only run it for experience, time or on Lee runs in certain run times, or it's something the cold starts become a problem. I think that taking a viewpoint from that perspective artificially hobbles what this might wind up on locking 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 because it needs to become more capable. The big value proposition that I keep hearing around server listen I've mostly bought into has been that it's about business logic and solving the things that Air corps 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 have progressed, But again, it's one reason I excited like a native is because a lot of those limitations aren't there. Now. Kay native 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 K native, aside from the service features it offers up, became these simplified incriminate his experience. So if you think about what you could do with Coronet is right, you can deploy a pod and they can run forever until the system decides to crash. For some reason, right, why not do that with a native and you can't stay with a native? Technically, I have demos that I've been running here where I set the men scale the one it lives forever, and teenager doesn't care right? And so deploying an application through K native communities. 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 wantto lower those constraints as long as you keep it a simplified model and support the eighty to ninety percent of those use cases that it's actually meant to address. Leave the hard stuff for going around it a little. >> Alright, So, Doug, you know, it's often times, you know, we get caught in this bubble of arguing over, you know? You know what we call it, how the different pieces are. Yesterday you had a practitioner Summit four server list. So what? I want to hear his You know, whats the practitioners of you put What are they excited about? What are they using today and what are the things that they're asking for? Help it become, you know, Maur were usable and useful for them in the future. >> So in full disclosure, we actually kind of a quiet audience, so they weren't very vocal. But what little I did here is they seemed very excited by K native and I think a lot of it was because we were just talking about sort of the merging of the worlds because I do think there is still some confusion around, as you said, when to use one versus the other. And I think a native is helping to bring those together. And I did hear some excitement around that in terms of what people actually expect from us going the future. I don't know the honest They didn't actually say a whole lot there. I had my own personal opinion, and lot of is what already stayed in terms of emerging. Stop having me pick a technology or pick a terminology, right? Let me just pick technology gets my job done and hopefully that one will solve a lot of my needs. But for the most part, I think it was really more about Kenya than anything else yesterday. >> I think like Lennox before it. Any technology? At some point you saw this with virtual ization with cloud, with containers with Cooper Netease. And now we're starting to seriously with server lists where some of its most vocal proponents are also so the most obnoxious in that they're looking at this from a perspective of what's your problem? I'm not even going to listen to the answer. The solution is filling favorite technology here. So to that end today, what workloads air not appropriate for surveillance in your >> mind? Um, so this is hardly the answer because I have the IBM Army running through my head because what's interesting is. I do hear people talk about service is good for this and not this or you can date. It was 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 time like he needed or any of the platform is whatever that platform actually finds you, too. So, for example, on eight of us, they may have time limited in terms of how long you can run. If that's a problem for you, don't use it to me. That's not an artifact of service. That's artifact of that particular choice of how the implement service with K native they don't have that problem. You could let it run forever if you want. So in terms of what workloads or good or bad, I honestly I don't have a good answer for that because I don't necessary by some of the the stories I'm hearing, I personally think, try to run everything you can through something like Cain native, and then when it fails, go someplace else is the same story had when containers first came around, they would say, You know when to use viens roses containers. My go to answer was, always try containers first. Your life would be a whole lot easier when it doesn't work, then look at the other things because I don't want to. I don't want to try to pigeonhole something like surly or K native and say, Oh, don't even think about it for these things because it may actually worked just fine for you, right? 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 is being implementation details of specific providers and that that will dictate answers to that question. I don't want to sound like I'm coming after you, and that's very thoughtful of measured >> thank you Usual response back. Teo >> I'LL give you the tough one. The critical guy had in Seattle when I looked at K Native is there's a lot of civilised options out there yet, but when I talked to users, the number one out there is a ws lambda, and number two is probably as your functions and as of Seattle, neither of those was fully integrated since then. I talked a little startup called I Believe his Trigger Mash that that has made some connections between Lambda on K Native. And there was an announcement a couple of weeks ago, Kedia or Keita? That's azure and some kind of future to get Teo K native. So it feels like it's a maturity thing. And, you know, what can you tell us about, you know, the big cloud guys on Felicia? Google's involved IBM Red Hat on and you know Oracle are involved in K Native. So where do those big cloud players? Right? >> So from my perspective, what I think Kenya has going for it over the others is one A lot of other guys do run on Cooper Netease. I feel like they're sort of like communities as well as everything else, like some of them can run. Incriminate is Dr anything else, and so they're not necessary. Tightly integrated and leveraging the carbonates features the way Kay native is doing, and I think that's a little bit unique right there. But the other thing that I think K native has going for it is the community around it. I think people were doing were noticing. Is that what you said? There's a lot of other players out there and his heart feel the choose and what? I think Google did a great job of this sort of bringing the community together and said, Look, can we stop bickering and develop a sort of common infrastructure like communities is that we can all then base our surveillance platforms on, and I think that rallying cry to bring the community together across a common base is something a little bit unique for K native. When you compare it with the others, I think that's a big draw for people. Least from my perspective. I know it from IBM Zzzz Well, because community is a big thing for us, obviously. >> Okay, so will there be a bridge to those other cloud players soon as their road map? For that, >> we think a native itself. Yeah, I am not sure I can answer that one, because I'm not sure I heard a lot of 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 a native. We do. But from a serving perspective, I'm not sure I hold her old water. From that perspective, you have to be >> honest. All right, Well, Doug Davis, we're done for This one really appreciate all the updates there. And I definitely look forward, Teo, seeing the progress that the servant working group continues to do, so thank you so much. Thank you for having me. Alright for Corey Quinn. I'm stupid and will be back with more coverage here on the Cube. Thanks for watching.

>> about >> fifteen live from basically about a room that is a common club native con Europe twenty nineteen by Red Hat, The >> Cloud, Native Computing Foundation and Ecosystem Partners. >> Welcome back to the Cubes. Live coverage of Cloud Native Con Cube Khan, twenty nineteen I'm stupid in my co host is Corey Quinn and having a welcome back to the program, Doug Davis, who's a senior technical staff member and PM of a native. And he happens to be employed by IBM. Thanks so much for joining. Thanks for inviting me. Alright, So Corey got really excited when he saw this because server Lis is something that you know he's been doing for a while. I've been poking in, trying to understand all the pieces have done marvelous conflict couple of times and, you know, I guess, I guess layout for our audience a little bit, you know, k native. You know, I look at it kind of a bridging a solution, but, you know, we're talking. It's not the, you know, you know, containers or server lists. And, you know, we understand that world. They're spectrums and there's overlap. So maybe as that is a set up, you know, What is the surveillance working groups? You know, Charter. Right. So >> the service Working Group is a Sand CF working group. It was originally started back in mid two thousand seventeen by the technical recite committee in Cincy. They basically wanted know what is service all about his new technology is that some of these get involved with stuff like that. So they started up the service working group and our main mission was just doing some investigation. And so the output of this working group was a white paper. Basically describing serval is how it compares with the other as is out there. What is the good use cases for when to use that went out through 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 proprietors perspective as well is open source perspective. And then the third piece was at the tail end of the white paper set of recommendations for the TOC or seen stuff in general. What do they do next? And basic came down to three different things. One was education. We want to be educate the community on what services when it's appropriate stuff like that. Two. What should wait? I'm sorry I'm getting somebody Thinks my head recommendations. What other projects we pull into the CNC f others other service projects, you know, getting encouraged in the joint to grow the community. And third, what should we do around improbability? Because obviously, when it comes to open source standards of stuff like that, we want in our ability, portability stuff like that and one of the low hang your food should be identified was, well, service seems to be all about events. So there's something inventing space we could 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, of events, filtering events, stuff like that. And so that's how these convents project that started. Right? And so that's where most of service working group members are nowadays. Is cod events working or project, and they're basically divine, Eva 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 of in format, right? It's Take your current events. 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 server list is quoted directly from the cover of Missing the Point magazine Server list Runs on servers. Wonderful. Thank you for your valuable contribution. Go away slightly less naive is, I think, an approach, and 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 running, I have a wristwatch I can run arbitrary code on. That's not really the point. It's, I think you're right. It's talking more about the event model and what that unlocks As your application. Mohr 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 are looking. A serval is, I think, very a lot of people did think of service equals function of the service, and that's all it was. I think what we're finding now is this this mode or people are more open to the idea of sort of as you. I think you're alluding to merging of these worlds because we look at the functionality of service offers, things like event based, which really only means is the messages coming in? It just happens to look like an event. Okay, fine. Mrs comes in you auto scale based upon, you know, loaded stuff like that scale down to zero is a the monkey thought it was really like all these other things are all these features. Why should you limit those two service? Why not a past platform? Why not? Container is a service. Why would you want those just for one little as column? And so my goal with things like a native though I'm glad you mentioned it is because I think he does try to span those, and I'm hoping it kind of merges them altogether 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 pass, go for I don't care. This guy over here he wants think that is a FAZ Great. It's the same piece of technology. Does the feature do what you need? Yes or no? Ignore that, nor the terminology around it more than anything >> else. So I agree. Ueda Good, 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 pass I go down. I want to reduce the friction for them and make it easy. So you know, how does K native help us move towards that? You know, ideal >> world, right? And I think so fine. With what I said earlier, One of the things I think a native does, aside from trying to bridge all the various as columns is I also look a K native as a simplification of communities because as much as everybody here loves communities, it is kind of complicated, right? It is not the easiest thing in the world to use, and it kind of forced you to be a nightie expert which almost goes against the direction we were headed. When you think of Cloud Foundry stuff like that where it's like, Hey, you don't worry about this something, we're just give us your code, right? Cos well says No, you gotta know about Network Sing Gris on values that everything else it's like, I'm sorry, isn't this going the wrong way? Well, Kania tries to back up a little, say, give you all the features of Cooper Netease, but in a simplified platform or a P I experience that you can get similar Tokat. Foundry is Simo, doctor and stuff, but gives you all the benefits of communities. But the important thing is if for some reason you need to go around K native because it's a little too simplified or opinionated, you could still go around it to get to the complicated stuff. And it's not like you're leaving that a different world or you're entering a different world because it's the same infrastructure they could stuff that you deploy on. K Native can integrate very nicely with the stuff you deploy through vanilla communities if you have to. So it is really nice emerging these two worlds, and I'm I'm really excited by that. >> One thing that I found always strange about server list is at first it was defined by what it's not and then quickly came to be defined almost by its constraints. If you take a look at public cloud offerings around this, most notably a ws land other there, many others it comes down well. You can only run it for experience time or it only runs in certain run times. Or it's something the cold starts become a problem. I think that taking a viewpoint from that perspective artificially hobbles what this might wind up on locking 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 because it needs to become more capable. The big value proposition that I keep hearing around server listen I've mostly bought into has been that it's about business logic and solving the things that Air Corps 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 have progressed. But again, that's one reason I excited like a native is because a lot of those limitations aren't there. Now, Kay native 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 K native, aside from the serval ISS features it offers up, became these simplified, incriminate his experience. So if you think about what you could do with Coronet is right, you could deploy a pod and they can run forever until the system decides to crash. For some reason, right, why not do that with a native and you can't stay with a native? Technically, I have demos that I've been running here where I set the men scale the one it lives forever, and teenager doesn't care right? And so deploying an application through K native communities. 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 wantto lower those constraints as long as you keep it a simplified model and support the eighty to ninety percent of those use cases that it's actually meant to address. Leave the hard stuff for going around it a little. >> Alright, So, Doug, you know, it's often times, you know, we get caught in this bubble of arguing over, you know? You know what we call it, how the different pieces are. Yesterday you had a practitioner Summit four server list. So what? I want to hear his You know, whats the practitioners of you put What are they excited about? What are they using today and what are the things that they're asking for? Help it become, you know, Maur were usable and useful for them in the future. >> So in full disclosure, we actually kind of a quiet audience, so they weren't very vocal. But what little I did here is they seem very excited by K native and I think a lot of it was because we were just talking about that sort of merging of the worlds because I do think there is still some confusion around, as you said when you use one verse of the other and I think a native is helping to bring those together. And I did hear some excitement around that in terms of what people actually expect from us going in the future. I don't know. Be honest. They didn't actually say a whole lot there. I had my own personal opinion, and lot of years would already stayed in terms of emerging. Stop having me pick a technology or pick a terminology, right? Let me just pick the technology. It 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 Kaneda than anything else. Yesterday, >> I think like Lennox before it. Any technology? At some point you saw this with virtual ization with cloud, with containers with Cooper Netease. And now we're starting to Syria to see with server lists where some of its most vocal proponents are also the most obnoxious in that they're looking at this from a perspective of what's your problem? I'm not even going to listen to the answer. The absolution is filling favorite technology here. So to that end today, what workloads air not appropriate for surveillance in your mind? >> Um, >> so this is hardly an answer because I have the IBM Army running through my head because what's interesting is I do hear people talk about service is good for this and not this or you can date. It 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 time like he needed or any of the platform is whatever that platform actually finds you, too. So, for example, on eight of us, they may have time limited in terms of how long you can run. If that's a problem for you, don't use it to me. That's not an artifact of service. That's artifact of that particular choice of how the implement service with K native they don't have that problem. You could let it run forever if you want. So in terms of what workloads or good or bad, I honestly I don't have a good answer for that because I don't necessary by some of the the stories I'm hearing, I personally think, try to run everything you can through something like Cain native, and then when it fails, go someplace else is the same story had when containers first came around. They would say, You know when to use BMS vs 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. I don't want to try to pigeonhole something like surly or K native and say, Oh, don't even think about it for these things because it may actually worked just fine for you, right? 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 is being implementation details of specific providers and that that will dictate answers to that question. I don't want to sound like I'm coming after you, and that's very thoughtful of measured with >> thank you. That's the usual response back. So don't >> go. I'Ll give you the tough one critical guy had in Seattle. Okay, when I looked at K Native is there's a lot of civilised options out there yet, but when I talked to users, the number one out there is a ws Lambda, and number two is probably as your functions. And as of Seattle, neither of those was fully integrated. Since then, I talk to a little startup called Believers Trigger Mash, that that has made some connections between Lambda Ah, and a native. And there was an announcement a couple of weeks ago, Kedia or Keita? That's azure and some kind of future to get Teo K native. So it feels like it's a maturity thing. And, you know, what can you tell us about, you know, the big cloud guys on Felicia? Google's involved IBM Red Hat on and you know Oracle are involved in K Native. So where do those big cloud players? Right? >> So from my perspective, what I think Kenya has going for it over the others is one A lot of other guys do run on Cooper Netease. I feel like they're sort of like communities as well as everything else, like some of them can run. Incriminate is Dr anything else, and so they're not necessary, tightly integrated and leveraging the community's features the way Kay Native is doing. And I think that's a little bit unique right there. But the other thing that I think K native has going for it is the community around it? I think people were doing were noticing. Is that 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 this sort of bringing the community together and said, Look, can we stop bickering and develop a sort of common infrastructure? Like Who Burnett is is that we can all then base our surveillance platforms on, and I think that rallying cry to bring the community together across a common base is something a little bit unique for K native. When you compare it with the others, I think that's a big draw for people. Least from my perspective. I know it from IBM Zzzz Well, because community is a big thing for us, >> obviously. Okay, so will there be a bridge to those other cloud players soon as their road map? For that, >> we think a native itself. Yeah, I am not sure I can answer that one, because I'm not sure I 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 a native we do went from a serving perspective. I'm not sure I hold her old water. From that perspective, you have >> to be honest. All right, Well, Doug Davis, we're done for This one. Really appreciate all the updates there. And I definitely look forward, Teo, seeing the progress that the servant working group continues to do, so thank you so much. Thank you for having me. Alright for Corey Quinn. I'm stupid and will be back with more coverage here on the Cube. Thanks for watching.

>> Presenter: Live from Copenhagen, Denmark, it's the Cube. Covering Kubecon and CloudNativeCon Europe 2018. Brought to you by the Cloud Native Computing foundation, and it's ecosystem partners. >> Well, welcome back everyone, we're live here with the Cube in Copenhagen, Denmark, for KubeCon 2018 Europe, via the CFCF Cloud Native Computing foundation, part of the Linux foundation. I'm John Furrier, my co-host Lauren Cooney here this week. And up next to Yaron Haviv, the founder, and CTO of Iguazio, and Doug Davis, who is the co-chair of the serverless working group, And the CNCF, as well as a developer advocate for IBM, IBM cloud. Great to see you welcome to the Cube. >> Thank you. >> Thanks. >> Thanks for coming in. So love the serverless work, and want to dig into that with a bunch of questions. So, super important trend as we see in that success functions, and all the good stuff that's going on, programmable infrastructure. So I want to dig into that. But first, Yaron, I want to get into what's going on with the business, what's new with you? Iguazio, I saw you're on the sponsorship list here, you're doing a lot of work. You have some news as well. What's going on at KubeCon, Europe for you. >> Yeah, so we're expanding on the business side very nicely, taking more momentum, and this strength towards edge analytics, edge cloud, people starting to understand that central cloud is not the only way to build clouds. We're also progressing nicely on our serverless framework, called Nuclio. It just was published, maybe eight months ago, already made 2000 stars in GitHub, you know, users. We've got some quotes, NPR's around production version of that, including strong partnership with Acer, on being able to run the same functions in Acer, and the cloud in a joint development effort, as well as customers actually using it to build real-time analytics use case in development in the cloud, and deployment in different locations. >> Our audience knows you well, you've been on the cube many times. You also write for us, as well as other blogs with your opinion pieces and commentary. It's always edgy, and strong, and right on the money, I want to ask you your thoughts on serverless, because you were there from day one, I remember the conversation. It wasn't called serverless, we were talking about resource pools and looking at cloud computing, pontificating about, potentially, what Kubernetes and orchestration was going to look like. It's happening. So, are you happy with the progress of the industry, performance of the tech stack? What's your thoughts on serverless today, state of the union? What's your opinion? >> I think it's progressing nicely. I think many people call everything almost, serverless now. You have serverless data bases, you have serverless everything. I think serverless will become, more and more, a feature of a platform, not necessarily a thing. But, like Salesforce will have serverless functions, Wix will have serverless functions, for their own stuff. Obviously cloud platforms, analytic platforms, et cetera. So there'll be, maybe a family of generic ones, and a family of platform specific, that are more use case oriented. >> Does that connect with your business plan for Iguazio? Are you evolving with it? How are you navigating those waters on the adoption side. >> So, you know, I'm sort of trying to be inclusive, I think there's room for more than one serverless framework. There's also OpenWhisk, and Openfazzer, and a few of those. Our focus is mainly real-time analytics, and high performance in data processing. Yes, we can also do other things, but maybe we won't invest too much in some features that are more front-end oriented, or stuff like that. >> John: So you're staying focused on the core. >> Yes, on the other hand, other people to deal with front-end, we'll focus on HTTP, and Blue Logic, and things like that. Most of the frameworks don't have the same capabilities of Nuclio, like real-time stream distribution, real-time, low latencies, all that stuff. So, I think there's room for multiple frameworks, and that's also part of the relationship with Acer. Acer have their own product, which is very good with integration with the Acer stack, and the Acer components. On the other hand there is real-time analytics, in IOT Nuclio is stronger, So, there interest is, rather than saying, no we'll choose just one horse, why won't we enable the market, and allow the people the choice in solution. >> That's great. On IBM's side, Doug I want to get your thoughts on the working group, as well as IBM. You guys have done a lot of open source, IBM well known in the Linux history books, as we know. And now very active again, continuing that mission, congratulations, and thanks for doing that. But the serverless working group. This is a broader scope now, can you just give us some color on the commentary around how that's evolving, because you guys have a lot of blue chip customers. Cloud Foundry just did a survey, I was talking to Abby Kearns yesterday, about the results came back, mainstream tech, not middle of the country, but they heard about Kubenettis like, what's kubenettis? So you have people going, Okay, I've got a job to do, but now kubenettis has arrived, this is a key part of a micro-services focus. >> Right. Yeah, and so the way the serverless group got started was, about a year ago the CNCF TOC, technical oversight committee, decided serverless is kind of a new technology, we want to figure out what's going on in that space, and so they started up a working group. And our job wasn't to really decide what to do about it yet, it was to sort of give us the landscape of what's going on out there, what are people doing? What does serverless even mean, relative to function of the service, or even the other as's, and stuff like that What does a serverless framework generally look like? What do people use it for? Use cases, and stuff like that. And then at the end of that we produced a white paper with our results, as well as a landscape spreadsheet, to say all of the various technologies out there in that space, who's doing what. Without trying to pick winners, just saying what's there. And then we ended with a set of recommendations in terms of what possible next steps the CNCF could do in this space, with an eye towards interoperability building more than anything else, because that's what, really, we care about. We don't want vendor lock in and all the other good stuff. And so we had a set of recommendations, and one of the main ones was, two main things, one was function signatures was a very popular one, but we decided to focus on eventing first, because we thought that might be an easier fruit to pick off the tree first. And so we were going to focus on the formats, or meta data of an event, as it transfers between systems. And so from the service working group we create a cloud events, sort of little sub-group within our working group, to focus on creating a specification around what the meta-data around an event would look like, just so we can get some commonality. That way, at least the infrastructure between the two systems can transfer the events back and forth, much in the same way HTTP layer, doesn't have to understand the body of the message, but can look at common headers, and know how to route it properly. Same kind of thing with eventing. And again, this is all about trying to get interoperability, and portability for applications, and users more than anybody else. And so that's kind of where our focus has been on. How can we help the end user not get locked into one platform, not get locked into one solution, and make their life easier overall. >> Great. Where are you now with that? Is it running? Is it-- >> Overall done. No. >> Oh you're complete, yeah (laughs) >> Doug: But we did that last week. No, actually as of last week though, we just released our first version, 0.1. It's a very, very basic thing, and people might look at it and say, what's the big deal? But even with that simple little thing we've been able to get some level of interoperability between the various platforms. And if people actually join, when is it? Friday 11 o'clock? >> Yaron: Yeah. >> We have a session where someone's going to demonstrate interoperability between, oh gosh, IBM, you guys, Microsoft. >> Google. >> Dameware, Google. All the various companies involved in this thing. >> Love it, that's great. >> Huawei. >> Yeah. They're all going to be either sending or receiving events, using the cloud event format, to prove interoperability around the specification. So we're just at 0.1, we have some way to go, but that first step was huge just to get agreement, and everybody to the table to agree. So it's been really fun >> And it wasn't easy, it wasn't easy. And he's the peacemaker in the group. (laughs) I'm the troublemaker, he's the peacemaker. >> We have a lot of vocal people in the group, yes. (laughs) >> We're not pointing at anyone. >> No, never. >> Important first step obviously, commonality, and having some sort of standardization kind of thinking. >> Doug: Yes. >> Yaron: Don't use the standard word. There are people allergic to that. >> Well yeah, the standard bodies and what not, but in terms of the community work going on, this is super important. What's the impact of that? Obviously it's a small step, but a big step, right? So, what's it going to impact? What's next, what's coming next now that you've got the meta-data, and you've got the interoperability, what's next? >> Well, obviously we need to finish it up, because 0.1 is obviously just the first step. As I said, I think beyond that people are really itching to do function signatures. Because I think if you can get the event format coming in to be somewhat similar, and then you can get portability of moving your function from one platform to another, with hopefully minimal changes from a function signature point of view, you're a long way there towards getting portability for people. And I think that's probably the next step we're going to be looking at. >> What's the technical case from a commercial entity like yourself, who's in business to make money, obviously you have a business to run. As you build out your architecture, where is this going to be applied for you? What's the impact of this project to your product? >> So beyond my strong religion around open APIs, and you've seen the blogs I've written about it, our interest is twofold. First, we're not the market leader, Amazon is the market leader, et cetera. So if we have a better technology, and things are standard, it's easier for customers to move. Second, is we believe in interoperability, closer to the data, closer to where the processing, especially when 5G is going to evolve, and we're going to see bottlenecks between metro locations. Our sales is, go develop in the cloud, and then push it, you know the diesel twin model. This is exactly what we're demonstrating with Acer. You could develop at Acer, our Nuclio functions and deploy in a factory. So it may not be the same platform, it may not be the same serverless framework. So having the ability to run the same code in different frameworks or different platforms is very important. >> And IBM, you're doing a lot of work. OpenWhisk has been something that's gotten a lot of press and notoriety. What's up with you guys and open source? Obviously we see you guys out there doing a lot of studies and a lot content, a lot of coding. What's new over on the IBM side of the house with serverless? >> From my point of view, I think probably the biggest thing is, we're leading the charge in putting OpenWhisk to run on top of Kubernetes. And I think what's interesting about that is we're going to see, probably, some changes to Kubernetes need to be made to get the better performance that we need. Because when OpenWhisk runs vanilla on top of, say run C, or the docker stuff, we have a lot more freedom there. Pausing containers, stuff like that. Stuff you can't do in Kubernetes. We're probably going to see some more pressure on Kubernetes to add some more features, to get the kind of performance numbers we need going forward. >> And scale too, is important to understand. I was just talking about the keynotes earlier with another guest, and Cern is up there. They have a thousand nodes, it's not massive numbers yet, at scale, I mean Amazon are the big clouds, you guys have clouds. You've got a lot of nodes, so it's a lot more scale going on in the cloud as Kubernetes starts to get it's footing. >> Doug: Yep. >> How do you explain Kubernetes, how do both of you guys explain Kubernetes to the IT transformation group out there, that's going cloud operations. >> So what we've seen, because we're also selling an appliance, a full integrated solution, people, in the enterprise, they don't necessarily want to understand low level of Kubernetes. And actually serverless is a nice way for doing that. If you look at the new Nuclio dashboard, you just go, you write some code, you click deploy, it auto scales, you don't need to think about the underlying cube cut whole, the underlying networking. It's all done there for you. And I think, what you see in the trend in the industry, some people call it serverless, some people call it other things, is more and more abstractions, where users will deploy code, will deploy containers, and some frameworks underneath will deal with the high availability, elasticity, all that. I think that's what enterprise customers are looking for. Not everyone is eBay, and Google, and Netflix. >> John: Your thoughts? >> What I think is interesting, I agree with what you said, but I think it's interesting is you actually have a wider range of people, right. You have some people who think Kubernetes, as you said, nice abstraction layer, you don't have to get into the nitty gritty if you don't need to. But Kubernetes does allow you to get under the covers and twiddle those lower level bits if you actually need to. I think that's one of the things that. People who start out with Docker, they like it, it's so simple to use, and it's wonderful, and they love it. But they found it a little bit limiting, because it was too opinionated, or it didn't give you access to things under the covers. Kubernetes, I think, is trying to find that right balance between the two, and I think for the most part they kind of hit it. There's a little bit more of a learning, because it's not quite as user friendly as Docker is. But once you get over that learning hump, all the flexibility it gives you, people seem to really, really, like that. >> What are some of the things that people do under the covers, you mentioned some tweaks here and there. Is it policy based stuff? What's happening under the covers that Kubernetes getting that their groove swing on now. >> There is something called custom resource definition. So for example, when we deploy a Nulio, maybe OpenWhisk or others have it as well. It's essentially, Nuclio becomes another resource that you can actually view when you're running the Kubernetes CLI, or all the other things that manage it's liveliness, et cetera. So those are services that you get for free as a platform. But if you want your function to keep being alive you need to code your functions into the liveliness API, the thing that monitors it staying alive. So you're getting a generic service, but you need to work with it. >> Yeah, actually I'd go one step further with that and abstract it a little. Because obviously Kubernetes has a lot of knobs you can turn, a lot more than other platforms, like Docker has. But I think, for me the biggest benefit of Kubernetes is the plugability. Custom resource definitions, one of them. Ripping out schedulers, or whatever controllers you want, and replace it with your own. That kind of flexibility to say, I don't have to leave the entire Kubernetes world just to run my own scheduler, or write the infrastructure around it, I can plug in my own. That's the kind of flexibility people seem to really, really like. That way they don't feel locked in, they can still play with part of the ecosystem, but get the flexibility and customization they need. >> Awesome, great commentary there. I want to get your thoughts on KubeCon 2018 Europe, for CNCF. Continuing to see growth in CNCF, fantastic to see. As the boat gets full of people, you've got to be the peacemaker if you're co-chair. As people want to start getting their claws into the projects, this imbalance on the community side, are you guys happy with the direction, obviously the success, and the visibility is increased. What's your take on the show here? What are you guys doing? What's going on around the event for you guys. >> So it only started today, but my impression, comparing it with the previous show in the U.S. There are a lot more decision makers here. I don't know if it's the European culture of not funding every student to every show, or just the maturity of the ecosystem. But that's something I've noticed, the discussions I had with decision makers. and they're also not everyone, like in the U.S.A. everyone wants to build it their own way. People here think about operationalizing solutions, so sometimes you need to take something that someone else already built and test. >> And what's the conversations like, that you're having? Is it architecture? Is it deploying production workloads? >> So for us it's a lot about use cases, because we're doing things in a very different way. We're doing some nice demos on how, we're running real-time analytics with the sample database as the core, and we're showing how it's equivalent to another solution that they may build. And that immediately clicks. The other aspect is really, there is so much technology, but we need someone to wrap it up for us as a package solution. >> Doug, your thoughts. First of all I love your shirt, it says code with all the words in the community. >> Doug: Yeah, it's one of my favorite shirts. I like it. >> Love that shirt. I'm just looking at it like, all these questions are popping in my head. What's your plan at the show here? What's your goal, what are you guys doing, what conversations are you hearing in the hallways? >> Well, obviously being from IBM, we just promote IBM as much as we can. But beyond that, really talk about interoperability around what we're doing here, and make sure people understand that we're not here to necessarily sell our products, which we obviously want to do. We want to make sure that we do it in a way that gives people choice. And that's why we have the serverless working group, the cloud events spec. It's all about giving everybody the choice to move from one platform to another, to get their job done. As much as we want people to buy our stuff, if the customer isn't happy in getting what they need, then we're all going to lose. >> And these projects are super important to get the solidarity around these, quote, standards. >> And just to follow on your previous question about the conference, and stuff that we'd like. Obviously it's great that it's growing so much, but what I really like about this conference, beyond some other ones that I've seen is, a lot of the other ones tend to have more marketing flair to them. And obviously there's a little bit of that here, people are promoting their stuff, but I love the fact that most of the stuff that I'm doing here aren't in the sessions. Because the sessions are great and interesting, but it's the hallway chatter, and interacting with people face to face, and not just to meet them, to actually have real technical, deep discussion with them, here at the conference, because everybody's here you can do that much better face to face than you can over a Zoom call, or something else. The productivity from that level is just astronomical, I love it. >> Yeah, I totally agree. And one thing I would add, just my observation, interviews in the hallways, is that we're living, and we talk about this on the Cube all the time, a modern software architectures here. And it's got some visibility around it, it's not filled in yet, but I think there's clear visibility. Cloud, micro-service, interoperability, portability, pretty clear. And I think people are engaged, people are excited. So you have the progressive new guard coming in, on board. Great job. Thanks for coming on the cube, we appreciate that. >> Thank you. >> Thank you. >> Iguazio and IBM, here on the Cube, breaking down KubeCon 2018 Europe. More live coverage, stay with us, we'll be right back after this short break. (electronic music)