 From San Francisco, it's theCUBE, covering Day2IQ. Brought to you by Day2IQ. Hey, welcome back everybody. Jeff Frick here with theCUBE. We're at Day2IQ's headquarters in downtown San Francisco. They used to be Messel Sphere, which is what you might know them as, and they've rebranded earlier this year. And they're really talking about helping enterprises in their journey to cloud native. And we're really excited to have really one of the product guys who's been here and seeing this journey and out there with the customers helping the company transform. And it's Chandler Hozington. He's the SVP of engineering and product. Chandler, great to see you. Thanks. So first off, give everyone kind of a background on the Day2IQ. I think a lot of people knew Messel Sphere, you guys have been around, making noise. What kind of changed in the marketplace to do a rebranding? Sure. Yeah, we've been obviously Messel Sphere in the past and Mesaus, I think a lot of people watching theCUBE knows about Mesaus. As we were going along our journey as a company, we noticed that a lot of people are also asking for Kubernetes help. So we've actually been working with Kubernetes since, I don't know, 2016, 2017, something like that, for a while now. And as Kubernetes ecosystem started to evolve and mature more, we also wanted to jump in and take advantage of that. And we started building some products that were specific to Kubernetes. So we thought, look, it's a little bit confusing for people, Mesaus and Kubernetes. At times, those two technologies were seen almost as competitive, even though we didn't always see it that way. The market saw it that way. So we said, look, this is gonna be confusing for our customers, being called Mesausphere. Let's rebrand around more what we really do. And we felt like what we do is not just focused around one specific technology, we felt like we help customers with more than that. More than just Mesaus support, more than just Kubernetes support. And we said, look, let's get us a name that shows what we actually do for our customers. And that's really helping them take their workloads and put them on not just a Mesaus platform, but actually take their workloads, bring them into production in an enterprise way that's really ready for day two. And that's why we called it day two. And let's unpack the day two, because I think some people are really familiar with the concept of day two. And for some people, they've probably never heard it, but it's a pretty interesting concept. And I think it packs a lot of meaning in a short number of letters. I think you can kind of just think about it if you were writing software, right? I mean, day zero is, okay, we're going to design it. We're going to start playing with some ideas. We're going to pull in some different technologies. We're going to do a POC. We're going to build our skateboard, so to say. That's kind of your day zero. What do we want? Okay, we're going to build a data analytics pipeline. We want Spark. We're going to store data in Cassandra. We're going to use Kafka to pass it around. We're going to run our containers on top of Kubernetes. That's just kind of your day zero idea. You get it working. You slap it on a cluster, things are good, right? Day one might be, okay, let's actually do a beta or put it in production in some kind of way. You start getting customers using it. But now in day two, after all that's done, you're like, wait a second, things are going wrong. Where's our monitoring? Oh, we didn't set that up. Where's our logging? Oh, I don't know. Who do we call? Our container runtime we think has a bug. Who do we call? Oh, I don't know. What support contract did we cut? So that's the things that we want to help customers with. We want to help them in the whole journey, getting to day two, but once they're there, we want them to be ready for day two. Right. And that's what we do. I love it, because one of my favorite quotes I've used it a thousand times, I'll do it a thousand one, right? Is that open source is free like a puppy. Right. Exactly. It's free when you leave. You're not writing a check necessarily to the shelter, but there's a whole lot of other checks you got to write and take care of. That's right. And I think that's such a key piece to enterprise, right? They need somebody to call when that thing breaks. Yeah, I mean, having come from an enterprise company, I was actually a customer of Mesa Sphere before I joined. Yeah, that's exactly why we are customers, is that we wanted not only that insurance policy, but someone to partner with us as we started figuring this out. Right. I mean, just picking what container runtime do I want to use with Kubernetes, that one decision could take months if you're not familiar with it and you put a couple of your best architects on it, go research container, you go research cryo, go research Docker, tell me what's the best one we should use with Kubernetes. Whereas if you're going, if you have a partnership with a company like day two, you can say, look, I trust this company, they are experts at this, and they see a lot of this. Let's go with their recommendation, it's a lot easier. Okay, so you got your whiteboard, you've got a whole bunch of open source things going on, right, and you got a whole bunch of initiatives and the pressure's coming down from on high to get going, you've got containerization and cloud data and hyper cloud and all this stuff. And then you've got some port CIO and his team been trying to figure it out. You guys have a whole plethora of services around some of these products. So as you try it, and then you got the journey, right? And you don't start from the standing start, you gotta go. So how do you map out the combination of how people progress through their journey, what are the different types of systems that they want to put in place, and to prioritize and have some type of a logical successful implementation and roll out of these things from day zero, day one, through day two. No, that's a great question. I think that's actually how we formed our product strategy is we've been doing this for a while now and we've gone on this journey with really big advanced customers like ridesharing companies and large telcos, customers like that. We've also gone on this journey with smaller, less sophisticated customers like industrial customers from the Midwest, right? And those are two very, very different customers. But what's similar is they're both going on the same journey we feel like, but they're just at different places in it. And so we wanted to build product to find the customer where they're at in that journey. And the way we see it really is just, at the very beginning it's just training, right? So we have a bunch of support and, or sorry, services around training that help you understand not just Kubernetes but the whole cloud native ecosystem. So what is all this stuff? How does it work? How does it fit together? How do I just deploy a simple app to it, right? That's the beginning of it. We also have some products in that area as well to help people scale their training across their whole organization. So that's really exciting for us. Once that customer has their training down, they're like, okay, I need a cluster now. Like I need a distro of sorts. And Kubernetes itself is great, but it needs a lot of pieces to actually get it ready for prime time. And that's where we built a product called Convoy to say, okay, here is your enterprise grade ready to go Kubernetes distro right out of the box. And that product is really, it's what you could use to just fiddle around with Kubernetes. It's also what you put into production right out of the game. That's been scale tested, security tested, mixed workload tested, everything. So that's kind of our Kubernetes distro. So you've gotten your training, you have your distro and now you're like, okay, I actually want to run some apps on it. So let me hold your, is it open core? Or there's a lot of conversation in the way those distributions get. Actually the way we built Convoy, it's a great question. The way we built Convoy said, okay, we want to pick the best of breed from each of these. Have you seen the cloud native ecosystem, kind of like pie chart or whatever it is where they have all the logos and all the different spheres? I don't think so. It's crazy. It's like thousands of logos, right? And we said, look, we're going to navigate this for you. What's the best container runtime to pick? And it's almost as if we were going to build this for ourselves using all open source technology. So Convoy is completely open source. There's some special sauce that we put in on how to bring these things together and install it, but all the actual components itself is open source. So if you're a customer, you're like, okay, I want open source. I don't want to be tied to any specific vendor. I want to run only open source and that's what comes. Yeah, I was just thinking in terms of Hadoop as a reference, right? And you had the Hortonworks, Cloudera and MapR strategies which were radically different in the way they actually packaged Hadoop under the covers. Yeah, you can think of it similar to how Cloudera approached it possibly where they had CDH and they brought in a lot of open source, but they also had a lot of proprietary components to CDH. And what we've tried to get away from is tying someone into us. I know that sounds counterintuitive from a business perspective, but we don't want customers to feel like if I go with D2IQ, I always have to go with D2IQ. I have to drink the Kool-Aid and I'm never gonna be able to get off of it. It's kind of not, doesn't really go with the open source ethos. Exactly. And it's not right for our customers. A lot of our customers want that optionality and they don't want to feel locked into any specific vendor. So when we built Convoy, we said, look, if we were to start our own company, not an infrastructure company like we are right now, but just a software company, build any kind of app, how would we approach it? And that was one of the problems we solved for us. And we don't want to feel like we're tied into any real income. Okay, so you got the training, you got the products, what's next? What's next is, if you think about the journey, you're like, okay, a lot, what we've found, and this may or may not be totally true, is one of the first things people like to run on Kubernetes is actually their builds. So CICD, and we said, how can we help with this? We looked around the market and there's a lot of great CICD products out there right now. There's GitLab, which is great, they're a partner of ours, it's a great product. There's your older products like Jenkins, there's a bunch of SaaS products, Travis and CircleC, all these things. But what we wanted to do, if we were customers of our own product, is something that was native to Kubernetes. And so we started looking at projects like Tecton and Prowl, some of these projects, right? And we said, how can we do the same thing we did with Convoy, where we bring these projects together and make it easy for someone to adopt these Kubernetes native CICD tools. And we did some stuff there that we think is pretty innovative as well, and that's the product we call Dispatch. Okay, but do you got more than just products, you've got professional services? That's right, so now you need help setting all this up. How do you actually bring your legacy applications to this new platform? How do you get your legacy builds onto these new build systems? That's where our services come into play and kind of steer you through this whole journey. Lastly, what we, next in the journey though, those services complement really well with the kind of the rest of the product suite, right? And we didn't just stop with CICD. We said, what is the next type of workload we want to run here? So there we looked at things like Red Hat Operators. And we said, look, Red Hat's doing a really cool thing here with this operator framework. How can we simplify it? We've done a lot of this before with DCOS where we built what we called the DCOS SDK to help people bring advanced complex workloads onto that platform. And we saw a lot of similarities with operators to our DCOS SDK. And we said, how can we bring some of our understanding and knowledge to that world? And we built this open source product called Kudo. People are free to go check that out. And that's how we bring more advanced workloads. So if you think about the journey, back to the journey again, you got some training, you have your cluster, you put your builds on it. Now you want to run some advanced workloads. That's where Kudo comes in. Okay. And then finally, at the end of the trail is, hell, 1-800, I need help. Well, almost. At the end of the trail, there was one more. Things are still moving well. There was one more step, right? The last one, the very last one. Actually, we said, okay, what's next in this journey? And that's running multiple clusters at the same time. So that's kind of the scale. That's the end of the journey for us, for our products as it stands right now. And that's where we build a product called Commander. And that's really helping us launch and manage multiple Kubernetes clusters at the same time. So it's so great that you have the perspective of a customer and you bring that directly in to what you want. Because you just have gone through this journey. But I'm just curious, if you put your old hat on, kind of the CIO hat, your customer, you just talked about the cake chart with Lord knows how many logos. How do you help people even just begin to think about the choices and about the crazy rapid change in what the, I mean, Kubernetes wasn't a thing four years ago, to help them stay on top of it, to help them both kind of have an eye to the vision, make sure you're delivering today and not just get completely distracted by every bright shiny object that happens to come along. Yeah, no, I think that's really challenging for the buyers. I think there's a, especially as the industry continues to mature, there's a new concept that gets thrown out all the time, service mesh or some new cool way to do monitoring or logging, right? And you almost feel like a dinosaur if you're not right on top of these things, you go to a conference and are you using BPF yet? And they're like, what is that? You didn't even feel out of the loop, right? Exactly. I think most importantly, what customers want is the ability to move their technology and their platforms as their business has the need. If the need isn't there for the business and the technology is running well, there shouldn't be a reason to move to a new platform or a new set of technologies. In fact, with DCS, with Mesa Sphere DCS, we have a lot of happy customers that aren't gonna be moving to Kubernetes even if they wanted to anytime soon. DCS does some things that Kubernetes currently doesn't do, it may never do, because the community is just not focused on it, that DCS is solving. And those customers just wanna see that we'll continue to support them in the journey that they're on with their business. And I think that's what's most important is just really understanding our customers, understanding their business, understanding where they wanna go, what are their goals, so to say, for their technology platforms and making sure we're always one step ahead of them. That's a good place to be, one step ahead of the demand. All right, Chandler. Well, thanks for taking a few minutes and sharing the story, appreciate it. Okay, thank you. All right, thanks. East Chandler, I'm Jeff, you're watching theCUBE. We're at day two IQ in downtown San Francisco. Thanks for watching, we'll see you next time.