 Okay. So, welcome to CF versus Knative. I felt compelled to add this warning because obviously things are being recorded. So, this is not a scientific survey. I don't know if you expected that. It is not. It's not a not scientific survey. There was no surveying. Exactly. It's very opinionated. But I think it's an educated opinion. So, hopefully it will be worth your while. The other thing is we're using Knative beta code, obviously things can change. So, what we say here could actually change when you get home and you try it. And we're looking at high level features versus very detailed fine grain. So, keep that in mind. And of course, to make it fun, we have a score that we are keeping for each. So, it would be nice that exactly, keep the score in your mind, we'll reveal at the end. But it's very subjective. So, get started. Let's get started. Yeah. So, who is this guy? You. I thought I was just. No, you. Who are you? I'm Dr. Nick. I work for Stark and Wayne, which there are many people in blue suits, blue outfits, which is the poor way to introduce them because I'm not wearing the same outfit. I know. You're in red. The worst person ever. But I look more like that than I, you know, anyway, that's I look like that. And Stark and Wayne is a consultancy. We run clap boundary for you and we're pretty, pretty good at it. Yeah. And if you don't know this guy, he does so much coding. Oh, yeah. I have a GitHub account. That's right. Yeah. So, this is me. I'm not on my bike, but I wish I was. You promised to wear the outfit. And actually, after this, I'm actually going for cycling and spin. So, if you're interested that, you know, we can do this. But I work for IBM. You're not actually like, is the background real? Or are you just like on a. This is real. I was in a better shape to there. But I work for IBM and I do voice things for Cloud Foundry. So, how much, how much not better are you in shape? Oh, yeah. It's horrible. Let's not talk about that. That's quite a racket. So, the way we're going to do this is I will represent Cloud Foundry. And you will represent. Keynative. Keynative. What is Cloud Foundry? It is the thing that you've hopefully, by the middle of today, oh, this, really? Yes. This is some cut and paste text, whatever. It is the way in which we go through the whole cycle of looking after apps. So, new code, you go through the whole process, get it off your laptop as quickly as possible, get it into a place that will be in production because no one wants to have to hand their laptop over and plug it into the internet. That's not deployment. That's just an excuse. So, we want to get into the production and we want that same environment to be production ready. Yes. It's that entire experience. And it's the thing we all love. We're here for that, right? So, what is Keynative? We do Keyn just because to shorten the name, but it's really Keynative. And if you go to their website, you'll see that it's actually a platform built on top of Kubernetes that is targeted to serverless workloads. But the reality is you can do pretty much anything else with it in terms of the regular apps and so on. It has the word end in it. Every other word is buzzword bingo, just gold fodder. Look at that. How could you not win buzzword bingo in that sense? All right, so what's the methodology that we use? Let me give an idea of this. So, we decided the way we would compare versus sort of the very detail is to pick five high level use case that we think people are interested in, hopefully you are interested in those. And very quickly, the basic one is to create an app. Can you actually do that and how easy is that? So, that gets you warmed up. The next one is managing it. So, you want to create multiple revisions of that app. You want to be able to delete. You want to be able to scale it, to add woods to it and so on, right? So, basic lifecycle management. The routes. The routes, no woods, routes, okay. Woods, French, routing. All right, anyway, the third part is shit goes wrong. Right? Is that French? It is. That is technically French. So, yes. Is it low shit or low shit? So, how do you debug the shit? So, the debug, that's very important, right? So, how easy it is for you to actually fix things. So, we'll look into that. And then the third part is because your app is not going to live by itself, it needs to connect to some external service. So, how easy is it for you to connect to those services, manage that connection and so on. And then finally, part of the reason you're here for Cloud Foundry is, and certainly as a member of IBM, it's certainly important for us to take of enterprising features, you know. So, how easy it is for you to take that platform and map it to your enterprise needs. So, hopefully we represent a good class. To put it into French. Yes. Step one, the four is shits and giggles. Yes. And then step five is... The important stuff. Yeah, in some ways. But... That's French. This is what we decided to use. Obviously, your use cases will vary and so on. So, keep that in mind, right? So, what we're going to do is, we're going to take each one of those use cases, go into detail and look at how each does it and then we'll have some of them as demo just because we can't do all of it. So, go ahead. So, we're going to deploy an app which many of you will be aware is a thing that you want to do. And then we have the steps, build packs and we will quickly look at that both Cloud Foundry and Knative can do things in addition to building build packs, but we want to app. And just to give away a bit of a clue, Knative and Cloud Foundry can both do this. I mean, I don't want to spoil too many surprises if we go along, but it's not apples and oranges. They do have... So, show them. Show them. I'm just so nervous. I'm so nervous. I'm going to actually deploy an app at Cloud Foundry Summit. All right. Except I'm not, am I? Because we're going to save most time. Yeah, skip that. Skip the Cloud Foundry, get to the Knative. Nothing. All right. Do the Knative one. Get to the Knative. You may or may not be aware, you can both push code that's local to you. So whatever's local up it goes, whether it's uncompiled code or whether it's a WAFAL or a pre-compiled Docker image that's on a registry. And you can do both of those things. Environment variables, you're good to go. All right, Knative. Do you want to talk through it and I'll type? Yeah, yeah. So one of the things that Knative, you know, I guess is not quite ready, but it's getting there, is there's not a very good user experience. So Dimitri Canon from Pivotal and I last year started creating a CLI. And then now there's a whole SIG or on creating an official CLI. We're still using the old CLI plus some additional stuff that Dr. Nick did to show you how you deploy. So basically to deploy from a Docker image, you just say KNCTL, so that's a tool. You deploy, pass it a name, give it an image and then target, which is an environment variable. This app is gonna take that target and replace it to say hello, right? So you can see one of the things we also do is we show the log out of that when you are essentially doing the deployment. The other way to do this in Knative without using this tool or the official client when it's ready is to essentially do a bunch of YAMLs just like you do in Kubernetes and then use CUBE CTL to do your deployment. This tool just makes it easy for you, right? So one of the things KNative can do in addition to what you can see in Cloud Foundry or it's almost like it's basic functionality is it, so in this first one we just assumed it was already built. Obviously that's not for everyone. Can you take source code and build it? Yes, you can. KNative wants to do it from a Git repo. That example is sort of skipping when the second part we've sort of shown well there is a way to do it from your local source code like Cloud Foundry. But one thing KNative can do and I know I'm supposed to be the pro Cloud Foundry person and you're supposed to talk for the other thing is that you can give it your Git credentials and it will just build for a source code. And I actually like that feature because it's one of the things I've been complaining about what Cloud Foundry cannot do is Cloud Foundry loses all context where this code came from. You go back to an app and try to figure out how to stage it, refix it, redo anything. It's like all that information is lost. Yeah, and part of the reason we have this in KNative is similar to how a lot of parts of Kubernetes is very flexible. So in KNative there's a portion of it that's called a build where you can actually create different kinds. So one of them can actually go from essentially you can provide your own build but there's a bunch ready. One of them is to be able to build from source build packs. You can actually specify eventually the build packs that are there and it will identify your source code and build. Lots of different ways to build. If you have an interest and they're actually adding a whole bunch of stuff around pipelining. Yes, which is interesting. So let's see the score. Where are we now? This is the first use case, right? This is where I take an early lead. Yeah, move, yep. So the observations, I think we covered is that they're pretty much on par except KNative has a little bit more flexibility. Right, but we rounded up so that I wasn't losing straight away. All right, so you guys keep it in your head. So it's one to one. All right, managing. This is where I'll take a further lead. So we've got- Just give it away. You keep giving it away. There's no way we get to the end of this and Claire Fandrie doesn't. Come on, dude. Are we working backwards? What the hell? I mean, this is a live spread. If I find out that we get to the end and it's dubious- I might have changed it. If it's changed then- Keep going. No, I live in so much doubt now. You can introduce managing. Go for it. All right, so obviously we showed you you could push apps both ways both with Cloud Foundry and KNative. But can you do more? Can you obviously do the life cycle of apps? And especially today, for instance, they showed you how you can do revisions in Cloud Foundry or at least it's coming. What about in KNative? What about scaling? All of those features that you need to do when you're essentially putting apps in production. How does that work in both Cloud Foundry and KNative? And look, if any people- By the way, the people that have decided to stand, this is optional, there are seats. These people will let you in. You will, won't you? I'm not gonna look at them weirdly. So again, we do want to spend most time showing you KNative things because that's kind of probably contextually interesting. But this is the kind of commands we're talking about with Cloud Foundry, the ability to do your push and it goes through that build pack life cycle, mapping one or more routes or zero routes that contain that. People talk about, I get very frustrated, even the CF Summit's own survey talks about, do you have containers to run? It's like, yes, I do. And where do you want to run them? And all the options weren't Cloud Foundry. Like, I can run Cloud Foundry. I can run containers on CF, they are. Like, you could do anything you like. You don't have to have a route. Go for gold. Just don't do state, but then you probably shouldn't put state on Kubernetes anyway. So restarting, scaling, and this is where we can introduce a deviation of what KNative can do that Cloud Foundry cannot. And if you want to introduce that. Yeah, so one of the things is you see we have a star and a double star and it's to mention that first, when you do a push on an app that already exists, you don't have a revision of the app. You replace the existing one. However, today you saw Ui showing a feature that's up and coming where you'll be able to specify different revisions so you can go back and forth between them, right? So that's not quite ready, but it will be coming. The other thing is in the community in Cloud Foundry, we have an extension service called App Autoscaler. It's actually used various places at SAP, at IBM and so on, where you can actually use it to do auto scaling. And it's very flexible, you can auto scale up and down. So to be fair, those exist, but they are not built into Cloud Foundry immediately. And does scale to zero? I'm not sure, actually. That's a good question. Because KNative does do scale to zero. That's right. So in KNative, when you do a deploy against the version that we just did right now, it actually will create another revision. How do I look, I've forgotten how we look this. So you can do a service list, not pod. It's called Happy Hello. So we're looking at the pods for that, and you can see there are no pods right now because it actually scaled out. And unfortunately, we didn't show you that there were pods before. Right, but we can show you now. It's like the world's worst magic tricks. That's okay. Do another... Like, where's my rabbit? Magic, no, my rabbit ran away. Whereas... Well, let's fix that. All right, so do a deployment. I love... It's a changey environment. I love scale to zero because, you know, as someone who pays for stuff, I like to not pay for stuff I was using. So scale to zero is fantastic. But let's send some traffic. So without talking about how we're gonna set up routing, there is a little built-in command where even if you haven't got routing, it can sort of... And it takes a little bit of time, you'll see because it's... It basically locks out this curl command down the point there. And it's taking time because it's pinning it up. All right. I'll do it again. Yep. And we have pods now. That's very exciting. That's right. And then if we wait a bit, it will scale down. It's five minutes and it will start scaling up. And by the way, if you had... If you all did the same thing, then it would scale up. And it actually scales up to whatever number you have. I've never built an app that had that sort of traffic. No, you could... We discussed like putting a little bash where it just spin up. Yeah. We could do that. But for the purpose of time, let's move on. The other thing, actually go back here. The other thing you can do also, which we're not showing you here because it takes a little bit of time and we have a lot to cover, is you can actually split the traffic pretty straightforward in Knative where when you have multiple revisions, it keeps track of them. Oh, there you go. We can say I want some percentage in this particular... Oh, that's right. Because we're going to do another... We're going to build another deploy, won't we? So if we do CTL, revision, lists, the minus S is service. What we call an app in sort of Knative and Knative's world is called a service. And so there is our one revision. If we go and do our deploy again... And change the environment? Yeah, sure. That's fine. Okay, it doesn't care. So now you can see revision two? This is a revision. Exactly. Because it's only... It's going to say hello to me again. You're not going to know, but we could have changed it so that the second revision now will have a different, essentially source code. And so once this finishes, is we say our revision and you can see that the route has switched over. Exactly. Which is what you would expect to expect it to work. Whilst the CNC tool itself right now does have some of the flexible routing features, what's important, and it's hidden by the cloud native Cuddle CLI, is that all of this in Knative is just, is the custom resource definitions. So we could be doing a lot of this by using the Cuddle command. And what that also means is that a lot of this functionality isn't Knative, it's Istio, which you may learn more and more about as coming into Cloud Foundry. And so a lot of these features are just playing with Istio. And you can do a lot of things by jumping down from this CLI and just configuring Istio to do all sorts of interesting routing. So there's a lot of flexibility in what you might like to do. Yeah, so let's see the score now. Managing results. So the observations are... Why did you do this? Oh, sorry, no, don't look. All right, well, so I think it's fair to say that Knative has a heads up here, right? It comes built in with scale to zero, scaling up and down is very straightforward. Certainly in Cloud Foundry, there are some of that support that's coming, but it's not there yet. Yeah, the only negative I can think is that the spitting up of pods does take some seconds. Yeah, so... We got a guy working on this to fix it. So we agreed against my wishes to do a half point for Cloud Foundry, even though obviously there's lots of features and... All right, moving on to the next one. Bullshit. All right, so the next thing is the thing that hopefully you don't have to do, but guess what? You pretty much know you're gonna need... No, I had to do some research on what debugging was. I've only been coding for 20 years. Exactly, you never had to do it, but you're the exception. So things fail, how do you access the logs of them? How do you don't have to SSH it to them, but sometimes you have to do that, right? So how easy it is to do some of this work? And then Cloud Foundry is pretty straightforward. Well, these are our tools, and this is fantastic. I mean, imagine having to go find containers and like so nonsense. So we have two log commands in a way. You can have logs where it's all future logs or you can have the logs command where it's a subset of recent, not a subset, it's just some, but like a recent chunk of logs. If anyone on the CF CLI team is here, I beg you, please, when we don't ask for recent, give me some recent logs anyway. Very rarely do you say, I don't want all new logs. Don't show me old logs. Who has got that problem? Get me some old logs and then show me all new logs. And then we have CFSSH, which if you've never seen, I do have some app, an app pre-deployed. I know we skipped that a little bit, but here's my little go app. You can see it logs, in you go. You can also run a command, bit of one off, I think one off stuff. And this is nice for looking at how configuration files might have turned out. Perhaps you can run some things internally. For the sake of the video, I don't expect any of you to type this down, but we do have our old blog post. Why is this not working faster? Oh, because I ran the wrong command, I'm super sorry. That's why I kind of SSH in. Oh, and then you're there. You can NS. Is SSH pro. There's this command and another thing, I think everyone just moved on. But when you jump into an SSH session, it isn't quite the same environment that you think it would be. It's like the environment before it becomes your node app or your go app or whatever. So this little command, there's blog posts explaining this, but now it's a go environment, et cetera. And you're inside your app and you can look at log files. You can try to run commands that failed and that's debugging. Are you plugging your tools? No, I would never. There is a blog post, but I would never come up with temp slash life cycle slash launcher. That's it. All right, very good. All right, so now let's switch to Knative. We just make it work, wouldn't you? Sure, sure, sure. Let's switch to Knative, which is unfortunately a little bit harder to do. But you can list your services logs. So logs are pretty straightforward. So let's do that. So let's clear this out. So can there's services? Service list. Service list. And this is a pattern, the command and various things. You can sort of, things are not in a happy condition right now. Because they're scaling down. Because they're scaling down, they're sort of unloved. If we were to give them a little bit of curl action. Yep. Back to that, although. Do the listing, I know. Happy and healthy again? So again, the scale up and scale down automatically, right? Knative. Oops, it can't. And then we can logs. So can CTL logs, yep. And you can follow the log in the tool, right? So if you use curl in a different window, then we should be able to see it. So when it hits it, we'll see an entry, right? Who doesn't love computers? So that's kind of nice. And then in order to actually SSH, what you're doing is you're looking at first, let me find a pod that the service is actually running on. Because when it scales down, the pod will disappear. So you need to find the current pod. Once you have that pod, then you can with cube control, exec, SH, and get into that pod. So, I guess pod list, yep. Oh, you already did that, cool. Similar to sort of the Docker exec. And then you're there, and you can LS. So you mean, now we're in the source code, right? And there's that little process running along. Perfect. Good times, good times. Okay, so let's see the results, because we were running out of time. We gotta get to the next thing. So what do you guys think? Ah, you give it away, all right. So it's about the same, right? It's not like it says, don't go yet. You just let me do this. It's okay, it's okay, it's okay. But never actually done the polish. It's about the same, all right, cool. So let's move on to the number four. Okay, so this is one where, you know, if you've been into Cloud Foundry for a long time, one of the things. We are borrowing Cloud Foundry's language here. Yeah, yeah, it's a shining jewel of Cloud Foundry. Databases, things that you get from someone else. Someone, you know, this is, I think one of Cloud Foundry's great distinctions. Absolutely. Is saying, you do apps, don't do state. You're not very good at it. That is true. You've learned node. You don't know how to look after state, all right? So we'll get some other people to do state. Never let anyone that you know run app, get install, MySQL, Helm install MySQL, Docker run MySQL. Don't do any of those things. The Helm chart for MySQL does not have the word backup in it. So it says a little quick indicator of what they think about data. So anyway, services. No, exactly, yeah, and let's show how you do that in Cloud Foundry. It's beautiful. We have a few ways. Do you want me to do it? Yeah, go for it. Yeah, yeah, you do it. You've probably seen halfway down, you would have seen the marketplace and the create service thing. But just to remember, you also have what I call the Post-it node system of where someone else says, here's your database. And you can do it with setting environment variables or the cups create user provided service method that's all then with a service broker. And so you have these three main different ways. You have the other one, which is not recommended, which is where you put it all in a config file and push it. You could do that as well, but then that is not preferred. See ya. And behind all of this is our open service broker API concept. So these requests create service, bind service are going off from the Cloud Controller, off to a broker, and it's going off and doing something possibly provisioning infrastructure, definitely setting up backups. And if not, you should do backups. Backups are great. You'll love backups the moment you want them. They're like insurance. All right, so we move to Knative. This portion to do it live is a bit tedious and long, but hopefully you all have seen this. In Knative, it's, we don't have support. We're skipping the how to get services that we go through the how to use them part. That's right, that's right. So in Knative, assuming you had your service created and exposed, maybe even with Cloud Foundry, you can actually with KNC-TL access it by essentially using the M-secret. So this command where you deploy the service or revision and you pass an M-secret will actually include that as a config map for your app and then you'll be able to access it within the app. So it creates an environment variable for you to access so you can access your services that way and so on. I will quickly introduce it. That's one way to do it. If you're going into the Kubernetes world, I will quickly introduce you to the service catalog project, which is where you're in Kubernetes and you have this idea of I want services just like we do in Cloud Foundry. I want them not necessarily helm installing things on my cluster. That's not what exactly we need. I just need someone else to be responsible. That abstraction of concerns, they have that. There's also the concept of operators and this example is me, I have a broker that goes off to CF and uses someone else. So there's a talk tomorrow where if you're interested in how your Kubernetes can just go and borrow all your brokers from your Cloud Foundry, there's a tool for that and that's just a quick demo where all the credentials just come back into your pods. Yeah, and then back to this. So then we do it as an environment variable. All right, so let's see the observation and the score. So obviously that came from Cloud Foundry and Knative doesn't know anything about it, but you can still use them to service catalog and I guess environment variable. So, but it's all good. Okay, so Cloud Foundry now has a half point ahead. So that's good. Okay, now we get to the last- This is surprising. There's some enterprises. I know, I know. So this may be the most controversial one except I think it's pretty straightforward in the sense that if you're here, you'll probably form a small, big enterprise and you wanna deal with the things that enterprise deal with. So you wanna be able to deal with access control, manage your users and your groups and divide maybe your apps into your organization, make it reflect your organization and so on and isolate them to each other, right? So if you think of these as enterprising feature, what are the supports in Cloud Foundry versus what you have in Knative, so. So for the orgs and spaces, if you're not familiar or you've never really thought about why I have it orgs, two primary things orgs give you is who's gonna pay for it? That's the- Who's using resources? Or orgs are for, someone's gonna pay for it. You also get resource quotas about how not to spend too much and domains. So if you've got an outside domain, Stark and Wayne, IBM.com, I trust that IBM.com is pointing at a Cloud Foundry, a blue mix, I'm sure. That'd be where you put all your stuff. Keep doing it. That's at the org level. And then of course you can have shared domains. And then pushing Cloud Foundry at an enterprising level and look, there's a whole conference that you should go to today. You should have done that. And about all the enterprising stuff that we do in Cloud Foundry. We spent so much money and time and energy on our secrets rotations. The whole Bosch deployment ownership of life cycle, container kind of networking and isolation segments of two others that we- Yeah, those are all the features that come built in with Cloud Foundry to help you with this. It is tedious when you hear people sort of compare Cloud Foundry and things just wistfully compare them. As if to say that these things we've spent, you know. So what do you have? Amounts of time. No, I'm not going to stop. This stuff is important. You have one thing and we shouldn't even be doing this talk. This is, you can't do any of this stuff. Well, we have namespaces. Come on. Chicken giggles was the first part. Oh, you've got namespaces. Yeah. Woo. And you want to use these two in there. You can just access them. Going home. What was it? Coop control. Right. I'll teach you a nervous stupid- No. My space, my space. My namespace. And then now you can actually- I'm furious. I'm furious on the inside. So one of the things we didn't show you is every time you did your KNCTL deploy, we are using the default namespace because we're going to specify it. So one thing you can do is you can say minus n and then specify any namespace in your cluster and we'll put those apps in that namespace. So that way- I can see why I shouldn't have called it my app. That was dumb. I mean, calling it my space doesn't make it any better. Well, it already exists, right, sir? I know it died and then got revived. Et cetera, et cetera and all that other stuff. Exactly. And then now you can specify that namespace and it will segment them and so on. All right. But you're still dealing with one cluster, right? So you're not dealing with different servers. It's not isolated from that perspective. If in doubt, make another Kubernetes cluster. Yes. To be fair, the community there is working on trying to figure out how to allow you to do federated clusters, to make it a little bit easier to divide them, isolate them and so on. But it's not there at least at this point, I think. Cool. And then the Istio stuff, so if you want to have public apps versus private apps and then you'd go into the Istio. You can do a lot of that work, but you have to do it yourself. So in KNATIVE, it's not yet exposed. Doesn't mean it won't be exposed soon, but it's not at this point. So the results are in Cloud Foundry, there's definitely a lot more enterprise features in mind because it gives you first class access to those. And KNATIVE is not so much in that space, right? But you have very powerful ways of creating namespaces and labels and how you can divide your work to make it map what you need. Oh, that hurts. I haven't made a keeping track of my head. Yeah, I know. I haven't. I don't know if I'll ever keep it right here. So who wins? Woo! So based on our subjective view, at this point, we rank it this way. A winner? Fair enough, fair enough, fair enough. All right, let's conclude and see if we have some questions. Don't worry about it. All right, get to the conclusion. But that was it, wasn't it? No, there was one more site. Okay, so I think the key here is that one is mature, one is not. So in some ways, it's not a fair comparison. But yours? Because Cloud Foundry has had years to get to where it is right now, right? Whereas KNATIVE is less than a year old and if you go to the repo, it's still not ready. But the important thing is if you're all here because you like Cloud Foundry, in less than a year, here's this brand new pass that is really cool features getting very close to matching everything we have. So this is not to say it's a fight, but we can replace any other day. It's something else, right? The same build pack system, you can use that. It's same networking, the premise, you've got my traffic coming in, service on the back end, I got revisions. And it's on top of Kubernetes, which is super hot. Oh, straight to the LinkedIn profile. I mean, this stuff's great for LinkedIn. I mean, don't forget the buzzwords. Why we got all your meaning links, obviously you're not gonna click those now because that would involve you touching my laptop, which would be weird. Exactly, so we got a bunch of links. We had a couple blog posts on KNCTL, if you're interested. I think Dr. Nick had a few blog posts as well. And he has this... Yeah, I asked you, we did like, because I was interested to see how similar it was and there are like six or so blog posts in a row that go through that deploy an app. How do you do build? How do you do services and secrets and things? So check this out. And then let's see if you have any questions. There we go. We wanted to make sure we have questions. Yes, please. Lots of questions. That's a boring question, next question. No, it's not, it's not more mature than that. But I think at this point, part of what's gonna happen, you'll see, and I don't wanna make future predictions, but you'll see companies taking what is available in the community and repackaging it. And as part of those repackaging, probably adding some of those enterprise features and security as well. I mean, it's an interesting, the repackaging is interesting because there are other projects like RIF and what's IBM's? Open WISC. And there are others where as top level projects, they are built upon Knative. Knative is like, you've heard sort of Kubernetes referred to as a platform for building platforms. This is more of that. Obviously we've shown you can use Knative directly, but in part it was designed to be allowed these higher order functions. All right, any other questions? Boring or not, that's good. Come on, Jules, you have a question. No, okay. All right, so it's not out of Dr. Jules's perspective that future version of what is Cloud Foundry might use the parts of Knative. So what you're saying is there's gonna be paths on top of fires, on top of fires, on top of fires, on top of fires. All the way? It's a long question. Yeah. On the use of words and for the people watching who are not here, Dr. Jules says some really interesting things and you missed it. And... Any other questions? So one of the things this project is, if we go back to the definition, they call it the buzzword bingo slide. They talk about it as called serverless. Yes. And I think that has the word functions, but certainly the people that make it talk about functions a lot. And I think one thing we've proven or demonstrated is what the hell are they talking about? This looks just like a platform. I feel like they're using these words just to try to pick up a new wave and new language, but it's just... It scales down to zero, buddy. It goes to zero. That's what makes serverless? Yes. What, when you can just pack up the whole thing and go home? Any final questions or comment? Yes. For my VM, by the way, stand up. Yeah, good. Contributor and so many things, including Diego and Irini and so on. Yeah, please. You don't like to pull things? Are people at home? He never said this sort of the similar topic of whether or not we do want to keep replacing layers or whether we should own the entire stack versus Delft deferred other ecosystems. I have an opinion on this, but let's see. Oh, yeah, please. Or you can do both. Yes, that's true. Why do you have to eat or war? Maybe you do a little bit of both, right? Did you want to say something, Jules? Then Jules said nothing interesting. He didn't say anything interesting. Look, we brought in Istio. We brought in Istio. They're redoing the whole built thing and collaboration with other people. I think the way to look at it is from an economic point of view also, right? It costs money to build stuff and it costs money to have code and to own code. If you talk to Rob Me from Pivotal, one of the things he tells me all the time, I have too much code. I'm rich in code and that's a very true statement, right? And it's a very expensive statement because when you have a lot of code, so how can we reduce that so we can reuse other things? But let's see, there's a question in the back. Maybe the last one, yes, please. That's true. Yeah, it's more cost efficient. Thank you for this. Thank you everybody for joining. Appreciate it. Thank you, buddy.