 Hello everyone. My name is Sagar Joshi and I work with Microsoft as a partner technology strategist. You can get in touch with me using the Twitter and LinkedIn information you see on the screen. Today's topic is Keda, an acronym for Kubernetes even driven auto scaling. We'll first start by looking at some of the challenges which developers experience, how Keda solves it. We'll look at the Keda of community and architecture and end with a demo. Alright, let's get started. If you're a developer working with Kubernetes to host your applications, you might be aware of a concept called as HPA. HPA means horizontal pod autoscaler. It's a component of Kubernetes which helps you to scale your pods, which is the CPU or memory metrics. But as we move into the modern world of microservices and even driven architectures, our scaling needs are also changing. You might need to scale your applications basing some custom events or messages which are there in your application. Well, you can solve that problem possibly writing your own frameworks, operators or custom resources. That could sometimes be time consuming or difficult to maintain in the long run. Hence, in order to drive developer productivity and agility in designing lower systems, Keda solves this problem for you. Keda helps you to scale your applications basis the events or messages in your application. Let's look at some of the features of Keda. It is very relevant in an event driven architecture. Keda helps you to implement autoscaling easily. We have a lot of scalers, for example, from telemetry systems, database systems, messaging systems, which are used across the industry. You can scale jobs as well as pods using Keda. Keda is also vendor agnostic. Whether you are running your Kubernetes cluster on premises on your laptop or on the cloud, Keda will work just fine. If you are working with Microsoft as your functions, which run on the cloud, on the edge or on premises, you can use Keda to scale as your functions as well. Again, the value proposition of Keda is helping you easily implement autoscaling for your applications. Let's look at some of the community work around Keda. Keda is now a CNCF sandbox project, which is cloud native computing foundation. It was originally developed and now maintained by Microsoft Red Hat and many other companies who are contributing to the open source ecosystem. If you want to get involved, just log into keda.sh slash community. Now let's quickly look at the Keda architecture. Keda sits between the horizontal pod autoscaler and an event trigger source. Now this could be a messaging system like Kafka, RabbitMQ, or Azure Service Pass, which generates messages. It then feeds that information to the horizontal pod autoscaler, which then initiates scale action for your pods. This is just a simple diagram explaining where does Keda sits inside your Kubernetes cluster. Just to take an example of some of the scalars which are available and very prominent software in the industry which are used for messaging or evading architectures. Some of the examples are Apache Kafka as your service bus, as your event hubs, Redis, MySQL databases, and many others from the other cloud providers and industry. What are some of the use cases that you can use Keda in? Number one, pod autoscaling or nodes. So basically you can scale your application pods, basis the number of events or messages that are there in the system. Just scaling by CPU or memory might not be sufficient. Keda can also be used to implement serverless workloads in Kubernetes. I highly recommend you read about a concept called as Virtual Cubelet, if you're not done so already. An example of Virtual Cubelet you can find on, for example, in one of the cloud environments is a virtual node in Azure Kubernetes Service. So you can scale from 0 to n pods or shrink in from n to 0 pods on a Virtual Cubelet which basically is truly serverless. And this in combination with the cloud environment can really help you to implement truly serverless workloads using Kubernetes. Alright, let's jump right into the demo. We're going to use a Azure service bus as the event source and then we're going to push some messages into the queue and scale the number of pods, basis the number of events which are there in the queue. And if it crosses certain threshold, we're going to keep adding pods, right? So let's jump right in. Here you see is my console. I have a Kubernetes cluster running on the cloud and I can show you the number of nodes which I have. So I can just say Qubectl get nodes. I have two nodes currently which are running. Now let's see if I have any pods running. So I'll say Qubectl get pods and I basically have a namespace for this. I only have one pod which is a web pod. And if I want to see the deployments of pods, the order processor pod. So basically the sample processes orders by picking up messages from the queue. And currently there are no orders, hence none of the pods running, which is zero. And this is a specialty of KDA from zero to N or zero to one and back to zero, which cannot be implemented by using a simple HPA. Now let's try to see and push some messages and we will be able to experience that the pods or the number of pods are getting added to the deployment as a number of messages in the queue scale up, right? So let me add a watch on the number of pods here. And let me sort of zoom in a little bit so that we are able to precisely see what's exactly happening. Awesome. Now I'm going to start pumping messages to the queue and we'll see the number of pods go up. So let me start my VS code and I'm going to just start pushing messages to the queue. But before that, let me show you a small visualization which can help you to understand how many pods are there. All right. So let me start my application, which is actually responsible for pushing messages to the queue. I'm just going to say .NET Run. It's a .NET code application to ask me how many messages do I want to really push? 200. Fine. And as you see, the number of messages are going up right now. And on the left-hand side, we'll be able to see that the pods will also be starting to create. And then KDA will keep adding pods until the orders is below the threshold number. Now if you see, pods are getting created, right? The order processing pods, which were 0, now we are adding more pods into the deployments. And if you see, different pods are getting created within the cluster, right? And then if you just pause it and see instead of the watch, now we have almost 1, 2, 3, 4 pods running. And if you just keep doing this, you'll probably see more pods as well, right? So you are able to scale in the matter of seconds until the queue length drops below the threshold, pods will also come down to 0 if there are no more messages left in the queue. And this is how you can implement autoscaling in response to the number of messages arriving in the queue. Now just look, let's look at our sample YAML file, which I used to deploy the KDA scaling. This says I'm using the Azure Service Bus as a trigger source for my messages. I'm monitoring the queue name called orders. And the threshold is 5, which basically means if there are more than 5 messages in the queue, start adding pods to the deployment. And then if you see, I'm configuring what is the maximum number of replicas of the pods that I can add, by default the name replicas is 0. And I'll just use kubectl apply for applying this configuration to my pods or to my deployments. Now as you see, the auto queue has now come down to 0 because the increase in pods has led to higher processing throughput. Now if you see here, we can just say again how many pods are there and we see almost we have reached the capacity. You can also go and check the deployments or what is the number of pods in the deployment we have reached the maximum capacity of 10. Now these 10 pods are actually processing the workload and then we'll be able to see that it also goes down to 0 after the application has processed all the messages. So if we wait for some more time, we'll see that the number of pods will drop down to 0 again as KDA starts removing those from the deployments. All right, so that was the demo and I highly encourage you to go and explore all the samples of KDA on github.com slash KDA code slash samples. Please feel free to reach out to me in case you have any questions or concerns and I'll be happy to answer them. Thank you for being a great audience and I hope you have a great conference ahead. Thank you very much.