 Okay, can you hear me? I've got some noise here. Okay, cool. All right, so we're going to get started now. And I'd like to thank everyone who's joining us today. So welcome to today's CNCIP webinar, SMP Experience Report, the multi-cloud serverless on Knative. So my name is Daniel. I'm working for Red Hat as a technical marketing major, but also I'm responsible CNCIP investor. So luckily, I will be modeling today's webinar. So we'd like to welcome our awesome presenter, Yvonne Anderson, a software engineer and VMMer and Mark Wang, head of cloud engineering and SMP global ratings. There are a few couple of things of housekeeping items before we get started. So during the webinar, you are not able to talk as an attendee. So but there's a Q&A box at the bottom of your screen. So please feel free to drop your question in there and we will get to as many as we can at the end. This is an official webinar of CNCIP. So please, and this is a subject to CNCIP code of conduct. So please do not add any anything of the chat or question box would be violation of the code of conduct. So please be respectful for all of your fellow participants and presenters. Please also note that the recording and slides that will be posted later at the CNCIP webinar page www.cncip.io slash webinar. And with that, I will hand it over to Yvonne and Mark. Take it away. Hi. So as I was introduced, I'm Evan Anderson from VMware and I'm one of the TOC members on the K-Native project and I've been working for the last couple of years. And we recently had an opportunity to work with Mark at S&P Global on actually rolling out an implementation of K-Native. And so I'm going to let Mark introduce himself a little bit. Thank you, Daniel and Evan. Good afternoon. Good evening, everyone. So my name is Mark Wong. I have the privilege to run cloud engineering at S&P Global Ratings. So like Evan introduced, so we have a current existing relationship with VMware. And once we selected the technology of K-Native for a multi-cloud serverless implementation, then we started working with Evan and the team. It's been a great collaboration and our goal today is to share our experience on this journey. And the talk to me, it sounds like it's almost like 100 level. So I'll go through some 100 level and then 200 level developer experience and Evan's going to get down to the nitty-gritty details of 300 level content. So Evan, anything before we start? Oh, I was just going to say that, you know, when we started this a couple of years ago, it was, you know, kind of a dream that, hey, all the pieces were coming into place, that you could actually run a serverless solution on your own infrastructure without having to build all of the pieces yourself so you didn't need to build your own schedule or Kubernetes had one of those. And so it's exciting to see companies like S&P actually taking that last step of not just having the software, but actually having a platform that they can build and customize to their own needs. And it's been great working with them to be able to get that to happen. So yeah, I'm going to let Mark talk a little bit about how things actually, you know, how S&P actually decided to do a serverless platform. Right, so when you think of serverless technology, right, some of the basic things come to mind, one is you don't have to manage infrastructure. It's the speed to market, right. And cost is another, you know, because of compute density, right, so you're not using machines, you're using everything packed into containers, and even functions, right. So why do we go to a function of the service. To me, the biggest benefit is we can ship software faster, right. So I'll go through more of our background in terms of our technology portfolio. But if we look at the overall goal right so why do we want to adopt that as function of the serverless function at the service or serverless technology right is to ship our products faster. So we want to move from monthly quarterly releases to weekly or daily releases, right, so release frequently so that's one of the benefits from serverless technology, which is that teams from teams can focus on the business logic and not worry about infrastructure worry about coding standards worry about vulnerabilities. A lot of those will be taken care of I'll show a little bit more about that. And then the other thing is that they can own more of their staff right so they don't have to depend on this team or that team. So the automation and the pipeline will take care of a lot of that. So they have to see ICD experience right they can release code, as soon as they're ready to any environment they would like. And the other benefit is that after we break down the monolith and go more and more functions. We want to take out more key capabilities, then we end up retiring our legacy monolithic applications. So less technology that worry about. And one of the things in our journey that we found is that as we moved along. You know, Knative is a new technology even Kubernetes and new technology for us. So for us to have this global fads initiative we really needed to transform our culture. One of the things we noticed as we moved along is that we partner with the application developers, because the subject matter expertise for Python for dot net for angular. And for other technologies resides with application teams right. So these we have an open kind of development open collaboration model, where the engineers can contribute to the platform. I'll show you more detail about that. And then when they contribute they kind of unblock themselves as well. It's almost like a kind of win win situation they're building shared features on the platform, meanwhile they're unblocking themselves, and they're enabling their peers to do more on the platform. So if we go to the next slide. Okay. So this is a background. So 2020 one of our five strategic initiatives is to be certified on function of the service. So if you look at our portfolio two years ago, where majority is on prem. And then last year over a period of nine month or a month we migrated 100% to the cloud that migration was kind of a learning experience and the culture change in itself. If you think about our company right SNP is a financial trusted financial institution in the world, right globally. So we've been around for 160 years. And today we're moving at the speed of fintech. So last year, 2019, by mid 2019, over a period of a month, we have migrated 100% to the cloud. And today we're benefiting from that right with COVID with remote working, we enjoy stability and freedom in the cloud right. So what is our next leap so the team gained a lot of confidence from this experience to move to the cloud, and just a little bit more background on that right While we're doing the move migration mass migration to the cloud, we went through in sourcing as well as agile transformation. So there's a lot going on culturally, but what clear leadership and dedication of our teams, as well as ingenuity from our engineers. So a lot of people don't know the cloud at that time right when we started the journey on the project there was just one and half cloud engineers. And I myself as half of the engineer. So we slowly built up the team internally, we didn't really get much help from outside, other than we partner with VMware to use a VMC solution for some of the VM workloads. So we took. So after that experience we get a lot of confidence. And then we go into 2020 we said, let's take a leap and go all the way to function as a service. So if we go to the next slide. Let's take a little bit of that journey. In terms of the roadmap right. So, we did a market research on what are our options to go to function the service lambda is the first one comes to mind right, and then Azure functions. So we evaluated those as well as other open source solutions besides K-native. And then we came up, came to the conclusion that K-native really gives us a cloud independence and the multi cloud capability that we want. And there's a lot of smart engineers like Evan that, you know, backup the active community behind K-native. Towards the beginning of this year we started experimenting K-native. So if you look at the first swim lane. So we experimented with K-native. And then by and the Q1 in partnership with Evan and team. We were able to release our first version of function as a service platform. And then we were able to release a handful of applications to the cloud to production. And the other, the third swim lane is really around adoption, right. So, regarding that benefit we talked about earlier that goal of shipping product faster, right. So for us to be able to ship product faster we need mass adoption. So we came up with a concept of certification, right. So the certification really is to measure the maturity of application teams. So bronze is a goal for 2020. It's really to make sure teams know how to do function as a service using K-native. And then they understand how to scale up and scale down. So we have certification meetings we make sure the teams are certified. And they understand what is their roadmap, how can they break capabilities out of the monolith to put into serverless. So if you think about it, silver really is to break out more high value capabilities out of the monolith and put it on to K-native, right. And then when we get to gold, we will have a consolidated portfolio of capabilities. And we will also retire bunch of duplications and monolithic applications at that time when we reach gold will be completely on function of the service using K-native. And let's go on to the next slide. So this is kind of a release view of the platform itself. So we majority of the responsibility of my team is to enable the application teams and strong teams to be able to onboard their use cases. Like I talked about earlier we really opened it up we had nine work streams, engineers from different areas or we're helping collaborating and moving this thing along. So in a month we'll have a platform release. So MVP one was that we have a base platform and so we have Kubernetes, we have K-native, we have Istio, we have Azure DevOps for CI CD. And then we have a set of pilot applications. So that was able to go live. And then we also define this model to collaborate with engineers from different groups. So 2.0 was released in Q2. At that time we have 24 by 7 support, and then we have introduced OIDC as a standard for authentication. We have logging, monitoring, onboarding automation as well. I'll show you some of that in the demo. And we have CI CD pipeline automation. So at this time we open it up by 2.0 Q2 we open it up for mass adoption. And we introduce the reference implementations. I'll show you a little bit of that in the demo as well. And in Q3 we are going through more maturity. So now we have K-native function as a service running in DMZ. So we have external phasing application that's using this capability now. And then we have distributed tracing and we're using spot instance for all of our clusters. And we also introduce containers, right? Container as a service because not everything can go to K-native, right? We have commercial off the shelf products that we don't manage the code for. And we also introduce container security. For us to go to DMZ we want to make sure our images, our runtime is secured. We can go to the next slide. Alright, so some highlights on the features. So we support currently these languages for our developers, Java.net, Python and Angular. And then for eventing we support Kafka as well as active MQ. And for security we have Twistlock. We have open policy agent and fortifies for our static code analysis. And then on observability side we have logging. So one of the things is the developers for productivity, right? They don't have to worry about logging into anything. There's obviously no machines. They don't have to care about where the container runs. They have full visibility with logging and monitoring. And we added distributed tracing as well with open telemetry. And like I said, we're using spot instances. I think one thing I want to highlight here, maybe in a later slide as we do blue-green cluster automation. So we'll go to the next slide and we'll talk about that. Yeah, so some of the major components, right, is we're using EKS currently Amazon. And this technology is completely portable on other cloud providers as well, right? We're currently using Alibaba and as well as we're going to start using Azure. So because it's built on Kubernetes and because Knative is built on Kubernetes, all these will be portable as well. And we're using a lot of automation, right? Like I talked about blue-green. So every month when we release, we will build a whole new color cluster, right, from dev all the way onward. The reason why we do that is we want to make sure everything is automated. And we want to also make sure we respond to the changes in the base underlying Knative and Istio features very quickly, right? Because the technology is changing very quickly. We want to be up to date with the underlying technology. Yeah, we can go to the next slide. Yeah, so this is a kind of a quick view for our developer experience. So we have local environment capabilities. So if developer wants to set up local developer experience with building the image locally and running the image locally, they can do that. And we also have pipeline with standards built built in and automation built in as well. So once they go through the pipeline, let's say they deploy the code to dev, then immediately that is the image is shipped to our Artifactory image repository. And then it's put into Kubernetes through Knative and accesses to Istio. So why don't we jump to the demo? So I'll give you a look at this. Let me share my screen. Can you guys see my screen? Yes. All right. So we want this to be a self-service as possible, right? So this is the view of our documentation. So we have a getting started guide that Scrum teams can come in and use it to get onboarded, help themselves with CICD, secret manager, and then we set up a meeting with them in 30 minutes they can get going. And we cut down our onboarding time from when we started in the MVP one that took like a week for a team to onboard a function. So now it takes about two hours. So I'll show you a little bit of that experience. So part of it is not all two hours. What was that? Not all two hours. No, no, no, no, no. I'll make it quick. It's going to be much less than two hours. So it starts with documentation and the onboarding automation I talked about so in Jenkins, right? So based on the different types of reference implementation. So for example, if you're a Java application, we'll create this template. So fill in all the details that you need. And then once you run it, we're going to build the reference implementation. So the reference implementation has the best practices and the standards built in. So once we run through this pipeline, it's going to create that reference implementation into a template for you. And I executed this for our demo here. So for example, I have a demo repository called demo mark rest. So it's a RESTful function and it's a Java function, right? So we have code reviewers, we have other team members and we have secret manager defined here. So after we run this, what it will do is it's going to create a reference implementation here. So if you look at this, this comes sort of out of the box, right? So you have a reference implementation, you know, all the monitoring the log and the documentation comes out of the box as well. So all you have to do then is to cut and paste your code into it. I'll go through a couple of the components of this, right? So since this is a Java function, we have a POM file. So POM file defines your dependencies for Java, right? And then we have a Docker file. These all come out of the box. And then you see this Docker file has my function name built into it. And then we use a base image for Java, for example, and then we use other base images for different reference implementations. And we then have a pipeline file. So this pipeline file is important because we use ADO, Azure DevOps, and this defines what goes into the pipeline. So for this pipeline, for example, I turned off the fortify, right? Because we don't want to run this for like 10 minutes because fortify is going to scan the code. And I turned off a couple of other things in here as well. For example, you can all these things are configurable. So you can turn these on and off. So for example, I turned off some of the QA automation. So you can have CI, CD and CT built into this, right? And as part of the certification, we make sure that you have code coverage, you have continuous testing as well as well as, you know, sanity test, smoke test, regression testing. So these are all configurable. We can turn on and off. For this demo, I turned on the observability. So I want to kind of show you that. And the other important file is service YAML. So this is the K-native file. So in here, developers have full control over what is their minimal number of instances they want to run, maximal number. As part of the certification, the teams have to demonstrate that they understand all these underlying technology. So each team is required to test their performance. So one team came in to the certification and they low tested, they performance tested their current usage up to 150%, 150 times the current usage. So for example, they had like 20 concurrent users. So they tested up to 300 or 3000 users, right? So their pot scaled up to 10. And then when they realize that they really don't need 10 pause maximum. So they set it back to four or two or three pause to support their typical load of 20. But they have full control over this. And then the other thing I want to show is that going back to the pipeline. So they have full control over here, I just stopped at QA. They have control over deployment all the way to production DR, DMZ and so on. And for the demo purposes, I'm just going to make, oh yeah. So these are the application config files that we can manage. For demo purposes, I have this sample function is a ping pong method. And then there's also a method to pull out some sample ratings. And what I'll do is I'm going to change the code here to, let's see, I will change the code here to, let's say CNCF ping pong. So imagine this is what the developers will go through to change the code or even put the code in the first time. And as part of the pipeline, it's gated release, right? We want to make sure that your release ties to a story, right? So we are continuously delivering value, right? So then they will commit the code and then they'll do a pull request. So even within the pull request, so I will check into the October release. In here, we are sure that you must have code reviewers, right? So this is another gate that you must go through. And I'm just going to, you know, for, I don't want Evan, no, Evan can't do it. I don't need anybody else to approve the code. So I'm going to approve it myself. And then we'll set the automation to build the pipeline here. So that's going to kick off the pipelines there. So we can go in and take a look at this. So the pipeline, what it does is it's going to start with a snapshot build. So you can see all the outputs of these. So we do a snapshot build first is to ensure that the container image will actually build, right? The Java code will build, because if that fails, there's no point to pulling anything into it to canate it. So we'll just fail it right away. So here we're doing a snapshot build. So it's going to do a Maven release. It's going to do a Docker build as well. And your developers don't need to figure out how to set this up, right? This is just from a template that's already published. And they can go in and adjust it later if they need to. But they don't, but just to get started, you've published templates. That's right. If you see this parameter in the template, so all of these are part of that initial automation that would create the reference implementation. This is for Java. And then all of that comes out of the box. So you see this is all based on a template. So it's GitOps, right? So they use template out of the box, and they can control all these different parameters within it for their pipeline. Good point, Evan. So in this case, the snapshot build is successful. And after that, it's going to run a build to deploy to dev environment. And you have certain controls, right? This is one I did earlier. So for example, you can, we don't need to deploy to QA, right? So we can just reject it. So QA has a manual step where somebody has to approve it. You know, they have to make sure that you have enough code coverage. QA will accept that build. So in that case, for my demo, I just stopped that. So for here, we're doing a build and deploy to our dev environment. So remember, we have this configuration here that for dev, it's going to do a very simple, right? For a time sake, we're just going to do a build. And we're going to take that image and deploy it into QA that into the dev environment. Oh yeah. And then here, here's that dev environment. So I'm going to watch that. So it is currently running. And this thing is going to show us that it will deploy the new one. Right. So it's, this is running currently in our dev environment. All this is running. Do you want to show any of the instrumentation or logging? Oh yes. You get out of the box. That's a good point. So for the instrumentation, every function that we release out of the box is a monitoring, right? So you can have health monitoring of your function. So remember I talked about blue green. So this dashboard shows you what color we are, right? Because we don't want developers to be confused going to the wrong cluster. And typically we once we deploy one cluster, we shut down the other cluster so they won't get confused. So you have the developers have full visibility into the health of these, the clusters and their functions, right? You can have, you can look at different namespaces, different functions. So full visibility out of the box. You don't have to, you know, care or, I mean, depending on how much you want to care, right? You just worry about the code. You don't have to care about how any of this stuff works. So we simplify it for you. But if you want to dig into the log, right? For example, this is that function. You have full visibility into the log. You can drill into it to see the log. And then the other thing is that out of the box, we have alerts enabled, right? You don't have to do anything. So this is the container health alert. This is log monitoring. So if you have errors, beta errors in the log, you will receive alert. Because in the onboarding, remember, you have to pull in your contact information. And so that we use that and I set up an alert for you. And then this is more of a native related alerts. And if we go back to this, so the build is done. What happens is after the Docker build, we will publish the artifact into Artifactory. And that is used for the deployment into the Dev environment. You use the same artifact for deploying to both Dev and prod. That's right. That's right. So remember we did a snapshot. The snapshot is making sure that your build is clean. And once we have that, if we remember this pipeline file, you will use the same artifact. You won't have to build again. You use the same artifact that deployed all the way through. That that will be your gold copy, essentially. Yeah, and then so this is, let's see how this is doing. We are terminating it and then put in the new new code. And then the other thing I want to show you is more around time series data so Prometheus gives us all the time series. So this is kind of a high level cluster level view. And then you can also view your functions and drill down to the health of each of your functions as well. So yeah, I won't, I won't give you too much information here. Let's go back to the deployment. So yeah, it's, let's see. So this usually takes about three minutes. So it's deploying the service now. I think in here I put in the destroy command. Yeah. I put in the delete. So I'll delete the previous deployment. If you don't want to delete it, then it's going to just use out of the box rolling deployment. And we're also looking at blue green deployment for the functions as well. So that the functions have full control over different versions being deployed. When we look at the pipeline, so that's done. The pipeline is done and you see all the, I think this is a little delayed the message here. That's the, that's the old containers shutting down now. That's right. The old ones. New ones up and running. So you should be able to show it off. Yeah. And the new one is running. So if I go to here. This method here. Yeah, C and CF ping pong. That was a code change. So I'm going to hit it a couple of times. So then we'll go to open tracing so we can see these things. I hit this a couple of times. So if we look at the open telemetry, right, this is also out of the box. So you can see the, if you want to debug, right, if you can go trace these things. So for example, if we look at, yeah, you see how this is. Let's see if we look at the traces, we're at 133. Yes. So this is that ratings, right, we're putting pulling back some sample ratings. You see this, there's a bit of a cold start right. So the first one took one second and then the subsequent one took milliseconds. So let's drill into it right. So the first one you can see majority of the time is spent on Java right. So this is your, this is your select statement database, which is pretty quick. But then if we look at this one here. This is your credit method pulling back all the data so that took majority of time for one second. But then if we look at the other one. This is after the code start right so you look at this one this total was nine milliseconds. And your select went faster too. Yeah, select went faster. Everything went faster. The second time around it took a little bit of warm up. I didn't actually notice that. Well, I did notice that but I didn't see until we had this instrumentation in place right so developers also get this experience out of the box as well. So that's all I want to demo for today so I will turn over to Evan. Okay, you'll need to stop sharing. Okay. Oh, just one more slide. Okay, so this technology is very new and exciting right I think couple takeaways one is that with that open contribution model right teams are able to come in and contribute and really get excited and get on board it with this right. We have 90% of the application in scope for this year meaning 90% of our application portfolio have either started or completed fast function. So if we look at a team view right 50% of our teams, all of our teams have done fast functions already. So we're kind of sort of following this, this adoption curve we're towards a ladder stages of adoption now so this year nine months from having had something to show them at all. That's right. Yeah. It really helped us with on our journey because it simplifies the developer experience as well as the infrastructure experience with with using Kubernetes. Okay. So, yeah, so we've talked a bunch about, you know, oh hey, S&P has built this fast platform and they're using Knative. But what does that actually mean. Knative is a system for building serverless HTTP applications. So we've talked a little bit about serverless. I'm going to talk a little bit here about why we do HTTP and then we're going to dig into more about how that serverless stuff works. So when we were starting the project, it seemed pretty clear to us, building an open serverless system that we want to build on some pretty robust standards and HTTP kind of struck us as the obvious way to get requests in and out because it's well understood. And it keeps evolving and improving so it's not like we picked a standard and you know it's going to be the same three years or five years from now. It'll keep getting better. Support for things like W3C's tracing will just automatically get added in and so all your tracing tools should work from front end to back end. In the next year or two would be my guess as the you know as that ecosystem evolves. Similarly we bet on Kubernetes for container scheduling. We knew that was going to keep improving and we wanted to be on the ocean where the tide was rising. And that would lift our ship as well. But we also wanted to specialize Kubernetes more than Kubernetes itself is sort of here, here's a tool you can do anything with it and you're like, I can do anything. But most of the time you don't want to do anything. You have a specific thing you want to do and so we wanted to make it a sharp specific tool for cases where you were building something that was basically a 12 factor application. That you were willing to speak HTTP that you didn't need to keep local state and that we could make things a lot simpler. And so the first place this shows up is, I don't know how many of you define Kubernetes deployments on a regular basis. This is kind of the smallest simplest deployment you could have over on the left hand side. You've got a deployment but if you want to talk to it you actually also need a service, and you need to have a bunch of selector labels, and you need to match some ports and stuff like that. And so you have at least two objects you've got to keep in mind and you have to think about labels. There's actually a lot for developer to dig into here because we haven't really talked about like what's a Docker image. Over on the right hand side, you can see a K native service. You basically say, you know, hey, this is a K native service that's the API version and kind. Here's its name. It's container. And it speaks HTTP. And then there's a bunch of convention and a little bit of magic in there. And you get some services that you don't get from a standard Kubernetes deployment. Like an autoscaler, you could go and figure out horizontal pod autoscaler. Oh, look, we just added a little bit more lamble YAML to the left hand side. So, we mentioned autoscaling. And then you get this to some extent with ingress for management of HTTP host names. Again, we just added another object you have to think about to the Kubernetes space. So, all those things are useful when you need to do something strange, you know, when you say, hey, I'm running a bunch of game servers each game server is kind of independent, but they're kind of together. Kubernetes is a great fit for that. But if you're building HTTP applications, K native simplifies that. We also build in some tracking of previous states. Every time you do an update, it creates a new revision. So that's a little bit like what deployment does, but it's a little easier to find them and go back to the earlier ones. And they're the garbage collection policy can be date based and and over time without having to think about, you know, how many replicas sets am I going to keep around. And we also automated a bunch of the rollout stuff between them deployment basically has one has a policy that's, you know, hey, we'll just start restarting things. And we'll get you up to the number you need. And since we're serverless, and we sort of start from zero. It's easy to just start a new pool and scale that up. And then the old ones go away when they need to. So you may burst a little bit more if you want to switch things over quickly, but you can also do it much more slowly or get more control over HTTP. Also, since we knew do new we're doing HTTP and we knew that it's 2020. So we built in integration with Start Manager and less encrypt so that you can automatically also get all your SSL handled without developers having to get involved. And you can have just a single wildcard cert that covers all of your functions in all of your domains. And let's talk a little bit now about how S&P actually ended up using this. So they talked about having blue and green environment. So you can see in the picture down at the bottom, you know, in their dev environment, they'd have cluster one and cluster two. And one would be blue and one would be green. And so they have a specific DNS zone. They also have a top level DNS zone for the environment. So dev has a different domain than UAT or production. And so if you don't want to have to think about, you know, are we in blue or are we in green, you can just hit that top level thing. You can see the details. It's there. And they integrated with AWS certificate manager to do the provisioning out of the box. Knative ships with integration with let's encrypt using Jetstack Start Manager, which is great if you have an internet connected cluster and you don't need too many certs. For a company like S&P, they can afford to send a few dollars AWS's way to get higher rate limits and certain guarantees that let's encrypt just isn't set up to give. Their goal is to encrypt the internet, but not necessarily to run a financial business. So, you know, find the right tool and one of the goals with building Knative was that you should be able to customize this stuff. So I think that was a success. And now we're going to talk a little bit about what the data path looks like for Knative serving because we've talked a whole bunch about it being serverless. And let's see what that actually means. So the first goal for handling requests. I call this life of a query. I got my start at Google and one of the first talks that you get is here's what it looks like when you actually do a search query. So I always call it life of a query. But the goal for steady state is that things should look pretty close to the same cost as if you were just using raw VMs or raw Kubernetes. So a load balancer splits stuff across your HTTP routing layer and stuff gets sent to a user container. And that's all lovely and good. And then so the next question is, you know, okay, lots of traffic comes in, you know, that goal of 3000 concurrent users, for example, that Mark was talking about. How do we actually count those users and then make sure that we've got the right number of containers and Knative does this by injecting this little proxy in front of the user container and being able to count all the requests and feed that back into a request based autoscaler. So if you're familiar with the Kubernetes horizontal pod autoscaler by default that will queue off of CPU or possibly off of a custom metric. But you have to do a bunch of plumbing to get your custom metrics in there. The default behavior of Knative is request based scaling. So you can take out the Knative autoscaler and put in horizontal pod autoscaler. It's possible to do we find that most people actually like the request based scaling. So this is, you know, building a particular focus tool, because we understand HTTP and we can get into the protocol. Okay, so another thing that AWS Lambda gives you is, you can write. Well, in Lambda, you have to write your code with the assumption that there's only going to be one request going on in a process at a time, because that's how Lambda works. But lots of people actually like that because it means that if you want to have globals for stuff or you just want to know that you aren't going to get interfered with anyone else. You have, you know, a container that wants to run a request at a time. We wanted to support that in Knative. So Qproxy also lets us enforce, hey, you know, you may have 50 HTTP routers, but you're only going to get one request per container at a time. You can also crank that up if you want to, you can say, hey, 50 or 100, you know, look, I've written this in Java, it's all re-entrant, you know, let it go to 1000 or keep it at one. And the default is to assume it's re-entrant, but it's easy to just say, you know, one request per container. So now, now, you know, okay, that's all nice kind of nice ergonomics. How does that scale from zero thing work? Because there's nothing actually running. How can we count how many requests there are when a request comes in? So this is where one of the clever tricks of Knative is that we run a single activator for your entire Kubernetes cluster or possibly a replicated set of them, but a small number, when you add a new function, it doesn't add a new activator. The activator is shared and it will pause the request and it'll say, hey, there's no instances of this. Kubernetes, please go talk to Kubelet and actually get a pod ready. And once that pods ready, then the activator will forward the request along. So you'll see a longer response time for those requests, but they won't get dropped on the floor. And so we've talked about, okay, we had zero, we want many, how do we get there? How do we do the opposite? No requests have come in and we've shut down. It turns out that actually takes a little bit of a clever dance as well. But first you need to add the activator in. After the activator is hooked in and the HTTP routers all know about it, then you can scale things down to zero the rest of the way. And Knative tests and handles all of that so you don't have to think about it and you don't have to build anything complicated and you get scaled to and from zero. The last part is Mark talked a little bit about blue green deployments and progressive rollouts and we wanted to support being able to say, hey, this is a new canary thing, we're only going to give it 10% of traffic. Even in that case that Mark was talking about where they have only 20 users, maybe you only want to do 10% of traffic anyway so that you tell people reload a few times and it should work. But you only have four pods. So with standard Kubernetes services, they're all around Robin. And if you replace one pod, it's a 25% rollout. Since we control that HTTP router we can actually and it's something on void based so far, we can actually replace things in there and say do 10% and 90%. I just kind of hinted at this one, we support multiple HTTP routers so contour, Istio ambassador glue and red hat wrote a really lightweight one called courier that's specifically focused for being used by Knative. So if you want to integrate with your HTTP router. We don't want to tell you, oh, you've made a big investment in Istio mesh or you've made, you know, a big investment in glue or contour or something like that. Sorry, throw it all away. So we have adapter layers for all of these and you can choose which one you want to install. I'm going to blaze through this because I have one minute left maybe. And then we'll have time for questions at the end. So the mental model for Knative is, I showed you that service a service is made up of a route which is the networking part and a configuration, which tracks basically how you want things to run and the configuration creates additional revisions. Every time you update it. The route lets you pick which thing receives traffic it can either be the latest revision or a specific revision. We call running with the latest revision at 100% Yolo mode, you only live once. But it's also really handy for for development and you know stuff that's not really critical. And that's the end. We're available for questions and anything else that, you know, feel free to use the Q&A or chat or stuff like that to get in touch with us. We've got contact info afterwards. VMware is hiring. I should probably add, we are looking for people to add to the Knative community and to hire them so feel free to reach out to me. Twitter DM or email. And I don't know if S&P is hiring Mark. We are I'm actually currently looking for two blockchain developers. And by the way, blockchains running on Kubernetes too. Cool. Yeah. Okay. Yeah, thanks to Evan and Mark for great presentation and demo. So we have now some time for question if you have some question around this topic. Yeah, feel free to drop in your Q&A tab. Okay, we got a one question just came up. Who will take this one? I can take that one. Okay. I'm going to answer it live. The question is, is there a significant difference in responsiveness between auto-scaling with Knative versus the horizontal pod auto-scaler? As always, the answer is going to be it depends. I will say that the Kubernetes horizontal pod auto-scaler may be, I don't know what knobs there are to tune how frequently it's checking to decide if it should rescale an application. The Knative auto-scaler team looks at that and has tests that are basically, hey, we're at zero. What happens if we dump a thousand requests per second on a Knative cluster with container concurrency set to 100 or something like that? So how fast do we get to the 10 or 12 instances that we should have for handling that much load? So they have a pretty fast cycle on the metrics collection and they've recently migrated that to GRPC from HDP to get additional efficiency benefits because they were finding that for large clusters, it was too slow. I haven't seen HPA measurements, so I can't tell you HPA is going to be slower, but my suspicion is that it's probably not tuned to check as fast and you may be able to tell it, you know, check every second or check every two seconds. Thanks for the answer. Okay, I think. I'm assuming that Mark, that S&P is using the default auto-scaler, the Knative one and not horizontal auto-scaler. We have a demo of it where we just scaled it up to 100 parts in like seconds, it was very efficient. The goal when we started Knative was to be able to match Lambda's performance eventually and that's going to take more effort and getting down into Kubernetes as well. Some of the limitations we see today are around things like how long does it take to schedule a pod and pull the image. And so I think that there are one or two caps that are percolating about how do we make that faster. For example, readiness probes. If you use the Kubernetes readiness probe, you've got a minimum of a second for your service to become ready and we'd like that to be below a second, you know, every 100 milliseconds or so. And currently the activator goes and does that check even on unready members of the service to see if it can race and beat Kubernetes propagation time on services. I think one of the things with Knative is that with Lambda's and Azure Function in the world, you're very limited. With Knative, we can do so much. We have full control over what we put in there. We're even talking about, with Pivotal, about trying to put a power builder in there. Because we have legacy apps, right? We want to modernize and there are different ways of modernizing. It gives us a lot more flexibility basically because it's in our full control and we can do whatever we want. And it's multi-cloud. Another great example of that is Doug Davis has a prototype that he's trying to figure out how to how to fit into the community for being able to just have a shell script that gets adapted to an HTTP server. So your container just has a shell command in it, you know, as a shell container and then inject an HTTP server binary through a volume mount, rewrite the entry point so that it calls that HTTP server and the HTTP server invokes your normal Docker entry point once for every HTTP request. And it's a pretty cool demo and we're trying to figure out, okay, you know, how do we make it that next level of accessible to developers? Yeah, I mean you guys are moving fast because we had a feature where we wanted to support S3 for IEM roles and that was, you know, we put in the request through GitHub and then that was released to us very quickly. So quick turnaround on that. Definitely been an interesting, oh, there's another question so I'll stop just convincing. What percent of compute or app estate could go to Knative or serverless ultimately? I'm going to pass that over to Mark first to talk for S&P and then I can have some unfounded opinions about the state of the industry. From our experience, they are other than the commercial office shell, right, if you think about breaking capabilities, so we are more mapping capabilities, right? And then even the first stage is almost a cut and paste, like you take your Java code, cut and paste into your .NET code. But then when we look at it, right, what percentage really depends on what percentage of your apps, you know, what is the current state of the target state. The target state for us is 100%, right? Other than the commercial office shell, we can move into, you know, because it's container based, so we have a lot of flexibility in terms of what we put into it. I've also moved some commercial off the shelf stuff to a serverless environment if it can be containerized and is, you know, stateless containers. We are actually, so we move Pega and Documentum, we are moving Documentum into containers. It's a bad idea. I ran Jira once like that, but it turns out that Jira keeps a bunch of local caches. So that was an unsuccessful final experiment because your issues wouldn't show up until somebody told it to re-index. So I would say if you have off the shelf software, try it. You may discover that it's not successful, but some of it actually does work pretty well. In terms of overall, I would say that Knative, specifically the current Knative serving, it might be about 30% of sort of all workloads where all workloads could also include stuff like, you know, databases and storage and stuff. I think there's other places where things could get more serverless than they are today. Looking at stuff, you know, a system like Pulsar or Kafka or ActiveMQ that scaled out just automatically from one node to many without having to think a lot about how many partitions do I have would be a really cool serverless, you know, distributed log system. And I'd love to see one of those. The follow-up question is, is state an issue here? How does Knative deal with it? So Knative and a lot of the serverless platforms today are stateless, like 12-factor. And the assumption is you can start two or five or 10 instances, and when you don't need them, you can just shut them down. So if you need to have state or shared state, using something like Memcache or Redis, if you need lightweight stuff, or just using, you know, your database to share state or an object store to share state, keeping state in your process or on disk, not such a good idea. So don't do that. And then there's a question about plans to support fast and Knative on ESXi through Project Pacific. Well, so two answers. You can run Knative on TKGS clusters today. That works. We use it for some of our internal testing. In terms of product plans, I'm going to have to point you back to a VMware product manager. Valentina Alaria would be probably the best, but feel free to send me email and I can connect you with the right VMware product managers because I mostly focus on the open source software and I don't keep track of VMware's product plans. And so we have, other than HTTP, we also have Chrome jobs. We have messaging, like eventing, I showed in one of the slides, and we also have static web UIs, kind of like you would with hosting user interface on S3. So we have all those running in Knative as well. I think we had some TCP use cases after I think that up. Oh, you mentioned TCP. One of the fun things with Knative, if you're a network, if you were a networking geek, is we actually support HTTP, HTTP2 and WebSockets, all at the same time, which is kind of a fun combination of spaces to talk about because there's lots of different ways to stream things back and forth even though you are just speaking about HTTP. And that's one of the great things about having such a broad ecosystem to pick from. You can auto scale streaming responses, which is, I've seen good use cases for it. I've also seen that start to bleed into the stateful space a little bit more than I'm comfortable with. So with great power comes great responsibility. We are at time. I promise that things would go early. And apparently I've failed at that, but yeah, no worries. Feel free to follow up with questions on either Twitter or by emailing either of us. And thanks for attending. Yeah. So, okay, so any last word, Mark? Thank you for having us. Perfect. So, all right. And that's all the question we have time for today. And thanks for joining us once again. The webinar recording and slides that will be online later today. And we are looking forward to seeing you at the future CNC webinar. But also we have a CubeCon and CloudNativeCon North America next month and November 17. And we are looking forward to seeing you once again, have a good rest of the day. Thank you. And there's no capacity limits on that because it's virtual. Yeah, thanks for having us. You guys are good. And have a good rest of the day, everybody. Bye-bye.