 Hi, this is Yoho Sapil Bhartiya and welcome to another episode of TFI Newsroom and today we have with us once again Satya Sankaran, Chief Operating Officer of Cloud Casa by Katalogik. Satya, it's great to have you back on the show. Thank you, Swapnel. Always a pleasure talking to you. And today's discussion is going to be really interesting because soon Cloud Casa is going to be spun into an independent company. I mean, you folks have been on this journey before, so we are going to talk about that as well. But what is really interesting is that we are seeing a lot of consolidation in the market where traditional companies are acquiring companies that were born in the clouded era, but you folks are heading in a different direction. So talk a bit about what is driving this move? Yeah, look, I think spinouts in general are treated complex in the world because there's so many unknowns around it and it's not a usual thing that happens. In our DNA, we've already spun out once, so this is the second one. So there is a lot less concern about doing something like this because we've already done this once. So the company lineage itself is that Katalogik was born out of a spin-off in 2013. So I think first we know what this can achieve and as a founder of this team and someone trying to drive exceptional focus to the problems we are trying to solve, I think the primary driver is to get focus within the organization. And luckily, I think we were always structured for this day to come from practically day one and some because there were needs surrounding us and some because we knew this was a most likely outcome. Let's talk about what constrained us to build it this way and also what made us build it this way. So constrained us is we were at that point in a relationship with an IBM OEM. You know, in 2021, we had an exit to IBM, a part of our business was acquired by IBM. And we had to build these products with the Chinese wall effectively within the organization because we don't want any IP pollution, we don't want borrowing code from one product to build another product. So it was really built from scratch because we were again ensuring that there is no shared IP between these different products. And again, that shared IP would have meant that, you know, this IP becomes part of a transaction that we were in a relationship we were in that would most likely lead to the transaction that eventually happened, right? So we already had no shared IP as a result of that constraint. We already had specific teams because oftentimes team is the IP, right? So we had dedicated teams to these products. We were operating under one roof and that hasn't been the case in the last two and a half years. So I think in many ways, we were already operating as completely two separate business units within the same catalogic umbrella. Sales and marketing teams where their focus is shared, but I think part of this is ensuring that we get full focus on the problems we are each trying to solve. And in catalogic with its DPX product line, backup product line that is focused on Windows and Linux and file shares, you know, they're going to focus on the cybersecurity angle of it, which is to drive the guard mode offerings, early detection of ransomware and how do you get, you know, rolling back of the files that are impacted by ransomware. So I think they're going to focus on that. We're going to focus on the cloud native opportunity in front of us. And that requires, again, we need to devote all our brain, brain share to this solving this problem. And that's what we're really trying to accomplish. The end of the day, both these products deserve our full attention. And that means we're just going to have to run with separate teams to get the attention that these products deserve. You almost answered my next question. I was about to ask, why not just add Kubernetes protection to DPX, but you kind of already explained that point. The other main thing, Swapnel, I mean, customer profile was very different too. So it's not just, you know, where we needed to focus at time and energy. But it was also about, we had a customer base that was very heavy on Windows, Linux and file shares, and in that those aren't the customers that are making the transition to Kubernetes today. Kubernetes today is very developer centric platform teams that are using Kubernetes today. So very different audience. So I think the fact that we're now operating together is given our lineage, I mean, where we came from. It's a path dependent model where we're in this together. But if we started from scratch, this would be two completely different organizations and I think that's a realization and self-awareness. I think we've kind of built in our organization to make this move or pursue this move. And that's a perfect segue to my next question, which is about when we look at cloud native today, first of all, cloud native can be seen as a product or as a process, depends on how people look at it. There are multiple approaches. Of course, there are big companies, heavyweights, who have all the resources that they need to run at massive scale and deal with complexity that comes with things like Kubernetes. At the same time, there are newcomers, there are smaller companies who just want to leverage these technologies to create new businesses, which brings us to the point of kind of build versus buy. Let's look at data production. What is the right approach when we look at data production? Should we look at SaaS or should we look at self-managed backup? What do you think? Yeah. So I'll talk about two things. I think you mentioned that, hey, cloud native, what is cloud native, right? I think that's, that itself is a little bit up in the air. Everything that runs in the cloud is a cloud native, right? And that's not obviously the case, right? If you're born in the cloud, the anticipation is you would be using technologies that best suit the cloud, right? But there is a lot of lift and shift happening in the world as well. And in fact, the last few years, there is a lot of blind lift and shift, right? So there is just a strategic imperative to say, we want to move to an OPEX model. We want to be running everything in the cloud, data center, running a data center is not the business we want to be in. A lot of companies made that move, a lot of CIOs and CDOs made the move, and set very aggressive milestones because that's the only way to drive transformation in the business, right? You set aggressive milestones. If you don't set a deadline, nothing ever gets done, right? That's just the human nature in business. So there is a lot of lift and shift happening and that means eventually you're going to have to replatform it to something that will best utilize the cloud capabilities that are there. So not every application running in cloud today is cloud native, but it can be made cloud native. And in steady state, our view is that they will be made cloud native because part of running everything in cloud is to effectively utilize the resources you have available. So I think there would be a lot of efficiency changes and those efficiencies will lead to replatforming and Kubernetes is in prime spot because it is already evolving as the OS for the cloud, right? So when we think laptops, most of us think one or two things, which is either Windows or Mac, right? When you think servers now, everybody thinks primarily Linux and some Windows, right? So similarly, when we think cloud in future, I think we will think Kubernetes, right? That's the direction in that world is heading to and that's the direction we want to follow. And our job is to protect those workloads and drive more flexibility and agility with respect to the data you're running in. So when we look at Kubernetes workloads, we're looking at it as what is the platform this cloud native workloads are going to run in? And that is Kubernetes. And for that platform, how can we add value? And that to us is providing mobility for data, that is providing resilience for data, and that is providing protection for data. So those are three things that we want to deliver on top of that platform. And you asked one more question, SAS versus self-managed. I think there's a world where both exist. But what we have to recognize is 80% of Kubernetes users are saying, hey, I'm going to move to a SAS model or a hosted Kubernetes Engine model because Kubernetes is, by nature, a very powerful and flexible framework. But it is also a complex framework. So I'm going to let the complexity be handled by the professionals and the cloud providers, and I'm simply going to focus on running my workload on that provider. So it's more that the trend is moving towards cloud. And it's also where we've built a lot of optimizations. And it's a bet we made two years ago that we wanted our service to be in the cloud and for the cloud. And we thought a steady state, majority of Kubernetes users will run their workloads in the cloud. And so far, I think that bet has been turning out fine for us. Since cloud CASA is going to become an independent company, I also want to talk about the kind of size of this market where you are going to play a role. We all know that traditional data operation is a huge and sticky market. But how big is the cloud-needed data operation market? First, let's just try to figure out the magnitude of the market in the first place. And Kubernetes is an extremely hard ecosystem to quantify because everything is open source. It's an open source community. There is no one single source of truth when it comes to Kubernetes. There are several indicators, but not a lot of truth. And that I can give with any specificity, this is the size of the market. But I actually went through this exercise recently. I went through this exercise of trying to find out how many Kubernetes clusters exist in the world today. And my starting point was a recent report. A recent is all relative. But less than a year ago, there was this big report that made a lot of noise. 900,000 Kubernetes clusters were exposed in the Internet to queries that you could run. So I think there was an organization called Cybel that went through that crawl and found 900,000 clusters in the Internet, responded to an IPv4 space scan. So you just scanned all available IP address to see if you're a Kubernetes cluster and turned out 900,000 of them IP addresses are replied back saying, yes, I'm a Kubernetes cluster. So that's a starting point. And 900,000 Kubernetes clusters are exposed. And there are good reasons for why you expose managed control plan. A lot of the cloud providers today, I think, are exposing their control plan. So it's not necessarily a bad thing if you have all the right structure around it to secure it. But let's say 900,000 implied and 80-20 rule you apply towards how many of them are cloud versus these providers. I think you will kind of find that about 1.5 million clusters run in the cloud. And the big three cloud providers are a lion's share of that. But the lots of small providers that we were able to identify with somewhere between 5,000 and 10,000 clusters running as well from these scans. So you've got about 1.5 million clusters running in the cloud. And I think Dynatrace, the observability vendor, also put out a survey not too long ago, not a survey, the observation from about 4.1 billion pods that they collect observability data from. And what they were able to find is we are right now at a window where on-prem and cloud are going to cross each other in the sense that in 2023, they're expecting that we will hit a day in which we will have 50% on-prem and 50% on-cloud. Because today, it's mostly still on-prem, which is I think their prediction is 2022. On September, they observed 55% of workloads where on-prem and 45% was cloud. But cloud is growing a lot faster. And they saw in 2023, it will intersect. So let's say about 50-50 is what we have. So you've got 1.5 in the cloud, and you've got another 1.5 at least on-prem. So by our calculation, there's at least 3 million clusters out there. And there is also another CNCF survey that says about 50% of these people already run stateful workloads today. And stateful workloads are really the kind of workloads that people are going to be worried about backup and mobility and agility and all of these stuff. So in market, there are about 1.5 million clusters that needs to be protected. And an average node size in the cloud is five nodes. An average node size on-prem is about nine nodes. So you take an average, that's about seven nodes per cluster. So you're looking at 10 million worker nodes that needs to be protected today. That's a decent-sized market. And what we see is Vellero. There's a group of people that believe Kubernetes doesn't need to be backed up. They run it in cloud. That means they don't need to be the in-charger backup. Cloud guys are somehow doing that in the backend. All wrong. But let's not go to that world. Vellero has 50 million-plus downloads. And we think, conservatively, it is backing up somewhere between 500,000 clusters to a million clusters of the 1.5 we are talking about. And if you look at every commercial vendor out there, and we say this with a reasonable degree of confidence, all of these guys have only 100 customers and 150 customers and not a lot more. They're protecting 2,000, 3,000 clusters. But you're looking at a million and at 3,000 in the same spectrum. I think this is the same challenge we fight as a commercial vendor is that we are waiting for these million customers to switch over to a more enterprise-grade solution, but not a lot have moved because everybody is an early adopter of Kubernetes today. Barring exceptions. You may have a Chick-fil-A. You may have a Mercedes-Benz. But barring some exceptions, you've got pretty much everybody is early on in their adoption of Kubernetes, especially stateful workloads. So that shift will happen over time. But also, I think we can meet the customer where they are today. And again, part of our focus as an independent organization is to not just rely on this commercial model, which I think a steady state will probably get customers moving to when they're on enterprise scale. But you've got a world where you have two orders of magnitude bigger, customer-based sitting in the free and open source tool in Valero. We want to figure out a way to meet those users where they are and by adding value to what they're already running. And a lot of our focus as an independent company is going to be not just in remaining a commercial business, but also become friends of open source, not free and open source, but friends of open source and provide value add to what's missing in that community. Wow, that's huge. There are a lot of players, too. There are many traditional heavyweights who enter the market. And of course, there are many newcomers who were born in this era, which kind of makes me to the point of, what is your strategy to approach this market? Yeah, Sapnel, you know the concept of judo, right? In judo, being lighter actually helps you a lot because you can be a lot more nimble and reactionary. Look, some of these traditional players are, I've been in the space for 16 years. Some of these traditional players are role models for us. Like you look at a company like Weem. Weem is, for a founder like me, that's an inspiration, what they did with entering into a new space, seeding the market and effectively taking over that market. A great story, well, it's not run by their founders anymore. It's run by a VC firm, right? So things have changed. But what I think you have to recognize then is back then they were us today, right? They were small, nimble, focused extremely on one use case, right? Now you look at their story today. Their story today is they are the large render that needs to ward off competition, right? They need to protect their top very heavily. In fact, they're making architectural choices for Kasten that suggest their motivation is protection and not cannibalize existing business that their partners are driving them instead of taking the best approach for Kubernetes, which is to probably run it on SaaS and be completely cloud native, right? So I think you really think, Judo, it's not always gonna be successful, but you do have an advantage of being light and nimble and flexible and fast, right? I think that's how we see us in this model. Traditional backups and traditional backup vendors have two problems. They've always done business by knowing a priority what they are going to backup. That means knowing ahead what you are going to backup and sizing an infrastructure for it and building an appliance for it. And in fact, the only the two companies that made a lot of wave in the last few years is Rubrik and Cohesity, they came up with the auto scaling mechanism. You buy a brick by brick and keep adding the bricks and make it work, right? Perfect, but a true cloud native company has already solved that problem with auto scaling through Kubernetes, right? Scaling is not my problem anymore. I'm using a cloud and I can scale to cloud level. You don't need to decide and know what needs to be backed up and how it should be sized and how it should be structured ahead of time. I can react to demands on the flow. And I think that's something that companies like us born in the cloud can deliver that you're going to see traditional vendors struggle because transformation by definition is disruptive to the incumbents. And when it's disruptive, you strike compromises. When you strike compromises, customers don't like it and it provides an opportunity for somebody else that is going completely focused on that ecosystem. And that's really where we wanna be and that's where we want a seat at the table with these customers to say, hey, we have a better solution than anybody, any traditional vendor is able to come up with so far. Satya, thank you so much for talking to me today and discuss this announcement. And I look forward to our next discussion soon. Thank you. Awesome. And always a pleasure talking to you so far.