 The Cube presents KubeCon and CloudNativeCon Europe 2022, brought to you by Red Hat, the CloudNative Computing Foundation and its ecosystem partners. Welcome to the Cube coverage of KubeCon 2022 EU. I'm here with my co-host Paul Gill. Pleased to work with you, Keith. Nice to work with you, Paul. And we have our first two guests. The Cube is hot, I'm telling you. We are having interviews before the start of even the show floor. I have with me, we got to start with the customers first. Enterprise architect, Anand Khan, welcome to the show. Thank you so much. Cube time, Cube time first. Now you're a Cube alumni. Yep. There you go. And Haseeb Habani, CEO, Arathi, welcome back. Nice to talk to you again today. So we're talking all things Kubernetes and we're super excited to talk to MoneyGram about their journey to Kubernetes. First question I have for Anand. Talk to us about what your pre-Kubernetes landscape looked like. Yeah, certainly, Keith. So we had a traditional mix of legacy applications and modern applications. A few years ago, we made the decision to move to a microservices architecture. And this was all happening while we were still on-prem. So your traditional VMs. And we started 20, 30 microservices, but with the microservices pattern, you quickly expand to hundreds of microservices. And we started getting to that stage where managing them without sort of an orchestration platform, and just as traditional VMs, was getting to be really challenging, especially from a day to operational. You can manage 10, 15 microservices, but when you start having 50 and so forth, all those concerns around high-availability operational performance. So we started looking at some open-source projects in a Spring Cloud. We are predominantly a Java shop, so we looked at the Spring Cloud projects. They give you a number of initiatives for doing some of those management. And what we realized, again, to manage those components without sort of a platform was really challenging. So that kind of led us to sort of Kubernetes, where along with our journey to cloud, it was the platform that could help us with a lot of those management operational concerns. So as you talk about some of those challenges pre-Kubernetes, what were some of the operational issues that you folks experienced? Yeah, you know, certain things like auto scaling is number one, right? I mean, that's a fundamental concept of cloud native, right, is how do you auto-scale VMs, right? You can put in some old methods and stuff, but it was really hard to do that automatically, right? So Kubernetes with like HPA gives you those out of the box, right? Provided you set the right policies, you can have auto-scaling where it can scale up and scale back. So we were doing that manually, right? So before MoneyGram, obviously, you know, holiday season, people are sending more money, on Mother's Day, our ops team would go and basically manually scale VMs, right? So we'd go from four instances to maybe eight instances, right? But that entailed outages, right? And just to plan around doing that manually and then sort of scale them back was a lot of overhead, a lot of administration overhead, right? So we wanted something that could help us do that automatically, right? In an efficient, unintrusive way, so. So, you know, that was one of the things, monitoring and management operations, you know, just kind of visibility into how those applications were doing, what was the status of your workloads was also a challenge, right? To do that. So, you see, I gotta ask the question, if someone would've came to me with that problem, I'd just say, you know, go to the public cloud. You know, the what, how does your group help solve some of these challenges? What do you guys do? Yeah, what do we do? So, here's my perspective on the market as it's playing out. So I see a bifurcation happening in the Kubernetes space. So there's the Kubernetes runtime, so Amazon is EKS, Azure is AKS, you know, there's enough of these available, they're now managed services, they're actually really good, frankly. Right, in fact, retail customers, if you're in Amazon, why would you spend up your own, just use EKS, it's awesome. But then there's an operational layer that is needed to run Kubernetes. My perspective is that 50,000 enterprises are adopting Kubernetes over the next five to 10 years, and they're all gonna go through the same exact journey, and they're all gonna end up potentially making the same mistake, which is they're gonna assume that Kubernetes is easy. They're gonna say, well, this is not hard, I got this up and running on my laptop, this is so easy, no worries, right? I can do EKS, but then, okay, can you consistently spin up these things? Can you scale them consistently? Do you have the right blueprints in place? Do you have the right access management in place? Do you have the right policies in place? Can you deploy applications consistently? Do you have monitoring and visibility into those things? Do your developers have access when they need it? Do you have the right networking layer in place? Do you have the right charge backs in place? Remember, you have multiple teams. And by the way, nobody has a single cluster, so you gotta do this across multiple clusters, and some of them have multiple clouds. Not because they wanna be multiple clouds, because sometimes you buy a company, and they happen to be in Azure. How many dashboards do you have now? Across all the open source technologies that you have identified to solve these problems. This is where pain lies. So I think that Kubernetes is fundamentally a solved problem. Like our friends at AWS and Azure, they've solved this problem. It's like AKS, EKS, et cetera, GKE for that matter. They're great, and you should use them, and don't even think about spinning up QB and AMBS clusters. Don't do it. Use the platforms that exist. And commensurately on-premises, OpenShift is pretty awesome, right? If you like it, use it. But then when it comes to the operations layer, that's where today we end up investing in a DevOps team, and then an SRE organization that need to become experts in Kubernetes. And that is not tenable, right? Can you, let's say unlimited capital, unlimited budgets. Can you hire 20 people to do Kubernetes today? If you can find them. If you can find them, right? So even if you could, the point is that, see, five years ago, when your competitors were not doing Kubernetes, it was a competitive advantage to go build a team to do Kubernetes so you could move faster. Today, you know, there's a high chance that your competitors are already buying from a RAFE or somebody like RAFE. So now, it's better to take these really, really sharp engineers and have them work on things that make the company money. Writing operations for Kubernetes, this is a commodity now. How confident are you that the cloud providers won't get in and do what you do and put you out of business? Yeah, I mean, absolutely. I think, I mean, in fact, I had a conversation with somebody from AWS this morning and I was telling them, I don't think you have a choice. You have to do this, right? Competition is not a bad thing, right? If we are the only company in a space, this is not a space, right? The bet we are making is that every enterprise has, you know, they have a non-prem strategy, they have at least a handful of, everybody's got at least two clouds that they're thinking about. Everybody starts with one cloud and then they have some other cloud that they're also thinking about. For them to only rely on one cloud's tools to solve for on-prem plus that second cloud that potentially they may have, that's a tough thing to do. And at the same time, V as a vendor, I mean, the only real reason why startups survive is because you have technology that is truly differentiated, right? Otherwise, right? I mean, you got to build something that is materially interesting, right? V seem to have, sorry, go ahead. No, I was going to ask you, you actually had me thinking about something, a non-moneyground, big, well-known company, a startup, working in a space with Google, VMware, all the biggest names, what brought you to Rafi to solve this operational challenge? Yeah, good question. So when we started out, sort of in our Kubernetes, you know, we had heard about EKS and we are an ABWS shop, so that was the most natural path and we looked at EKS and used that to create our clusters. But then we realized very quickly that, yes, to Haseeb's point, AWS manages the control plane for you, it gives you the high availability, so you're not managing those components, which is some really heavy lifting, right? But then what about all the other things, like centralized dashboard, what about we need to provision Kubernetes clusters on multi-cloud, right? We have other clouds that we use or also on-prem, right? How do you do some of that stuff, right? We also, at that time, we're looking at other tools also and I had, I remember, come up with an MVP list that we needed to have in place for day one or day two operations, right, to before we even launch any single applications into production. And my ops team looked at that list and literally there was only one or two items that they could check off with EKS. You know, they've got the control plane, they've got the cluster provision, but what about all those other components? And so that kind of led us down the path of looking at, hey, what's out there in this space and we realized pretty quickly that there weren't too many. There were some large providers and capabilities like Anthos, but we felt that it was a little too much for what we were trying to do, you know, at that point in time. We wanted to scale slowly, we wanted to minimize our footprint, and Raffae seemed to sort of was a nice mix, you know, from all those different angles. How was the situation affecting your developer experience? So that's a really good question also. So operations was one aspect of it, right? The other part is the application development, right? We've got MoneyGram as when a lot of organizations have a plethora of technologies, right? From Java to .NET to Node.js, what have you, right? Now, as you start saying, okay, now we're going cloud native and we're going to start deploying to Kubernetes, there's a fair amount of overhead because a tech stack all of a sudden goes from, you know, just being Java or just being .NET to things like Docker, right? All these container orchestration and deployment concerns, Kubernetes, deployment artifacts, right? I got to write all this YAML, as my developers say YAML hell, right? I got to learn Docker files, I need to figure out a package manager like Helm on top of learning all the Kubernetes artifacts, right? So initially we went with sort of, okay, you know, we can just train our developers, right? And that was wrong, right? I mean, you can't assume that everyone is going to sort of learn all these deployment concerns and we'll adopt them, right? There's a lot of stuff that's outside of their sort of core Dev domain that you're putting all this burden on them, right? So we could not rely on them and to be sort of Kube-Cuttle experts, right? There's a fair amount of overhead learning curve there. So Rafa, again, from their dashboard perspective, right? So the managed Kube-Cuttle gives you that easy access for Devs, right? Or they can go and mount it to the status of their workloads. They don't have to figure out, you know, configuring all these tools locally just to get it to work. We did some things from a DevOps perspective to basically streamline and automate that process. But then also Rafa sort of came in and helped us out on kind of that, providing that dashboard, they don't have to worry they can basically get on through a single sign on and have visibility into the status of their deployment. They can do troubleshooting, diagnostics, all through a single pane of glass, right? Which was a key, key item. Initially before Rafa, we were doing that command line, right? And again, just getting some of the tools configured was huge, right? Took us days just to get that and then the learning curve for development teams, right? Oh, now you got the tools, now you got to figure out how to use it, right? See, talk to me about the cloud native infrastructure. When I look at that entire landscaping number, I'm just overwhelmed by it as a customer. I look at it and I'm like, I don't know where to start, I'm sure. Or not, you folks looked at it and said, wow, there's so many solutions. How do you engage with the ecosystem? You have to be at some level opinionated, but flexible enough to meet every customer's needs. How do you approach that? Yeah, so it's a really tough problem to solve because, so the thing about abstraction layers, you know, we all know how that plays out, right? So abstraction layers are fundamentally, never the right answer because they will never catch up, right? Because you're trying to write and layer on top. So then we had to solve the problem, which was, well, we can't be an abstraction layer, but then at the same time, we need to provide some sort of, sort of like centralization, standardization, right? So we sort of have this, the following dissonance in our platform, which is actually really important to solve the problem. So we think of a stack as sort of four things. There's the Kubernetes layer, infrastructure layer, and EKS is different from EKS, and it's okay. If we try to now bring them all together and make them behave as one, our customers are going to suffer because there are features in EKS that I really want, but then if you write an abstraction layer, I'm not going to get them, so not okay. So treat them as individual things and bring them to logic that we now curate. So every time EKS, for example, goes from 1.22 to 1.23, we write a new product, just so my customer can press a button and upgrade these clusters. Similarly, we do this for AKS, we do this for GK. It's a really, really hard job, but that's the job, we got to do it. On top of that, you have these things called add-ons, like my network policy, my access management policy, my et cetera, right? These things are all actually the same. So whether I'm in EKS or AKS, I want the same access for Keith versus a nun, right? So then those components are sort of the same across, doesn't matter how many clusters as many memory clouds. On top of that, you have applications. And when it comes to the developer, in fact I do the following demo a lot of times because people ask the question, right? People say things like, I want around the same Kubernetes distribution everywhere because this is like Linux, actually it's not. So I do a demo where I spin up access to an OpenShift cluster and an EKS cluster and an AKS cluster and I say, log in, show me which one is which. They're all the same. But make that real for me. I'm sure after this amount of time, developers, groups have come to you with things that are snowflakes. And as an enterprise architect, you have to make it work within your framework. How has working with Rafi made that possible? Yeah, so I think one of the very common concerns is the whole deployment, right? To Haseeb's point, right, is you're from a deployment perspective, it's still using Helm, it's still using some of the same tooling, right? But how do you, Rafi gives us some tools, they have a command line, R-Cuttle API that essentially we use. We wanted parity across all our different environments, different clusters, doesn't matter where you're running. So that gives us basically a consistent API for deployment. We've also had challenges with just some of the tooling in general, that we worked with Rafi actually to actually extend their R-Cuttle API for us so that we have a better deployment experience for our developers, so. Haseeb, how long does this opportunity exist for you? At some point do the cloud providers figure this out, or does the open source community figure out how to do what you've done and this opportunity is gone? So I think back to a platform that I think very highly of, which has been around a long time and continues to live vCenter. I think vCenter is awesome, and it's beautiful, we've done an incredible job. What is a job? A job is to manage VMs, right? But then it's also access, it's also storage, it's also networking and a sex, right? All these things are done because to solve a real problem you have to think about all the things that come together to help you solve that problem from an operational perspective, right? My view is that this market needs essentially a vCenter, but for Kubernetes, right? And that is a very broad problem, right? And it's going to span, it's not about a cloud, right? I mean, every cloud should build this. I mean, why would they not? It makes sense, Anthos exists, right? Everybody should have one. But then the clarity in thinking that the RAFI team seems to have exhibited till date seems to merit an independent company, in my opinion. I think, I mean, from a technical perspective, this product is awesome, right? I mean, we seem to have no real competition when it comes to this broad breadth of capabilities. Will it last? We'll see, right? I mean, I keep doing cube shows, right? So every year you can ask me that question again. And we'll see. You make a good point, though. I mean, you're up against VMware, you're up against Google, they're both trying to do sort of the same thing you're doing, why are you succeeding? Maybe it's focused, maybe it's because of the right experience. I think startups only in hindsight can one tell why a startup is successful in all honesty. I've been in one or two startups in the past. And there's a lot of luck to this. There's a lot of timing to this. I think this timing for a product like this is perfect. Like three, four years ago, nobody would have cared. Honestly, nobody would have cared. This is the right time to have a product like this in the market because so many enterprises are now thinking of modernization. And because everybody's doing this, this is like the bootstorm problem in HCI. Everybody's doing it, but there's only so many people in the industry who actually understand this problem. They can't even hire the people. And the CTO said, I got to go, I don't have the people. I can't fill the seats. And then they look for solutions. And via that solution that we're going to get embedded. And when you have infrastructure software like this embedded in your solution, we're going to be around, assuming obviously we don't screw it up, right? We're going to be around with these companies for some time. We're going to have strong partners for the long term. Well, the center for Kubernetes, I love to end on that no intriguing conversation we could go on forever on this topic because there's a lot of work to do. I think, I don't think this will over be a solved problem for the Kubernetes or cloud native solution. So I think there's a lot of opportunities in that space. Haseeb, Haseeb, how about it? Thank you for rejoining theCUBE, non-con. Welcome becoming a CUBE alum. You get your own profile on the CUBE website. It's really cool. From Valencia, Spain, I'm Keith Townsend along with my host, Paul Gillan. And you're watching the CUBE the leader in high tech coverage.