 Live from San Diego, California, it's theCUBE. Covering KubeCon and CloudNativeCon, brought to you by Red Hat, the CloudNative Computing Foundation and its ecosystem partners. Welcome back, I'm Stu Miniman, and my co-host is John Troyer, and you're watching theCUBE here in day two of our coverage of KubeCon, CloudNativeCon. And joining me is Toby Kinnup, who is the co-founder and CTO of Day Two IQ. See what I did there, Toby? That's right. All right, so Toby, first of all, KubeCon, of course, Day Two IQ, last year when we were here, it was Mesosphere. So, you know, give us a little bit, you've been in a lot of customer meetings, 12,000 people in attendance, tell us a little bit about the energy and how your team's finding the show so far. Yeah, obviously, biggest KubeCon so far, and you know, it's just amazing how far this community has come, how it's grown, how many projects are part of it now, how many vendors here too, two expo halls with different booths. And you know, I think it just shows how important this community, this ecosystem is. When customers come to us and say they want to work with Kubernetes, the community is why they're really doing it. Yeah, it is, it's a great community, great vibe for people that aren't already in it. It's easy to get started, but one of the big themes we're hearing here is its simplicity. How do I make it easier to get going? And once they get going, what happens after day one? That's some of the re-branded pieces. So for our audience, explain a little bit why the re-brand focus of the company, day two operations, absolutely something that I hear a lot of discussion on. And why is your team specifically well positioned for that environment? No, absolutely, I think. So the re-brand we did because, obviously our old company named Mesosphere has Mesos in it, that's the open source product we started with. But we've been doing a lot more than that actually for many years, right? We help customers run Apache, Kafka, and Spark, and Cassandra. And we've been doing a lot with Kubernetes also for some time now and even more so now. So having one particular technology in the company name was holding us back, right? People just put us in that box, but we're doing so much more. So that was the reason for the re-brand. And so we wanted a name that doesn't have a particular technology in it. And so we're looking for what has really expressed what we do, what we help our customers with. And we've always been focused on day two operations, so everything that happens after the initial install, how do you monitor things properly, upgrade them, and so on. So that's why we love that day two concept. And then the IQ really stands for a couple of things. First of all, we try to put a lot of automation into our products, so make those products smart to help our customers. But more importantly too, when we look at the ecosystem as a whole, where are most customers at? Where are most companies at? Well, they're still early in their cloud native journey and they need to get up to speed. They need to get smart about cloud native and about day two operations. And so that's the IQ piece. We want to help our customers become smart about this space, get educated, and learn to do cloud native. So Toby, one of the things that fascinates me about the Kubernetes ecosystem is that people bring stuff to the table, right? People bring different, Kubernetes is here, that's evolving, there's all these things, but people are, other companies, entities, projects are coming to the table with other open source concepts and solving problems that they have in the field. At day two IQ, when you were Mesosphere, you have years of experience, right? Dealing with production issues, scaling, scaling, management, all these sort of really, really fascinating cloud native problems. So you bring a lot of experience to the table. So one of the things, the projects that you are now working on and working with your customers and partners and the bigger ecosystem on, is an operator, a way of approaching operators. The concept of bringing this kind of lifecycle automation to applications and helping with all these day two problems. Can you talk a little about, so Kudo is the name of the framework, I guess. And can you talk a little bit about that and how you're bringing that here to set at the table and what some people's experiences with that are and what they're using it for? Yeah, so these data services, these stateful workloads like Kafka, Cassandra and Spark, that's been in our DNA for a very long time. In fact, a little known fact, so Apache Spark was originally a demo application for Apache Mesos. That's how it started originally. Obviously it took off. But so we've been doing that since even before we were a company. And we've been helping our customers on top of Mesos with running these complex data stacks. And there's an equivalent of operators on top of Mesos called frameworks. So we've been building these frameworks and we realized it's a little too hard to build these things. We typically had to write thousands of lines of code, 10, 20,000 sometimes, and it took too long. So what we actually did on Mesos many years ago is we extracted the common patterns from those frameworks and built it into a library and made it so you can actually build a framework with just configuration, with just YAML. So it's a language that allows you to essentially sequence your operations into phases and steps, kind of like you would write a runbook that a human operator takes and then goes through, right? So when we looked at the Kubernetes operator space, we saw some of those same challenges that we had faced years ago. Building a Kubernetes operator requires to write a lot of code. Not every company has Go programmers, people that are skilled enough in Kubernetes that they can write an operator. And more importantly too, it's once you write those 10,000 lines of code or more, you also have to maintain it, right? You have to keep up with API changes. And so a lot of folks we talked to at KubeCon last year and to customers said, it's just too hard to build operators. The other side of that too is folks said, what's a little too hard to use those operators to? Because very common use cases, you build a data pipeline, that means you'll be using multiple different operators, say Kafka, Xenon, Spark. So if those all have different APIs, that's pretty hard to manage. So we wanted to simplify that. We wanted to create an alternative way for building operators that doesn't require you to learn Go, doesn't require you to write code. It works with just this orchestration language that Kudo offers. And then for the Kudo users, the API is the same across these different app operators. It has a plugin for KubeCuttle. So you can interface with all the different operators through that. So yeah, simplicity and a great developer experience are the keys here. Yeah, Toby, I was wondering maybe you bring us inside the personas you target with this type of solution. As we've seen the maturation of this space, the first couple of years I came, it felt very infrastructure heavy. The last year or two, there's more at the app dev discussion there. They don't always speak the same languages. Looks like you've got some tooling here to help simplify that environment and make it easier because of course your application developers don't want to worry about that stuff. The problems of things like serverless are just we're going to take care of that and sass and whatnot. So we're specifically, do you target and what are you hearing from customers as to how they're sorting through these organizational changes? Yeah, so I think ultimately everybody kind of wants a platform as a service in some way. If you're building an app for your business, you don't want to think about how do I provision this database, how to do that. And obviously I can go to a public cloud and I can use all those public cloud services, but what a lot of folks are doing now is they're running on various different types of infrastructure. They're running on multiple public clouds. They're running on the edge. We work with a lot of customers that have a need to deploy these data services, these operators in edge locations, on the manufacturing floor in a factory for instance, or on a cruise ship. That's one company we're working with. So how do you bring this API driven deployment of these services to all these different types of locations? And so that's what we try to achieve with Kudo for the data services and then with the other products too, like Commander which is a multi cluster control plane. It's about when organizations have all these different clusters and very typically they get into the dozens or even hundreds of clusters fast, how do you then manage that? How do you apply configuration consistently across these clusters? Manage your secrets, manage your RBAC rules and things like that. So those are all the day two things that we try to help customers with and there's a little bit of attention there sometimes because the great thing about Kubernetes is it's great for developers. It has a nice API. People love the API. People are very quick to adopt it. They try it out on their laptop. They stand up their first cluster. That typically goes very fast and you're very quickly to have their first app running. So it happens organically, right? But every large organization also has a need to put the right governance in place. How I keep those clusters secure? How do I meet my regulatory requirements? How do I make sure I can upgrade those clusters fast if I need to fix the security issue and so on? So there's that tension between the governance, the central IT and what the developers want to do and we try to strike a balance there with our products to give developers the agility that cloud native promises but at the same time, give the IT folks the right controls so they can meet their requirements. So Toby here at the show this year, obviously bigger and a lot more folks at different parts of their cloud native journey. And again, with the experience you all have, I mean, as you talk to folks this year, I mean, obviously people are clearly in production but you know, you talked about some of the governance issues. I mean, is there anything you can say about either what makes for, you think it's going to make for a successful partnership with you, a successful customer, what qualities do you need to have but by the time you're growing up in production and then also as they're making choices here, what should the end users be looking at? Right. Yeah, so one of the things we realized over the years is actually, cloud native is a journey. Every organization is somewhere else on that journey and I think you said partnership, I think that's the key word here. We want to partner with our customers because we realized that the stuff is complicated, right? And it's actually for us as a company, our journey has been kind of interesting because we started at this large scale spot, right? Before we were even a company, we were running these clusters with tens of thousands of nodes, these large online services at Twitter and other companies. So that's where we started, but and that's where our first product kind of landed is at that large scale, that's where we're known for, but most organizations out there are much earlier in the journey to cloud native and so what we realized is that we really need to partner with folks to even at the very first steps where they're just getting educated about this space, right? What are containers? How are they different from VMs? What is this cluster management thing, right? How does that all fit together? So we try to hold our customers' hands, you'll catch them where they are. Besides all of the software that we're building, we also offer trainings for example and so we just try to have the conversation with the customer, figure out what their needs are, whether that's training, whether that's services or different products and the different products that come together in our Kubernetes product line, they're really designed to meet the customer at these different stages, right? There's Convoy, that's our Kubernetes distribution, get your first product up and running, then once you get a little bit more sophisticated, you probably want to do CI-CD, so we have an upcoming product for that, called Dispatch, pretty excited about it. The data services with Koodle, folks typically add that next and then very quickly you have these dozens of hundreds of clusters, now you need Commander, right? So we try to fit that all together, meet the customer where they are and I think education is a big piece of that. All right, Toby, want to give you the final word. You talked about some of the things coming out here, so just give us your viewpoint of kind of the ecosystem broader as to what next things need to be done to help even further the journey that we're all on. Yeah, I think in terms of next things, there's a lot of interest around operators and while operators ask the implementation, but really what's happening is people are running more and more different workloads on top of Kubernetes, right? And I think that's where a lot of the work is going to happen over the next year. There's some discussions in the CNCF now, even what is an operator, how do we define that? Is it something fairly broad? Isn't something fairly specific? But Kubernetes is definitely the de facto standard for doing cloud native and people are putting it in a lot of different environments. They're putting it in edge locations there and so I think we need to figure out how do you have a sane sort of development workflow for these types of deployments? How do you define an application that might actually run on multiple different clusters? So I think there's going to be a lot of talk, operators obviously, but also on the developer side in a layer above Kubernetes, right? How can I just define my application in a way where I say maybe just run this thing in a highly available way on two different cloud providers instead of saying specifically it needs to go here and it needs to go there or deploy this thing in a follow the sun model or whatever that is. So I think that's where a lot of the conversations are going to happen is that level above. All right, well Toby, appreciate the updates. Congratulations on the progress and definitely look forward to catching more with you from you and the Day2I2 queue team in the near future. Thank you very much for having me. All right, for John Troyer, I'm Stu Miniman. Lots more to come. Thanks for watching the queue.