Clumio Data Protection for Google Cloud –

Machine-generated from the episode audio and not hand-corrected, so names and technical terms may be imperfect. The audio is authoritative.

All right, you're listening to a really special episode of the CTO Advisor podcast. We're here in beautiful Las Vegas at the Manly Bay doing Google Cloud Next. We have a returning guest from the Lightboard series, Woon Jong, CTO of Clumio. Woon, welcome back to the program. Nice to meet you, Dan. So you folks have, I don't think you coordinated this, Google Cloud Next is all about data. Data to support agentic workloads, but you folks specifically had timed an announcement around data protection for Google Cloud Next.

What's that announcement? We're at Google Next today to launch the support for GCS support, basically the backup of GCS. We've been with AWS for some time now, for the last eight years, we've been solely focused on protecting data sources on AWS, and this will be our first venture into GCP. So there's a bunch of data problems to solve around not just AI, but traditional workloads. You folks have your hands full with AWS. Why Google Cloud Next? Maybe why Google Cloud Next, not just the show, but why tackle the Google Cloud challenge next?

This really, we follow the customers, is really what they asked us to do, is what we're working on, literally. So over the last, again, five, six years, we've been working with a lot of the customers, and then they've been asking us, they've been asking us to actually provide the same experience and service that they have in AWS, in GCP, because they themselves are actually multi-cloud many times, and then that's what made us work on GCP. So what's different about GCP than AWS from the approach?

Because when people look at this, wow, this is just object storage. What makes backing up object storage hard from one cloud provider to the next? Obviously, honestly, a lot of the thing is common, is very much similar. A lot of the public cloud providers are converging, and then there's small differences here and there that we have to handle it, but that's what we do. A lot of the learnings that we have from AWS, we're going to bring it into GCP, and also along the way, address some of the differences so that our customers don't have to deal with that at all.

And specifically in the context of our launch of the GCS support, today Google doesn't have a native support for GCS backup. If you go back about five years ago, it's actually very similar to what we experienced with AWS. When we first launched the support for S3 backup with AWS, AWS didn't support S3 backups. It took them a little bit for them to launch. And even after that, once we launched, a lot of the customers used to tell us, you know, why bother protecting S3?

I have replication. And I'm guessing that a lot of the stuff, similar things will happen with GCP. It's in early days. We're going to get questions about, you know, GCS supports replication. Isn't that enough? Why do we need backup? You know, it is the initial innings. We're going to go through the same journey, but I expect the same things to happen over time where people will realize that the data in GCS needs to be protected beyond just replications because those are two different solutions that solve two different problems.

So there are folks that are natively born in GCP. I found this an intriguing part of the conversations that I've had while I've been here at Next is that there are folks that's never used a different cloud. So they're coming to this exact problem for the first time. Like they're born in the cloud, not just born in the cloud, they're born in GCP. So they have no point of reference. Talk about some of the failure domains that you're protecting as a result of going beyond just replication.

Yeah, I know. So in the case of replication, you know, like whatever happens in the source bucket gets replicated to the destination, right? Or you're replicating to. Correct. Whether that's a malicious attack or whatever, intentional deletions or unintentional deletions, everything gets replicated over. So then while replication solves the problem, really like the name says, it solves the problem of availability. When you actually lose one region, you have the other bucket where you can pick it up. But because every operation that happens on the source gets replicated on the destination, if let's say things get deleted or corrupted, that exact same accident happens on the replica, which doesn't really help you in that case.

And moreover, replication keeps the latest copy because, you know, as you make changes on the source, it happens on the destination. But if you want to time travel, like many times, you know, an accident happens, let's say five hours ago. If you want to, you know, time travel to five hours ago, you can't do that with replication. And that's kind of where backup comes into the picture. So replication protects from failures, but not necessarily from corrupted data or some business challenge where you need to revert back to a previous copy of the data.

And this is the escape. Yeah, exactly. It's completely different. Like, you know, you can call replication a backup, just like I won't be calling backup replication. It's different solutions. So a lot of the conversation around customer use cases have been multi-cloud. Google is exceptionally adept at helping customers connect to other clouds. So what's really tempting is to now look at my data landscape from an entire multi-cloud view, operational view. Can you talk to some of the unique challenges with Google Cloud or even the commonalities between Google Cloud and AWS when it comes to operations of data protection?

No. So a lot of the things are, well, outside of the fact that, you know, there's things that are supported in AWS, but not in GCP and vice versa, there's small differences. But again, that's what Clumio is about in solving. The idea is that no matter where you are, whether you are in GCP or in AWS, you configure a single policy to back up the resources either in AWS or in GCP, the same way that you do it in AWS, you do it in GCP.

Whether that be policy, whether that be APIs, configurations, or Terraforms, everything that you do through Clumio, we hide that behind the scenes. So you're just, guys, managing AWS like you're managing GCP or vice versa. So we're in the world of AI and everyone wants there to be an AI use case. Most organizations I know that you're talking to are just trying to get their data together, like this whole data protection, you know, I need to know how to protect my data before I talk about moving it.

But there is this desire to move data. How are customers embracing or what capabilities are you giving customers operationally to approach multi-cloud, either data movement or data protection? Yeah, so today we don't actively go ahead and move data between the cloud, but what we go ahead and do is basically simplify the management of it. It's like you treat AWS no different than GCP, Clumio single portal, single policy, single API and Terraform and configurations, and you get the same experience. With the two cloud providers being slightly different in terms of what they support and the characteristics and all that stuff to get scale and performance, you have to do things slightly different in the two cloud providers.

We hide all that for you. You just have to configure it in one place. There's no tools that you have to manage. There's no things that, you know, it's just one thing that you have to get it right. The customers I'm talking to are really worried about AI threat protection, like malware is becoming real. They, you know, we used to have security by obscurity. Hey, I'm a small company. No one is going to find my unsecured endpoint to maliciously attack.

Methos is changing that conversation. If you have open endpoints, if you have vulnerabilities, a $20 spend in AI tokens will find that. So the need to protect my data is even more prevalent. As you're talking to customers, how has the conversation changed, if customers are even keeping up with it, how has the conversation changed around protecting their workloads from malicious malware? A lot of the stuff is still the same. We're talking about AI and agentic and all that stuff is, you know, it's a theme.

But then the need to protect the data and all that stuff is still, you know, pretty much the same. Yes, you know, AI, LLMs and all that stuff. But, you know, at a high level, the way I see it is, you know, really garbage in, garbage out. You have to make sure that the data is well protected. The only difference, like you mentioned, some of the blast radius gets wider just because, you know, accidental deletions previously were done by a human.

Now it could actually be done by an agent that could actually expand the blast radius. But really, it's about the same thing. And the other thing that I started noticing, which is, if you think about it, some of the data that has been sitting in S3 or in the case of Google GCS, AI turns out to be a huge unlock. Because these are, you know, let's say a bunch of text, a bunch of blob data that sits there that you couldn't extract value out of it.

Now, with the AI, now you get an opportunity to extract value out of it, it just becomes a huge unlock. And some of the things that, you know, it wasn't important before, now it starts, you know, people start caring more about it. Moreover, specifically, you know, if I'm actually going and designing some of the applications, before there used to be data that, you know, things like log files, things like auxiliary data that, you know, I used to look at it and I say, okay, you know what, we're never going to need it.

Let's just go ahead and delete it. But I get to keep all that stuff more and more, because I know that in the future, leveraging AI, I should be able to extract value out of it. So a little bit of that is changing. But then at the same time, protecting the data, you know, is a constant. All right. So you just unlocked something that I really didn't consider, this ability that AI is allowing me to utilize my data, my log data, which I thought was useless.

Now I can put analytics against that data and get insights that I couldn't get before. But there was always a cost associated with not just keeping that data hot, but keeping it backed up. How are you helping me with cost? Not just in GCP, but across GCP and AWS, because I want to keep the same logs that I'm keeping in AWS. I want to keep that same telemetry data that might be slightly different, but I want to keep it in GCP as well.

Yeah. So the way that Clumio will support it is through giving you different tiers, right? So you can back it up into what we call the standard tier, which is, you know, hot backups, right? If something happens, you can get it back immediately. But then we also have what's called the archive tier that, you know, at a much lower price point. But obviously, when you need it, you do have to wait for the thawing time, right? Right. So we'll actually help you with those two tiers.

But it's really about trade-off, right? You talked about how much does it cost me to maintain the data, and what's the trade-off in between the two? The other trade-off is the value, like how much value you assign to that data, and how much does it cost you to keep it around? Now I think with AI, what happens is the value that you can extract out of it, that went up a little bit. Now your motivation to keep that data a little longer equally just goes up a little bit.

I'm not saying by no means keep every data, but now it increases the, you know, the surface area. And I think this is where we're leaving it, like the call to action isn't the traditional, hey, if you want to learn more about Clumio, I think it's more if you want to have these deeper conversations. If you want to have the conversations about the trade-offs, if I want to use my data as an operational tool as I'm starting to look at agentic AI, where is data being leveraged?

Where should I place GPUs? Should I invest in Bedrock versus BigQuery? All of these questions become architectural questions. And these are questions I think CTOs and their staffs are better suited to have directly with Clumio. So the call to action isn't just how do I learn more about Clumio, but how do I help organizations solve this problem? And I think the easiest way to do that is, what's the website? com. com. If you want to learn more about the CTO Advisor, you can visit us on the web.

com after 10 years, or the traditional website, the CTO Advisor. You want to follow me on the web and you want to ask me the questions, I have an axe wound, DMs are open at CTO Advisor or on LinkedIn. Talk to you next, CTO Advisor podcast.