 The next topic is in the evening sidecar in FIDAS Ravadis by Kartikeyan VK. Kartikeyan is a cloud native architect at Pro India. He is passionate about learning new technology to solve business and developer challenges. Welcome, Kartikeyan. So, how was the session going on? Okay. Fine. How many of you have already worked on Kubernetes? Okay. So, who are planning to work on Kubernetes? So, can you read this? Can you understand this meme? Those who have already worked on Kubernetes will say, can laugh about it. How many think Kubernetes is easy? It was easy. Okay. Okay. Kubernetes is not easy. Okay. So, even when we took it in our project, we thought it's actually easy. You deploy a docker and it all starts working. It's not the way it works. There are lots of things in Kubernetes, which is too much to talk in 20 minutes. I'm not going to do that, but I want you to take away certain things out of this 20 minutes or 25 minutes session they've asked me to do. So what I'm going to do is I'm going to teach you two or three things which will help you to design or architect your product when you are thinking in terms of Kubernetes. Okay. So, first thing is, using Kubernetes in production is not easy. Okay. You have to know lots of things just to make sure to run one docker file. Okay. You run it once and then after that, you'll start feeling the pain. Okay. Those who are laughing at this, I know they have already felt it. Okay. So, we'll start with why KEDA. Okay. So, I'm going to talk about KEDA. KEDA is basically even driven auto-scaling technology where you can use it for scaling your Kubernetes. Okay. So, why? Okay. Already the Kubernetes scales, right? Why you need KEDA? We'll answer that. Cloud-native serverless option, we need works on all clouds, Google, AWS, Azure, okay. It supports horizontal pod scaling, we'll come to that again, and it gives you a fine grain control on what you want to do. What is KEDA? So, KEDA is basically that, okay. For example, whenever there is a high load, what will happen? Okay. And you can anybody answer that. Say, for example, you have like a four or five pod running and the load is high. What will be the next thing that will happen? What is that? Throttle will happen. Okay. What else? Pod will increase. Okay. So, how does the pod increase? HPA. Okay. So, what does HPA do? Based on what? Based on? Super. So, based on RAM CPU metrics, it actually scales your pod. Okay. So, what if I want to, so there is a web request that comes in and your CPU uses being throttled to say almost close to 90 or 80 percent and Kubernetes does what? It goes in, gets creates one more replica set or pod, right? Is that what HPA does? Okay. So, what if I want to do some kind of event based scaling? I have a queue, okay. And there are like one lakh or one million objects in the queue. Okay. How do I scale it? Can HPA do it? Why HPA can't do it? So, it is not based on CPU, right? The content or the data is outside the Kubernetes, right? So, if you want to scale any event driven application, you need Keda. Okay. So, next time if you are using Kubernetes and you need some kind of a queue or event bus, Kafka, any other service bus, then you might think about Keda. Okay. So, that's the major thing. So, as everybody knows, HPA is nothing but what? Horizontal pod, autoscalar. Okay. It scales your pod, meaning, for example, if Kubernetes wants to increase their pod because of high throughput or number of users have increased, okay. It needs to increase the pod, right? So, you serve all the request that comes in. That's where the HPA does it. So, it does based on metric monitoring and it also does the pod scaling. So, how does Keda comes into this picture? What Keda does is, so, there is already a HPA there. The metrics adapter, the control and scaler and admission. These three things will take care of scaling your Kubernetes pod based on the load. For example, there is a queue or event hub which has one million requests and you might need 10,000 pods, right? Or 20,000 pods or 10,000 pods, 5,000 pods. Horizontal pod scaler cannot scale it. This metrics Keda will actually scale it and then based on that workload, the Kubernetes servers will be called, okay? Yeah. So, now, can anybody tell me what is the difference between normal Kube jobs and Keda jobs? What's the difference? Any idea? Yes, basically. Yeah. Kube jobs is nothing but normal cron jobs, right? The timer trigger or any other jobs that runs and Keda jobs are based on number of requests or the external events, okay? What is the good thing about Keda is if you don't use or if the queue has zero elements or items, okay? This pod can be scaled to zero. So, when the pod scale to zero, what is the advantage? Cost, okay? You can save lots of cost. So, whenever there is an eye throughput, when it's needed, it scales up, goes up, up, up. Once it's down, the Keda will automatically bring the pod's number of pods down and you can save lots of money. So, we saw about HPA, right? That's the main thing and we also saw about Keda. Keda is basically an event-driven technology which we use here. The actual context of this event is talking about AD workload identity, okay? So, for example, so what if I want to use Azure resource, Key Vault or any other database, any other database by the pod, okay? So, how can I use the resource? Say, for example, I want to use, my pod wants to use the database. How can I use it? What is that? It's using our bag. What else? Selector. What? Service. Server, what? Service accounts. Service accounts, correct? Service accounts. So, you can also use it through connection string also, right? Correct? Is that right? No? Okay, fine. So, you can, if you're using connection strings, what will happen? What are the disadvantages of using connection string? Use a name and password, why? If you give what is, use a name and password, what will happen? Security, okay, fine. Who is going to do the security problem? So, okay. So, what if I give the connection string, okay? What are the problems that will come up when I give a connection string? What is that? Connection management. Okay. Maintable tissues. I won't tell you the whole truth, okay? Yeah. What will they do with the production connection string? Yeah. What is that? They put a delete star, okay? So, that's not the right way to do it. And also, writing code for accessing the resources is not the right way. It's not the right way to do. Even, and you can still use R back and all the, say, but it's not straightforward where you can connect those resources, okay? So, with Azure AD workload identity, they have made it very simple. Okay. So, how it does this, I'll show you the code first. So, this, you have to just write these two lines of code into the code. Then you'll be able to handle that. I will show you the other codes also for configuring it, okay? So, how this Azure AD workload identity works? When the Kubelet wants to connect to workload, right? What it will do is, it will ask for, as somebody said, the service account is created. And then, yeah, the service token is got. Once the service token is got, the service token is authenticated by Azure AD. And then, the open AD discovery document will validate that. And the workload will get access to the Azure resource. So, workload there and this Azure resource will get access once this intermittent steps is over, okay? Yeah. So, yeah, as I said, there are like only these steps available. So, what you need to do normally is, you have to configure the OIDC specific feature flags. You have to get the OIDC URL. Since interest of time, actually I did the code. They said, laptop also not. You cannot bring the laptop. I mean, I can't, what to say, create a video also. It takes lots of time for me to create a video to do a demo of five minutes. That's very tough. So, I just thought I'll put it here. So, you need to create a mutating admission web book. And then, you need to install ACWI. This is the main command here. Once you create the service account and federated account, you can actually test it. It will give access to the Azure thing, okay? So, yeah, so major takeaways out of 20 minutes, right? It's too much to give you lots of things. Major takeaway I want to tell you, main is the major takeaways. HPA has its limitation. What is limitation for HPA? What is that? Yeah. So, you cannot scale based on any event or any external sources, right? So, that's a major problem with HPA. That is solved by KDA. The identity can be configured using ACWI, okay? Whenever you want any Azure resources or any other resources to access your pod to access any of the resources, you can use the ACWI, okay? Any questions you have? Serverless, okay. Any other question? Yes. Yes. Yeah, okay. So, first question, how does it work with serverless, right? So, you can configure that KDA. I forgot the actual keyword. You can configure it to the minimum number of pods you can run. For every scaler, there will be one pod. For example, Event Grid will have one, sorry, Event App will have one. Q will have one. Service App will have one. You can configure that and the load will increase. You can also configure number of, say for example, I take a thousand Q items from the encryption. Then it can scale up and once it goes to that level, it will automatically scale down. Your question was HTTP, right? Yeah. I mean, did you find any problem in that? Okay. So, okay, fine. So, there might be a cold start. If you keep one pod running all the time, you should be able to figure it out because I have worked on both HTTP and Q triggers. The thing is, we, in our company, we did a huge cost saving. Initially, we calculated that, it's a basically ML model we ran it. It cost around 21 lakhs. We started using KDA and the cost came around three and a half lakhs. Okay. And out of which, one lakh went to log management. Okay. The unnecessary log cube, right? That log management. So, we almost saved like 17 to 18 lakhs by using KDA. Okay. Because it will only scale on need and then... Okay. So, it will only scale on what is needed and then it scales down. That's the huge advantage. Meaning, you can even say 0.2 CPU or 0.1 CPU and it will be charged only for 0.1 CPU. Okay. Yeah. I have one doubt. Yeah. Hello. Yeah, yeah. So, I have configured. One question I have. Let's say that I have configured MariaDB to scale based on number of queries that are coming. Okay. Right? So, what should I give in the connection string? Let's say that MariaDB increase from five replicas to ten replicas. Okay. So, how the pod will get connect to the MariaDB? So, you want to scale the MariaDB or the pod? Yes. Let's say that I have given maximum replicas as ten for MariaDB. Okay. So, what should be the connection string from the pod? Because I cannot use service name to connect to the MariaDB, right? Because the service will send the traffic. It may send the traffic to one pod at a one time. Second time, it may go to the second pod, right? So, I cannot use a service name to connect to the MariaDB. Instead, I have to give a pod name, correct? So, in that case, what will be the connection string from the pod to connect to the MariaDB? Okay. So, you are saying the MariaDB sits on scaling based on the event. Let's say that number of queries that are coming to the MariaDB. Okay. And it has increased from five replicas to ten replicas. Okay. Now, the pod needs to connect to the MariaDB. Let's say the front end is the PSB-based application. So, there is always be a service. Okay. The service guy will take care of the talking to the pod. No. Because one request can go to one replica. The second request can go to the second replica, right? But the second replica will not have my data. No. I think I don't understand the question because it's very trivial DB problem, which is solved like under 50 years before. I'm just trying to understand what is your problem. Okay. One simple question. Can we have- I understand the pod scaling. He's asking about how will it know which pod to go. That is all solved in the DB itself, right? Yeah, that's what I'm trying to understand. Yeah, that's what I'm trying to solve. Because the KDA is not actually built for that level of scaling. I'm not sure. Because there is still a Cassandra Scalar that scales on based on the query, but it's not like which pod to go. That's basically distributed computing problem which is already solved. You can actually talk to me out. We can just discuss- You can connect offline, okay? Yeah, yeah, please. Thank you. Okay, fine. All right. We have some questions. Yes. How is it different from- I mean, how ACWI is different from- Okay. They have simplified it for KDA. Okay. The orders you say, right? Service, account service principle. This still uses all the details. Okay. The way you see everything is done. But this industry here- So KDA pod for using KDA, I'm talking about KDA deployment or KDA jobs. You just need to put these two. For KDA, this is for KDA. It's not for all the pods. For KDA pods it is. Okay. So there are lots of scalers in KDA. This is authorization. Okay. Hello. Hello. Yeah. In the events which are pending, is there any kind of prioritization which can be done so that you can give priority to that? Okay. So that has nothing to do with KDA. You can use different, say, user service hub or event hub for that priorities. Okay. It's not based on KDA. KDA just pulls the records from the, say, service hub. You can set priorities or orders in service hub or Kafka. Then you can pull it. Because I understand the question. Because Q does not have any orders. If you want orders or priority, you have to use different topics or use the different- I mean, not the Q. You can use event hub or service bus. Event hub is better, or Kafka. Yes. This is solely dependent on Azure AD. Yes. Even if, say, for example, your workloads in AWS and then your identity is in AD, then it will actually work that way. So it's basically AD thing. There are lots of authorizers. But concept is almost the same for all the other authorizers. Excuse me. Yeah. Yeah. The colleague was asking about the database, right? Yeah. So if we can scale the database, right? So let's say I add few replicas. I am assuming that the database will start writing new data in the new replicas, right? Yes. Once the data, or the new parts in this case. But let's say if KDA tries to scale down, what happens to the new replicas which is now storing the data? Okay. What happens to those data? See, I think now I got the question. There are two things, right? The compute and storage. Right? KDA takes care of compute, not the storage. Okay. Is that answered the question? No, that still doesn't answer. Because the data is still, let's say the new compute units that are created, let's say the storage is separate. KDA doesn't take care of it. Yes. Now the data is written to these new storage locations because the new parts come in. Yes. But now the KDA says, okay, let's stop all the five replicas because I don't need them. Yes. But now the data, these new volumes would not be attached to the old replicas, right? Or would it be a common storage because that was a little bit confusing. Okay. So the storage should be common. Okay. But how will the database know that these new, because even though all these replicas, right, they have their own volumes. Yes. Yeah. Yeah. But those volumes will be femoral. See, I have not written one-scale, DB scalar on my own. Okay. Because if you, that's what I said. So there's a distributed problem where there will be one R disk and there can be multiple CPUs. If you can think in those terms, once the compute is done and the data shouldn't be in the femoral pods, right? It should actually write it. If the write is not done, the pod will still be running. And then once the write is over, there'll be an event that comes to the pod to kill itself for terminating. Okay. Still, I mean, we should probably look internally more because what I don't understand is the old replicas will start reading data from the new replicas. No, no, nobody reads. Okay. So this, again, we are getting confused with compute and storage. Okay. Okay. Storage is there. That is one. Probably. Okay. No. Then let me rephrase the question. Can database be scaled up and down? Yes. Why not? That's how the whole thing works, no? No, no. The applications can be done. But my question is whether the database part, not the application part. Okay. The database, let's say I'm using Elasticsearch or MariaDB. My application is in Java. I understand applications can scale. That is clear. Because it will be serving more data. That's okay. But can database layers, can those also be scaled and come down? See, that's what they're promising. I have never used a database scalar. Okay. Okay. Understood. Because I don't think so. MariaDB Scalar is there. But for Cassandra Scalar is there. Because for MariaDB, it's a SQL. Okay. So it's a, you cannot scale a SQL vertically, horizontally. But Cassandra on all, horizontally scalable. I think now I got the question correct. Got it. Yeah. I don't think so. MariaDB does have a scalar. But Cassandra, there is a scalar. Got it. Thank you very much. Perfect. I think now I got it. Yeah. Fine. So, I'll just give a huge shout out about my book I wrote. This book is about how to become an architect. And if you want to get your career to next level, this book helps. Those who have actually, how many of you have bought this book? Anybody here? One, five, ten? Okay. Almost like 12 people. Oh. Lots are there. Nice. Okay. So those who have bought it are very much happy. And I got a very nice review from Amazon. They wrote a review also. It's a very nice book. I mean, it took me two years to write this. It talks about the journey I took from say developer to this level. And the way, first initially I thought all the problems, I'm technically updating myself. I should be able to crack the software industry, but it's not the case. 60% of it is something else. Communication, stakeholder management, how you talk to yourself, how to present yourself, how you position yourself, how you market yourself. And all this is put up. And out of the basics you should learn. And if you want to be in current with the technologies, right? There are lots of things comes up. KEDA comes up. Something else comes up. Some people are always in current. So there are certain basics you need to learn. I've actually written all this in those books. So just if you want to copy also in Amazon 600, I sell it for 450 because it's actually cheaper for me as an author. This is my LinkedIn connect. If you want to connect, please do connect with me. We'll be happy to help you on any questions with respect to KEDA or Kubernetes, anything, any technology problem you should be able to, I should be able to answer or I should be able to help you. Any questions you guys have? Anything with respect to event, you can ask me. I've worked extensively. Even streaming, even based. Thanks for an interactive session, Karthik. And thanks for keeping up the time as well. I appreciate it. And we'll try to give you a small token of appreciation for money.