 Hi, this is Hosoklin Bhartiya and welcome to T3M, our topic of this month and topic of this month is data and today we have with us Martin Fan, field C2 at Cloud Casa Back at Logic. Now Martin, it's great to have you back on the show. Great to be back. Thanks for having me. And today we are going to talk about name space as service and what are the some of the data challenges that it's also so talk a bit about from Cloud Casa's perspective. To consider namespace as a service, you have to understand a little bit about Kubernetes and software as a service in general, right? So with Kubernetes, we have this ability to spin up applications pretty much with a click a button or like a declarative one line command statement. And as users are spinning up these services, they are hosting these services within clusters. And part of the reason why namespace as a service has become so prevalent is because users don't really want to deploy multiple clusters for each application or service that they're looking to host within their website or within, let's say, their application. So what namespace as a service entails entails is the fact that you want to subdivide that Kubernetes cluster even further, right? Users wanting to do more with less in other words for hosting their applications. So that's how we get we come to namespace as a services to actually subdivide it and segregate isolate the services within the cluster down to their individual namespaces such that you can secure that application within namespace and only provide users that should have access with access to that service. How widely it's been used within the Kubernetes ecosystem? What kind of awareness there? What kind of demand is there for it? I think it's still within its early phases, right? Users are still in the process of adopting Kubernetes, but just like we saw with, you know, I like to use the VMware and physical server analogy where users wanting to do more with less have basically consolidated their applications or multiple operating systems onto one physical host, right? And as users start to adopt Kubernetes more and start hosting their services and their application pods within Kubernetes, we're starting to see more of a shift towards that software as a service application. These cloud native applications running within a single cluster, there is limitations in terms to how those applications can then be secured. So now we're starting to see the shift of these ephemeral one-time workloads that are being hosted within Kubernetes just spun up for let's say a matter of a day or weeks now becoming more along the lines of monolithic applications, almost like a cloud cost. So we're hosting our own cloud cost application, as you know, within Kubernetes. It is a Kubernetes application and we're now wanting to segregate our environments such that we can run multiple applications or services within a single cluster and then further protect those applications through namespace as a service. So I think while we're still in the early phases of adoption here, I think this will become a very prevalent use case moving forward in the future as users begin to adopt more Kubernetes workloads and look to secure those workloads within namespace as a service. Can you just specifically talk about what are the benefits of namespace as a service for Kubernetes backup and recovery? We're looking at it from a cost perspective, data governance perspective. If you are backing up and protecting Kubernetes and applications, if a user has access to a Kubernetes cluster, they basically have access to the control plane, the central database, the SCD database that is hosting the applications and has all the definitions for those applications. With cloud cost, we make it very easy to back up it and migrate and recover namesfaces and pods within Kubernetes. That ease could provide some malicious actor the ability to come in and backup, let's say an application then restore to a cluster, entirely separate cluster. Just by the mere fact that they have access to the main cluster, they have access to all the underlying applications underneath it. Right. So with namespace as a service, what we're doing in our partnership with Class 6 and their module capsule is we are allowing for tendencies to be created within the cluster. That is the ability to segregate that cluster even further so that users will only have access to specific namespaces within that cluster. And cloud cost will then, through its own rule-based access control, filter down those namespaces down to their own component levels and ensure that the cloud cost user that's trying to perform a backup or recovery of the pod or namespace within the cluster actually has access to that namespace. If we look at just backup and recovery space, can you draw a contrast from the traditional on-prem experience versus cloud native or Kubernetes experience and how you folks specifically look at namespace as a service help users protect their data? That's a great question. And I'm going to answer it, just basically speaking in terms of cloud native applications and Kubernetes backups, because as you know, the cloud cost, which was spun off from the catalogic software, we also have a data protection application, DPX and DPXV+, among others that actually protect on-prem, your traditional backup and recovery, as you mentioned, with agents and with Kubernetes and cloud native applications that completely change the paradigm from how we protect these cloud native workload states. The beauty of cloud cost is that we are cloud aware, we integrate natively with the cloud. So, and I'm talking, you know, some of the big three cloud providers, Amazon, Microsoft, Google, right, we integrate and have native integration directly into those clouds to perform discovery and actually build clusters with a click of a button on the fly, something that we call full stack recovery or any to cloud recovery. And that's a really cool feature that we have from a native integration standpoint, but from an on-prem, off-prem, you know, where the cluster is located from a Kubernetes perspective, it really doesn't matter to us, right, from a cloud cost perspective, right? In the fact that the agent that is deployed is a similar manifest file or the same manifest file actually between deploying on a cloud or an on-prem resource, that agent is going to do the exact same thing as it would do within the cloud and possibly more, right? So, we're collecting the underlying metadata, we're interrogating the cluster itself. We are, and from a cloud perspective, we're interrogating the actual cloud APIs as well, what type of back and storage, for example, what storage classes are made available to that cluster. And now with this integration and with a classics and capsule to provide us with that granular level of focus, namespace as a service, right, we're going to be able to filter even further and subdivide even further such that users who, let's say, as they're growing their Kubernetes infrastructure, but consolidating applications into, let's say, one large cluster with many worker nodes, they're now able to subdivide each and every single namespace down and then just provide access to those users. The best part is that the end user really has no knowledge of the fact that the namespaces are being filtered. They just see what they see, they can back up what they can back up and they can restore what they can restore, and that's really the beauty of it. Do teams need a different approach when they want to leverage namespace service or it really doesn't affect their own workflow? The aspect of the administrator, the Kubernetes administrator, they're going to require some setup, it's an additional pod, so they're going to need to install the Class Six Capsule module to their cluster, but then from once installed, they're going to be able to create rules and access permissions within that cluster that will then be reported back to the CloudCosta server, and that's kind of the integration that we have with Class Six Capsule module is they have an add-on component that basically mirrors the rules and permissions back to CloudCosta. CloudCosta does the rest in terms of filtering out those namespaces that that user should only see, and then because that user can only see certain namespaces and certain pods, they're only going to be able to access and back up and restore those namespaces and pods, so from the end user perspective, you're not the Kubernetes cluster administrator, you're not the data protection administrator, you're not going to experience any change or change to your workflow or change to your infrastructure that you're going to be aware of or that you'll need to know about, you'll just be defining back as your stores just as you normally would, and that's how we designed it. Martin, thank you so much for taking time out today and talk about this topic, and as usual, I would love to chat with you again. Thank you. Appreciate it, thanks for having me against what you do.