 First of all, I want to introduce myself. My name is Welly. Apologies for the weird setup, because we cannot move this thing today. So I just have to deal with it for now. My name is Welly Xiao. I'm a principal partner solution architect here at AWS. I will be your moderator today. I heard that this is our first KubeCon multi-tenancy conference. So this is also will be our first panel session today. The title of today is the Unlocking the Power of Multi-Tenancy. We're going to hear perspective from some of the platform leaders. So with that, I'm going to introduce our panel today. First of all, Mohan, Mohan Atreya. He's the senior VP of product and solutions at RAFI Systems. Mohan, apparently also the author of the books around digital signatures. Mohan, I did not know about that. So that's a new secret that I learned about you. He has extensive experience in Kubernetes, IEM, endpoints, and more. So Mohan, welcome. Thanks for being here. And then next, we have Prasidia Satya, principal essay on the AWS as well. My colleague in here, she's based off Bay Area, right? She has been focusing on helping a lot of customers in their cloud native journey into AWS, of course. Experts in Kubernetes, EKS, Fargate, ECS, and so much more. And last but not least, Ritesh Patel, the VP of product of Nirmata, and also the co-founder at Nirmata. If you haven't heard about Nirmata, it's the creator of the open source Kubernetes native policy called Kifrna. And there's a couple of news announcements about Kifrna today, so I was really excited about this. Ritesh has more than 20 years experience delivering enterprise software and solutions. All right, so with that, that's the panel for today. I'm going to go ahead and start the discussions in here. I'm going to get my notes. Mohan, I think this first question will be for you. Of course, today is the first multi-tenancy con. And there's so much dimension that I hear so far from the talk about the multi-tenancy. Can you try to maybe help us kind of explain this? When you talk with the customers, how do you typically explain about multi-tenancies and what are the trends that you're hearing from the customers? Sure, absolutely. First of all, thank you for... This is a privilege. Thank you for allowing me here. So the question that Veli asked is an interesting one. We saw some sessions earlier today, where especially the New York Times team, they showed how the journey, right? You have an option one, which results in these pros and these cons. You have option two, then you have pros and cons. And unfortunately, that's going to be the nature of any decision you make. There's going to be some positives, and it'll drag you down in other ways. And some of these, you can compensate through other mechanisms to solve the problem. But in general, what we see customers attempt to do, they don't just start with Kubernetes, right? For them, the problem is a lot bigger. When I were at Talk to Customers, they start sometimes with the concept of your own landing zones, right? Especially the bigger ones, they say, look, I'm going to have to create an environment for my application team. So maybe they start with landing zones. And if you are on AWS or Azure or any other cloud, for that matter, you need these ways by which you can compartmentalize things. So multi-tenancy starts right there for them, right? And then goes even further. If I have, do I create multiple VPCs or not? Do I put everything in one? Do I have a flat network or not? And then things go even further and say, if I have like a managed hosted database, do I have a shared database or not? And only then Kubernetes comes into the picture. So as you can see here, Kubernetes and multi-tenancy is nothing strange here, right? The problems we're seeing with multi-tenancy in Kubernetes, they exist in everything else. So the general philosophy that organizations align with is, hey, I don't want something new and different, if possible, because then it's yet another thing that someone has to learn, yet another thing that is different from everything else. They try and align across all these patterns they have. So the method that works for non-Cubernetes, how far can I take it into Kubernetes? And at some point, of course, it'll stop, right? For example, there's no concept of a namespace in some of the other resources, right? So that's kind of what we see from customers. They want ideally to deal with a known devil than an unknown angel, right? That's easier for people to grok. Most organizations here, I'd be surprised if you're 100% only cloud native. You probably have a mixed environment, right? Some people have hybrid, some people might be multi-cloud, some straddling the world between VMs, maybe even mainframes, then serverless and cloud native. So all of these mixed environments. So how are you gonna make sense of all this? So now, having said that, when you talk about Kubernetes, since we're at KubeCon, we'll talk about Kubernetes, right? All of us heard about the standard patterns, namespace as a service, cluster as a service. An interesting pattern we see from organizations is, can I be in between those two, right? I want the isolation that's possible with the namespace as a service, but I don't want to be in ticketing nightmare day in and day out, right? So I'll give an example. We're dealing with a large, one of the world's largest commercial real estate company. They use Kubernetes extensively and they have an onerous ticketing process that they cannot get rid of. See, if I'm a developer and let's say I want a namespace with a certain quota and let's say I made a mistake, right? I had to wait two more weeks for that ticket to be processed and go from extra sources to wider sources, right? So they want to get out of this ticketing business. So they have kind of found a spot in between namespace as a service and cluster as a service without the security compromise. So these are interesting patterns we're seeing where people are trying to find ways to avoid this ticketing nightmare, form filling, the constant changes because no platform team wants to deal with this day in and day out, right? You want as much automation as possible. So these are patterns we see. Another pattern we're seeing every now and then is if I give a tenant, what are all the doors I can close right away? I think a New York Times team talked about one or two of them, like namespace isolation using Sillium as an example. We see that pattern quite a bit where they say can I have a network policy on by default, right? And then I'll start opening rather than having a model where everything is open by default and then I start locking. They go the other way, which is everything is shut by default and then I open based on exceptions. So there's no one size fits all in a nutshell, but in general, there are time-tested patterns that we are publishing, that the industry is documenting. My recommendation is pick one of them, build on that, extend on it, contribute if you can, and it just gets better with more contributions. Hope that helped. Thanks so much Mohan. I think I also picking up the story about like this is not only about Kubernetes. I think a lot of it is in Kubernetes, but then some of those workloads are still need a database and other services outside of the Kubernetes itself. So maybe this is a question for you, Presidia. Like you've been working with a lot of customers in AWS of course. Are there any best practice or architectural considerations when they're thinking about multi-tenancy in Kubernetes in AWS? Sure. So thanks Veli for the introduction initially and thanks everyone for attending this. Yeah, definitely, you know like the best practices what we see from customer is exactly what Mohan said, one size doesn't fit all. So the architectural guidance and patterns around this also changes accordingly to the use cases, right? So we have seen like at AWS, I work with the enterprise customers, strategic customers, and I've seen that they start from the higher level like the business unit level. And at that time for them, the multi-tenancies account. So they create multiple accounts and they have the IM for the privilege access for the resources at that level, right? So that's one way. And that also helps to limit the blast radius and plus the account limit issue what we have. It also helps them in costing analysis because it's a different account, right? And then you go down the path like Mohan said, there are some platform teams within this strategic customers who wants to use a best practice like namespace as a service, right? And then they use all the rest of the bells and whistles what we have for network policies, policy management, anything around IRSA. As you mentioned, you have to talk to the other AWS services. You definitely need to control those resources, right? So, and then we have also seen the usage of crossplane. That's another thing, right? Which is used actually to provision different AWS resources. So that's also into the practice. And then there are some customers who wants to go for node-based provisioning, right? They use the auto-scaling group. We also have Carpenter, which is a new auto-scaler, which also basically uses the node pool to provision according to, so that you can take your pods and put it in the nodes where you want, right? So that also gives you the isolation for all the pods in the node. And then some people want a multi-tenancy. And in that case, they go for cluster as a service, right? So each tenant gets one cluster. But then it adds to the cost. And then a maintenance is a nightmare sometimes. Upgrade is a challenge. So few of our customers who are worried about these challenges, they say that, okay, is there any other solution? We are okay with not having like this much of workload. So for that, we suggest them the serverless option, which is Fargate, right? So it's like, you don't need to maintain the servers over there. No clusters. It's just like a serverless container engine. So those are like different options we have from AWS, like where our customer uses for multi-tenancy. Awesome. Thanks so much, Rosita. It's kind of pointing out a lot of the available tools out there. And this may be a question to you, Ritesh. I keep hearing the challenges around data isolations throughout the talk today. And I think that's really important. There's many ways we can achieve this, but what are some of the techniques and maybe tools that you have seen work very well when you're talking with the customers? Thanks, Oli. So yeah, so one of the things about multi-tenancy, and if you go back and look at some of the history, right, multi-tenancy in Kubernetes, implementing it is fairly challenging and you cannot kind of do it without automation, right? In the past, there was always a trade-off between namespace as a service and clusters as a service. The one reason why somebody would use clusters as a service is because using a shared Kubernetes cluster with all of the multi-tenancy guardrails in place was really hard. So one of the things you saw, again, referring back to the New York Times presentation, they talked about policy-driven security. And we see that a lot, policy-driven security and automation. So as part of the Kivarno community, using Kivarno for multi-tenancy is one of the top use cases, right? Because Kivarno is a policy engine that not only can validate, but also mutate and generate resources and that can trigger a slew of automation to enable multi-tenancy in your clusters. So for example, you saw the New York teams write a controller, but a lot of that can be easily automated without having to write single line of code through Kivarno. So going back to the data isolation techniques you mentioned, obviously in Kubernetes, you have the control plane and you have the data plane and isolating control plane, the techniques that are used, which we already talked about, namespace as a service. There's a project, I believe. I'm not sure where it's at now, but there was hierarchical namespaces where you can have namespaces within namespaces. And then also there was a kind of, an in-between virtual clusters, like we clusters where you can actually have like cluster-wide resources segmented across teams. So that's on the control plane side, but now we start looking at the data plane and then you start getting into some of the network isolation, which we already talked about, so I won't get into that. But the data isolation is also very important, like with provisioning data dynamically, isolating tenants using different storage classes, making sure that one application cannot use or access data from other application. And then there is a physical node level isolation. If you have a cluster with a lot of different types of nodes, you want to isolate, say applications that use GPUs only on nodes that have GPUs, you don't want to incur that cost for other applications that can be done, right? So all of these are different techniques again. There's obviously challenges in implementing it and there are ways to overcome these challenges through some of these approaches, like policy-driven security and automation. Thanks so much for this, yeah. I think even in the data planes, like a role-level security database these days has become more and more common and it's making it super easy as well, right? To kind of look at it. I will have to say, certainly I see a lot of explosions in terms of the tools and technique when we talk about multi-tenancies. But since this is a multi-con, so this is our summits, I'd love to hear from all of the panels in here, like what do you see as the future in terms like a multi-tenancy? Is there any top of the mind, maybe Prasita, you have something in mind? Sure. I would like to share one project of what we have initiated from AWS called Kanu. This is not only from AWS, just from our like community partners like our customers like Salesforce, Adobe, I think Autodesk and Twilio. So it's called CNOE and it stands for Cloud Native Operational Excellence. So this project basically it takes, it kind of solves the decision making for the tooling of CNCF. So a lot of people must be using, you know like Argo CD, Crossplane, Backstage and everything. So this project basically brings everything together based on the best practices and the patterns, what our customers have worked on and bring it to you so that you can use it and we have the community support and it's driven across our customers as well as the community. So that's one thing I want to share as a future. Awesome. Mohan, do you have anything in mind in terms like future state? Sure. The pattern I see as with any other technology is things like this need to become invisible, right? They, it cannot be a very big, you make a decision and then it should just be a checkbox and you're done, right? And then how do you know whether the system is working for you or not? Because the pattern you choose may not be the best choice for you long term, right? So the other thing that I see common from people is they go down one path, they realize after six months it's not the right path, they had to come back, try another path that's better suited for them for the next two years, right? So we see people asking the question very frequently which is I need to choose something that has two doors. So we go down this path, the cost of moving to another pattern should not be hyperexpensive, right? And invasive on the company. So these are the patterns we're seeing that people are trying something and moving to other patterns that are maybe better suited for them long term. So, and the thing becomes invisible behind the scenes for them. Thanks so much. Preetas, do you have something in mind in terms like future state? Yeah, I think obviously, you know, from our perspective, for a lot of this to be successful it needs to be developer self-service, right? I mean, there's no, I mean, you talked about ticketing system and stuff like that. I mean, I think that's probably ancient, right? From what the future is about, you know, doing things using things like GitOps, right? Model, using tools that developers are already used to not kind of introducing more tools but making sure the infrastructure is built in a way where it can do things automatically with the right set of, you know, guardrails and governance in place, right? That's what we see as the future. Thanks so much. I know, I saw the time clock get back. I think we are short on time in here. So I was wondering if there's any questions from the audience to the panel, perhaps? Maybe we have one or two minutes. If not, I actually have one more questions in that case, but let's see. Okay, maybe this is again for all of you, like in terms like recommendations for any new organizations that just about to get started with multi-tendencies. What would be your first maybe suggestion? Maybe we start with Mohan. Yeah, sure. Yeah, I would recommend Start Simple, right? If you are new, brand new to the journey with Kubernetes, Start Simple. We tell people it's okay for it to cost more money in the beginning because you can always move from one pattern to another as you learn more. Your team has to have intimate knowledge of the Kubernetes landscape or you're gonna shoot yourself in the foot. So if you're new, Start Simple, it might cost you a little more, you can optimize later, right? So that would be our recommendation. Thank you so much, Ritesh. Prasita, you have any thoughts? Yeah, I would say that security is important, so least privilege principle to be applied for all your multi-tendents and start from there, generally like deny policy, and then from there on like keep, open it up for the tenants. Awesome, Ritesh, any last comments? Yeah, and just to add to both of these, I agree with both. And just to add to that, there's definitely a lot of proven models out there. So just don't, you know, just, I think just by doing some research, you should be able to get ideas of how others have successfully, you know, gone through their journey and settled on a model. And you know, if you can avoid a lot of mistakes by, you know, following those patterns and paths. Thank you so much. I know we are running out of time, so thank you so much again for the panel in here. And also thanks for the audience. I hope that you all find this insightful. If you have any more questions, the panel will be around in here. Please give the applause to the panel here. Thank you so much. Thank you.