CloudCasa helps with data protection, data migration, and disaster recovery In Amazon EKS
In the recent episode of TFIR Insights, Catalogic’s VP of Global Sales, Ryan Kaw to discuss how CloudCasa helps with data protection, data migration, and disaster recovery In Amazon EKS with Swapnil Bhartiya, CEO and Show host of TFIR. Martin Phan, Field CTO – North America, also gives a demo of CloudCasa during this episode.
Moving Kubernetes applications to the public cloud helps developers focus mostly on adding business value to their applications, while also ensuring scalability and high availability, including across regions and across clouds. However, it doesn’t magically solve all challenges for them that come with Kubernetes applications.
Ryan talks about some of the misconceptions around moving Kubernetes applications to the cloud, especially in terms of high data availability, data migration, multi-region spport, data restore and more.
Earlier we hosted your COO Sathya Sankaran and he talked about how CloudCasa is addressing the data production weaknesses of Kubernetes and redefining how data production should be delivered. Today. We are going to talk mostly about data protection, data migration, and disaster recovery for applications on AWS EKS. There seems to be a misconception that once you move to cloud, cloud takes care of almost everything, of course, high availability and scalability can be expected but the same can’t be said for data protection or security. So what do you have to say, just because somebody moved their Kubernetes applications to a public cloud, should they still worry about high availability data protection?
Yeah, definitely. So you're correct. I do think that there is a misconception, there are tons of people moving their data into the cloud, and it does provide high availability, but there's a difference between high availability and high data availability as well. Uptime doesn't translate to the elimination of downtime, right? So when you think about certain things like configuration from a user, maybe they've accidentally deleted a cluster... I was just talking to a prospect last week and it was an infrastructure manager. They have their stuff on-prem though. But he was telling me how there's some shadow IT going on.
And they started dabbling into the Kubernetes space too. And he was doing a data center migration. And long story short, during this migration process, they actually had data loss. And the developer was like, "Hey, where did my data go?"
He's like, "I didn't even realize you had this stuff, or did you need it to be protected for that matter?" Granted, it was only a testbed in the environment, but still, if that data was being protected, it could have saved them a ton of time from reconfiguring that cluster, bringing it back, and then also repopulating that data in regards to the persistent volume. We also see other scenarios as well in regard to things like auditing, where you might be asked to go ahead and bring an application configuration back to a specific point in time, as well. So, I certainly do think if somebody's leveraging data protection in their environment using something like CloudCasa, it certainly would behoove them.
Thanks for sharing that example. I am sure there are many customers who have experienced that. Now, when we talk about AWS or public cloud in general, it’s a crowded space even for data protection and data recovery. Generally, people look at it as ‘all we need is to restore the data. It’s also a sticky market. So can you tell our viewers how does CloudCasa differentiate itself from other players which may include the cloud provider themselves, incumbent data protection vendor, or even some open source projects?
So, I think a couple of things that come into my mind as far as from a differentiation standpoint, is first off, we’re a SaaS solution. So, from deployment and getting off the ground and running, it’s very, very quick. You sign up on our website and then you just start registering your clusters and installing it from there.
And with us, especially in regard to EKS, there’s inventories, automatic inventories, because we plug into AWS cloud foundation as well. And then also bare metal recovery, like that patent I was telling you about. Some people don’t really talk about licensing. I think we’re very unique from a licensing standpoint too, where all of our competitors out there, are licensing on worker nodes versus where we’re going from a capacity standpoint, which is certainly beneficial to users in the Kubernetes space.
One more thing I want to talk about is customers’ ability to do cross-cluster and cross-account restores in the same cloud. Can you talk about some use cases where customers need such capability or more broadly, why it’s needed?
Yeah, absolutely. And I’ll give you a real-life example. So there’s a large pharma company that’s leveraging cloud cost today for that specific reason. Cross cluster resource, cross-account restore as well. So specific to their environment, they have a production environment, with a prod AWS account, and a dev environment with a dev account as well. And what they really needed to do was take that data from prod, and move it over to their development for test and dev purposes. And we helped achieve that. And obviously, when we go through a product demonstration, you’ll be able to see that firsthand as well. As far as, why do I think they’re doing that? I think there’s really three main reasons. One being security in the respect that you probably do not want to give your developers access to the prod environment.
Number two is development speed. If you have a developer in your prod environment, they’re going to be a little bit hesitant on what they can bring up, what they can bring down, et cetera, as well. So giving them their own playpen, and their own environment is crucial. And then from a billing aspect as well, to financially understand where is your money going towards? So that’s why you have those different pockets and segregation as well too.
Thanks for sharing those three reasons why people may need it, what about cross-cloud store. I mean we live in a multi-cloud world people run workloads in different clouds for different reasons. How realistic is the cross-cloud restore?
Yeah, so I think when we look at Kubernetes environment and as environments are continuing to scale and to have many more and more and more clusters, you’re going to have different cloud providers as well. I think every cloud provider has specific incentives for you to host it over there versus here. From our perspective, we want to be agnostic. At the end of the day, we just want to support where you’re going to, you obviously have your benefits, and so forth. But as these things continue to scale up and you try to do things manually per se, it is very, very difficult.
And I think with our solution, having a central management pane of glass for wherever your environment is, whether it’s on-prem or in various areas of the cloud, I think that’s certainly key as well. Nobody wants to be locked into a specific vendor anymore.
And then I think if you look at, from a business continuity standpoint as well, one cloud provider may go down for whatever specific reason. You’re going to want to host it at somewhere else. But at the same time, what if you’re required to protect that data as well? So we can go ahead. We don’t really care as long as you register our clusters, we’ll be able to go ahead and protect it. And I think, as I said, the specific thing, especially unique to EKS is the auto-discovery of your clusters. Being able to pick up any new clusters that you deploy, apply it to a specific policy, and get that stuff backed up. And then in the event that you ever need to restore, that you have that bare metal recovery feature, or if you want to restore it to a new cluster or something else, or the original one, we give you all of that flexibility as well.