Beyond Kubernetes

Video size:

0:09 Miko Pawlikowski

Hello and welcome to another episode of Conf42Cast, the tech podcast from a neighboring galaxy. My name is Miko Pawlikowski. And today I have for you not one, but two co-founders of Kubefirst for the price of one, John Dietz, and Jared Edwards. How are you guys doing today?

0:25 John Dietz

Doing great. Thanks for having us on.

0:27 Jared Edwards

Thank you.

0:28 Miko Pawlikowski

Absolutely. My pleasure. So you know, you've been prepped, the weird question for you to start is what orchestration platform would you use to run a spaceship? And why Kubernetes?

0:41 John Dietz

And why Kubernetes? Exactly. No, it would absolutely have to be Kubernetes. It would be it would be irresponsible. On a spaceship no less. Can you imagine being on your way to Mars and you suddenly have some unexpected problem, and all you have is Ansible. And some virtual machines would be terrible.

1:07 Miko Pawlikowski

That would be the stuff of nightmares. I do wonder what's the basics around their stuff? Like I suspect it's a bit lower level. But yeah, I think I agree. Like, you know, not that long ago, you got away with something with processing power of a dumb phone. But today will definitely be Kubernetes. Okay, so you passed the first one. So I guess we'll continue this. What's the second one? What do Kubernetes and space travel have in common?

1:37 John Dietz

So one thing Kubernetes has in common with space travel for sure is how it was set up for fault and being tolerant of bumps that happen. And I've only watched a handful of Sci-Fi movies. But if you're going in outer space, there's gonna be some some bumps in the road and systems are gonna go down on you. And when they do, it'd be nice to be really fault-tolerant, highly available, have some redundancy built in maybe have a spare node group laying around tied to that master, maybe have an AB master that was ready to go. Just warm and waiting in the helm. I think that, you know, I thought they were silly questions when I first read them. But, um, I think you got something going I think we should hit Musk up. Because Kubernetes is definitely the way to run your navigation to Mars, for sure.

2:40 Miko Pawlikowski

Definitely make for a nice Kubecon talk, right? That is fair enough. So I don't usually get both co-founders. So you know, I'm a bit spoilt for choice today. So I guess the first question, really to start with you guys is like, you know, how did you meet?

3:01 Jared Edwards

Yeah, so I guess I can take that one.

3:04 John Dietz

Take it away.

3:05 Jared Edwards

So John and I met back in 2017. It was like mid-late 2017. At our first Kubernetes project. I was actually a front-end developer. And John was one of the two people running the Cloud team at the time. And after working with him on a project, he pulled me over to the Cloud team, and I never had to write front-end code again. So all was good.

3:26 Miko Pawlikowski

He saved you.

3:29 Jared Edwards

Yeah, he did. Yeah. That's the short version. A little more about the company, we were at a big data real estate company, and they had a ton of needs. And the CTO basically ordered us to build the platform, mostly using all Kubernetes for everything. So that's what we did. We had to build in the application management, had to build in the secrets management, you know, the CI, CD, everything, all in Kubernetes. And we just were impressed with how well it all came together after a long fight of armwrestling and picking the wrong tools and then picking the right tools. And you know, the finding the patterns we liked, but in the end, it all worked out really well for us. So

4:09 Miko Pawlikowski

And then you liked working so much together that you went on the new venture?

4:13 John Dietz

Yeah. It soon as I saw this guy work at all, there was no way he was going to be a front-end engineer, zippy chance. So we pulled him onto the infrastructure team. And we, like Jared was saying, we built this platform out. And the origin of Cooper's, we were on the train on our way to data dog dash. We were just kind of reflecting on this platform that we had spent the last year building and we were like, you know, I've been in DevOps forever. I've been like in DevOps since before DevOps was even a word back when developers had to work with operations teams, right. And running a platform on Kubernetes was just clearly different and it was a tough adoption. And we were basically just like, how do we make it so that it's no longer a tough adoption? How do we take that year of work that we just did, and productize it so that it's immediately available? And the train ride home, we bought the domain and started working nights and weekends for like, years for multiple years, we were working on this project for nights and weekends, we got it to a point where we could pilot it at an enterprise. It was it was all closed source. And we thought we were going to just like go shop to shop and just, you know, do Kubernetes platform installs for companies. And it turned out to be a little bit more complicated than that. And long story short, we ended up deciding that we were going to open source and added ourselves to the CN CF and tried raising capital. And through that process, we ended up getting acquired by our parent, company coop shop. And now we been building a team around it and trying to see the rest of our vision through for the last year.

6:13 Miko Pawlikowski

That's a sweet story. Like I wish every domain that I bought on my way home from somewhere in the spring was actually turned into a project that worked a couple dozen of them by now. So let's start to like establish some timelines. So if my memory is not failing me, first time I started doubling Kubernetes was version 1.2. So that would have been in 2015, late 2015. And back then, if I remember correctly, well, at least for me, it was just a bunch of binaries that I downloaded from GitHub, and then tried to set up some automation to actually put all of this together and discover the next layer. And the next problem, like blew up understand how it all fit together. I remember various other weird attempts. Everybody was basically on the same boat, right? And that's roughly where you guys started with Kubefirst two, that's the was it 2017 you said? 2018?

7:16 Jared Edwards

Yeah, well, I guess I don't know, John don't remember how many months before you were at the shop before I showed up? But for me, it was October 2017 when I joined. So it's right around that time, but I believe, John, you should probably field this one, but started out on an early version of GKE. But then ended up migrating to cops that ran in a the AWS cloud instead.

7:42 John Dietz

Yeah, exactly. Yeah, the early days of Kubernetes was a dark and scary place. That was back when Kubernetes was the hard part, right. Were like actually getting the master control plane and the nodes to attach and managing it as infrastructure's code. That was quite a daunting challenge back then. And, you know, I had come from a company where I was literally advocating against Kubernetes at USA Today. The platform team at USA Today wanted to adopt Kubernetes, we had just migrated to the cloud and from on premise infrastructure that they had. Really complex story, you know, microservices, just from all angles. And just as soon as we had settled and finished the cloud adoption, now we're talking Kubernetes. And, you know, honestly, it seemed like just another, I had seen all these buzzwords 15 times before, it sounded the same. It sounded like it was just another, you know, sexy, trendy, buzzword that engineers that want to be early adopters would adopt and think was super cool was how it felt. And I advocated against it for about one month. And then I got pulled into this other project. And the mandate was Kubernetes, or bust, like there was going to be no infrastructure there wasn't running on Kubernetes period. So get loving it or get out, right? So we had to learn it the hard way. We had to read a bunch of blogs that were just full of lies and try to find our way through the dark. You know, like you're kind of describing, you're just kind of putting raw pieces together as best you can and seeing what works and what doesn't work. And it takes a long time. Nowadays, that part's actually quite a bit easier, but the cloud native part must be four times harder. There are so many more products that are available, that are adequate that are ready to run on Kubernetes, that now you have like, analysis paralysis on which stack you want to build. And so that's kind of the solution that we're trying to provide to the world is not to give an opinionated Kubernetes stack that you're stuck with forever. You know, we're not trying to wrap any of these excellent open source tools that are on the platform, we're just trying to enable fast adoption of them in a way where like, you know, once you have this platform, if you don't like Argo workflows for CI great, don't use it, add Jenkins to it, add, you know, Tecton to it, add whatever you want to it. And establishing that GitOps paradigm, to provide the extensibility. And to provide the disaster recovery that you need, we think is going to be a really solid motion moving forward. So yeah, used to argue against Kubernetes, if you can, believe it or not. Now I eat it for breakfast. It's crazy.

11:06 Miko Pawlikowski

Well, you know, not that long ago, that wasn't a given. And it's changed dramatically. But we didn't actually define what is Kubefirst, what does it actually do? And what's like the unique value proposition?

11:22 John Dietz

Definitely. So basically, Jared, do you want to field this one?

11:26 Jared Edwards

No, go for it.

11:27 John Dietz

Right, yeah. So basically, I'm Kubefirst trying to establish an instant, fully operational, fully automated, GitOps-oriented, open source application delivery, an infrastructure management platform for anyone. It's all free. It's all open source. It only uses free open source tools. And it's put together and fully automated in a way where you can run your enterprise software development ecosystem in 30 minutes, you just run a single command against your empty cloud that has nothing but one domain in it, and will attach to the domain, will run in different clouds. In the AWS Cloud as an example, we lay down the VPC, we lay down the subnets, we build the EKS cluster, we establish the bucket for your infrastructure's code state store, we bootstrap that Kubernetes cluster against a git repository called GitOps that we give to you that you host in your own GitHub or your own GitLab. So this git repository that's powering all the infrastructures code that's powering all of the Argo, CD configurations for your Git ops, application delivery, is all hosted by you in your Git repository. So you run a command against your cloud, it creates this whole ecosystem, including a management Kubernetes cluster, that has HashiCorp Vault, that has all of your platform secrets in it, it establishes a user, IDP and identity provider that's powered by HashiCorp Vault, we established an OIDC provider with clients for every single one of the platform tools, so that you have immediate single sign on for logging into Argo CD, logging into Argo workflows, logging into your Git provider, whatever it might be. We do team management, separation of administrators from your engineering groups, we start you out of the box with a good R backstory, so that you at least don't have to start by giving your admin keys to your development group. The tricky part with Kubefirst is trying to find that line where we stop and our adopters begin their Kubernetes journey. But they can begin their Kubernetes journey on a foundation that includes automated infrastructures' code and GitOps application delivery, and secrets management and a powerful secrets engine and user management in equally good user ecosystem, all powered by TerraForm, all powered by GitOps. And in AWS, it's 30 minutes in the SIBO cloud, it's like 7 minutes to have basically a company on wheels for free. So we think that it's going to bring a lot of power to the cloud native ecosystem. And we even have a local version of the platform that you can install to your laptop. It's powered by K3D Is the Kubernetes engine. But the same platform including automated IC and like application delivery, we do container builds we do Helm publishes, we do GitOps pipelines that deliver to a dev stage prod environment, and you can have it all all running on your laptop, also in just like 5 minutes. So we've basically packaged all of these great open source tools, put them together in a way where it's all automated from minute one. And then our hope is that folks will use this platform as a foundation for their platform engineering operations. So that when they're trying to build their Self Service portals for their development teams, and trying to deliver their applications to a dev stage prod environment, they can leverage all the tools that we build as that foundation, and have a local ecosystem that matches an AWS ecosystem, that matches a SIBO cloud ecosystem or wherever it is that they need Kubernetes platform, they'll be able to lift and shift their platform anywhere. So it's a pretty cool story. It's a little ambitious, but we think we're up for the challenge.

15:53 Miko Pawlikowski

Definitely sounds so. So I think my first question of from all you said is, you kind of have to draw the line how opinionated you are, and you name dropped a few things, where perhaps there's fewer alternatives, like TerraForm. But on the other side of the spectrum, it can be kind of, you know, flexible to the point where this paralysis analysis that you mentioned, is actually creeping back in. What's the goal? Like, are you trying to be prescriptive? Or are you trying to be, you know, as open as possible?

16:29 Jared Edwards

I think my answer to that one is as open as possible. We know that we're never going to be able to build a platform that suits everybody's needs, like, it's just not going to happen. Everybody has different opinions, and everybody likes different tools. Some people are married to their tools in a way that they'll just not shift. But we do see that there is a commonality across companies, people we have conversations with, you know, there is a subset of the CNCF landscape that we've noticed become top choices. Now sometimes those top choices are hard to configure or hard for teams to adopt for reasons, you know, there are lots of reasons, doesn't matter. But well, all we're trying to do is give you that starting point where everything works on minute 7, minute, 30, whatever you want to call it, right? So start there and you can drop your applications into the platform, there's a pattern to follow with a sample application that we deliver for you, shows how you get an ingress in front of your application, shows how you pull secrets out of HashiCorp Vault in your Kubernetes native way, shows how you can have tight integrations with your CI and how it can have smaller blast radius of access per container it a secret in Vault. All of these things that just take time to discover and establish and actually get working in a way where it wasn't an exploration spike day or an engineering day where you got a tool working, and then you had to repeat it the next day, because like, that's the hard part is being able to go back through, repeat that process, make sure that you can then take that and explain it to your teams, make sure at that point, you're usually making some kind of architecture decision where you've got 14 members, and three of them agree and one of them doesn't. So you're going back to work to go figure out how you can convince that fourth person that this is the right choice. And like we're just trying to eliminate a lot of those upfront choices to be able to get people going. And from there, like John mentioned, it's because we deliver that GitOps repo to you. You can pull request away or whatever you don't want in your Kubernetes cluster, and pull requests right back on anything that you do want. So that's the best I can answer. John, I'll let you add anything else to that?

18:41 John Dietz

Yeah, no, I think you're really spot on. The detail I don't want to get missed though is that there is a need to provide that immediate value for the business. Businesses don't take adaption of Kubernetes lightly they read the blogs, they understand that it's an investment. And it is. And they also understand that in order to succeed in this investment, you have to hire good engineers that are able to architect this complex ecosystem. And there's frankly, a shortage of folks that are expert level, cloud native architects, they're hard to capture, they're hard to find. And there's a lot of small to medium sized businesses that only have, you know, two three engineers working on their cloud teams. And they're already overworked. They're already running virtual machines and Ansible and they've got TerraForm over here and well, we just do that part manually. And we have a run book up here and we feel like by establishing a stack of a good starting point that embodies all of the major pillars of cloud native delivery, that being secrets management, user management, infrastructure's code, and GitOps style application delivery. If you have those, you can do literally anything in cloud native. You can host every single application under the sun, it doesn't matter if you're building boxes for chick fillet, or rocket ships to take you to Mars, it will work because you have those things. But Kubernetes doesn't come with those things. So by building a platform that gives you everything stitched together immediately, and then supplementing it with a community of users that have all agreed, hey, maybe this isn't where I'll end. But this is where I'll start. And I want to start on all the best open source most popular technologies all working together. And if I want to deviate off the path, by all means, we hope that you will, and we hope that you'll tell us about the story of you shifting into Tecton or whatever. But your director has needs, your director wants value to come out of this Kubernetes investment. And we're able to take this six month journey and turn it down to like, you know, you'll be a hero by lunchtime, it's ready to go. And so if you can just start there and be doing builds and delivering the prod, even if it's not the way you'll do it permanently. That gives a lot of value to your company. And then you can start the analysis part, then you can start deciding, 'Well, you know, do we really want to use HashiCorp Vault? It's a fair conversation. I think the answer is yes. But it's a fair conversation. And you should have that debate. And you should spend weeks on that debate. And you should pick other tools. And you should have a bake off about which one's best. But do it while everything is working, right? So that your director isn't just tapping his toe, staring at a stopwatch wondering what's taken so long on this Kubernetes effort. So we hope that we're able to give the cloud native community that and we do have a growing community, we just hit 150 people, you know, not gaudy figures, but 150 people are in our Slack workspace that have all kind of agreed that like, yeah, this is the tech we're going to need. And if we have a question, we're going to ask the community and there's 150 engineers that are all using the same tools the same way, which is pretty powerful if you're a small shop. So um, so yeah, we're trying to shift the landscape a little bit, just kind of have a easier starting point for companies to get value out of the Kubernetes investment that they're already making.

22:58 Miko Pawlikowski

Definitely, that's definitely a pain point. And I think to a certain degree, now, the fact that you can go to Google or Azure or whoever and get like working cluster where at least you don't have to worry about actual control time working is a nice first step. But what you're saying and all this glue that takes so much time and so much effort and often goes underappreciated is definitely a lot of value. So two questions to you, then. First, what took you so long? And why wasn't this ready five years ago? And secondly, how do people get started with it? How do they become person 151 on your community?

23:41 John Dietz

I talk too much. Take it away, Jared.

23:43 Jared Edwards

Oh, okay. Let's see, where do we start there? What took so long? Great question. There's only so many hours in the day. So we'll start there. We were trying, we were going as fast as we can. I swear. It doesn't look like it. But but we did. Apologies. I need a refresher on the second part of that first one. But then John.

24:04 John Dietz

How do we get people involved? Yeah, I mean, yeah, we have open source contributors that contribute in all kinds of ways, from an upgrade to get a security patch into one of the tools all the way down to just like somebody finding a typo in our docs. And they're, they're all equal contributions to the platform, we very much value the contributions from the community. We have some groups of users that see the value in Kubefirst. And we kind of built Kubefirst to be this company on wheels that you can deploy to your cloud and, you know, you have all this immediate value. But to our surprise, there were a whole bunch of folks in our community that want Kubefirst to be there homelabs story. And there's this budding community in our home lives channel of folks that are just like, shout out some like tail. There's these folks who are like actively working through the challenges of trying to get the Kubefirst platform available in home lab environments so that you can have, you know, Proxmox, or we're also kind of in parallel, doing some bare metal stories where maybe we implement harvester in a very similar capacity. But just kind of a bring your own cluster type of scenario for the Kubefirst platform to be installed upon. And it seems like there's some neat community engagement in that regard. But just go into slack.io, or I'm sorry, Kubefirst.io/slack. That's the easiest way to drop in, that'll auto invite you to the channel, and we have a Helping Hands channel in that slack workspace where even if you don't know what a pod is, and you could just use an explanation, like, it doesn't matter how simple the question is, it doesn't matter how complex the question is, we've seen it all. And we're happy to help. We're just trying to get people onboarding on to Kubernetes. easier.

26:05 Miko Pawlikowski

Can I run it now on my Raspberry Pi?

26:08 John Dietz

That's a great question. You can't run it on Raspberry Pi yet, but we are working on that.

26:16 Miko Pawlikowski

Well, you know what I'm interested in now. Another aspect that I think is kind of, I'm obviously biased. I love open source. And you know, we've liked recent years and encouraging results of HashieCorp being like a billion dollar company and stuff. I'm actively on the lookout for open source companies. What's your experience been? Is it just that it was like a natural choice, because a lot of this stuff, including Kubernetes is actually open source, so that was like the default state. But did you make that choice for any other reason? And what has the experience been so far?

27:02 John Dietz

I can definitely take that one. So cloud native engineers want experience in technologies that are highly valued. That's a real state of cloud native right now. There are major, major Fortune 500 cloud companies that are running on Kubernetes that have an opinionated set of tools that they gravitate toward. And the engineers in the cloud native space understand that. We know that, we know that HashiCorp Vault is indeed a top-notch secrets manager, a little complex, but very, very, very good from a lot of different measurements. Argo CD, you're not going to find that many major major major shops that didn't at least consider Argo CD as their delivery pattern. TerraForm HashiCorp's TerraForm. Most major shops need IAC and TerraForm is, love it or hate it, it is the de facto standard. So if all of the shops that have all of the money to pay, high wages for cloud engineers, are gravitating towards certain tech then those popular best of breed technologies are valuable to the engineers at any shop, whether they're going to one of those shops or not. So in order to attract that talent, it's really valuable to bank on leveraging the best of breed tools, so that you can attract the talent of the engineers that are using the technologies in order to embolden their resume and their experience and their ability to run enterprise style shops. So that's one of the advantages that Kubefirst brings is that you don't have to have this entire team of engineers that are going to buckle down for a year. We were that team. And we did it for four years, and now we're giving it away for free. So if you can just start from here and run on enterprise level patterns, on the best tools on the planet, whoever that great cloud native engineer is that you're hoping is going to say yes to your shop, when they see the tools that you're banking on, that you are trying to run your organization under, it's going to be more attractive than, you know, someone that's, you know, forgive me for saying so but one of the cloud providers deployment tools or something. There's a hint of yuck about it that cloud native engineers just don't want to touch. They want their their tools to be cloud native, they want everything stable, they want everything in yaml. They want it desired state, they want it pushed via GitOps, they want everything to be well-orchestrated, and highly available, and redundant and available and portable, so that you can move it to your local host, or run in GCP, or AWS, or a smaller cloud, like SIBO, or whatever it might be, like, that's what the cloud engineers want. And maybe I shouldn't say so. But the the engineers are going to get what they want anyway. So, if you can expedite that six month process of getting all the tools set up the right way, why not start there, and especially if the end result is that you're gonna have to do all that same thing anyway. So let's imagine that there's no Kubefirst in the world. And for a lot of people, that's true. And that's terrible, and we should change that. But let's pretend for a second that there's no Kubefirst, and you had this program that you've been working on in your basement for nights and weekends for the last few years. And you finally got some seed round funding. Congratulations, we love it, right? Now, you have to take this idea that has a git repository, and it works on your laptop. And now you have to deliver it to the masses, Dev stage prod, CICD, you're going to have to hire people, they're going to have different roles in your organization, you're going to need single sign on, you're going to need infrastructure, you're going to need application delivery, you're going to need all these things. If you didn't have Kubefirst, what are you going to do? You're going to start writing some infrastructures code, obviously, you're going to put it in a git repository, obviously, maybe you'll be granted enough of a timeline to automate it with something like Atlantis, if you're lucky. You're going to have to build out CI, you're going to have to write the scripts to do your builds, you're going to have to pick a technology. You're gonna have to do all these different things. And at the end of the day, if you did it, all right, it's still going to be in a git repository. And you're still going to lay out all the applications and their configurations in a GitOps-oriented way. And you're still going to have all your infrastructure as I see, that's in some files, and maybe you're lucky and you got to automate it. And you're going to have some secret source of truth somewhere. So like, if Kubefirst cease to exist, that story is exactly what we left you with, you're no worse for it. We just gave it to you in a few minutes instead of handful of months. So yeah, you know, that's kind of the story of our mission. That's, that's, you know, we're basically just trying to build that next layer of open source where we can put all these tools together, instead of making everybody do that same job over and over.

33:15 Miko Pawlikowski

Yeah, I can definitely relate to, you know, building trust through making right decisions and providing people with good tools. Now, as you were saying that, an example that came to my mind is that I see behind you vacuum cleaner. And it's not just a vacuum cleaner, I can see that you chose a model that actually empties itself. So you're only going to have to touch it once a week. So I immediately trust you more because you make reasonable decisions. If that was a manual one, we'd probably have to cut it short. You know, we keep going.

33:54 John Dietz

This guy is observant. I love it, Miko.

33:59 Miko Pawlikowski

By the way, full disclaimer, I'm not associated with iRobot.

34:05 John Dietz

Just an investor.

34:06 Miko Pawlikowski

You mentioned Kubeshop. And I gotta say that, you know, I kind of pride myself knowing quite a bit of a Kubernetes in general. But I haven't come across an accelerator for Kubernetes. So I'm very curious. Can you tell us more? You mentioned, you've been acquired and you're part of it now. I think we spoke a little bit earlier that there are six other projects. Would you like to do a quick landscape pass?

34:39 Jared Edwards

Yeah, I guess I can take this one. So yeah, Kubeshop. It's great. And we have five total projects right now. Did I count those right?

34:51 John Dietz

Plus casket.

34:54 Jared Edwards

Okay. So sorry, back to that. So we got acquired and brought into under the umbrella about a year ago. But what's neat is they basically come together and helped these projects. Some are homegrown, some are outside projects like ours. But what they do is they, they make it easier for these teams to be able to focus on their product development, and not necessarily have to worry so much about all the ins and outs of like trying to build a business company at the same time as building your product. So they have like a shared services model. So they have like a design team. And they have a marketing team. And they have Dev Rel, and they have all these other branches, payroll, and you know, those important things that your teammates and employees care about. They take care of all of those types of things for us, so that we get that larger focus of time on the actual engineering, the product, the interaction with the community, all of those things that we want to continue to do as an open source project. So I'll stop there and see where you want me to go with a little more depth on the overall picture. And, John, if I left anything out, feel free to throw it in.

36:06 Miko Pawlikowski

Any other projects? Or are you more competing against them?

36:11 Jared Edwards

I wouldn't say we're competing, we all have very different functions, if you will. So like botkube is a chat ops bot, that's yummy. We could install it on coop first. But we have we did a live stream a couple of weeks ago, check it out. It's on our YouTube channel. But there's you know, there's a trace test, which is a little bit more traits based testing. Little more insight for like QA Dev and Ops teams. There's test cube, which is a Kubernetes native test execution framework. So has a ton of different integrations with Cypress and J meter and you know, blah, blah, blah, test framework, test framework. So you can do all these tests in a Kubernetes native way. And, yeah, so there's monocle.

36:56 John Dietz

I was just going to add monocle to the list as well. Monocle is a Kubernetes YAML manifest observability tool that helps you build a good safe Kubernetes YAML manifest for your applications.

37:14 Jared Edwards

Yeah, go ahead.

37:14 John Dietz

Yeah, I was just gonna say the five projects. You know, because we have sort of different spaces and different angles. Sometimes we have opportunities to collaborate with each other, we have, like, show and tell every week where you know, whatever it is that we've been working on, we have an opportunity to like, bounce our ideas, and what we're thinking of off like, you know, it feels like you have like a CNCF survey in your pocket. It's really nice. There's all these Kubernetes engineers, and they're all just kind of locked in on on Kubernetes. Like, you don't have to describe what YAML is to these guys. And just being able to get that immediate feedback from all these Kubernetes-oriented engineers is kind of been a really nice benefit of being at Kubeshop specifically, they're obviously very hyper focused on Kubernetes projects, they see the, the direction that Kubernetes is headed that it's basically just swallowing the internet. So yeah, it's been a great experience. So far, we've had probably just a little bit over a year with them now. And I can't express enough how different it is going from a nights and weekends passion project. That means that you're working until, you know, three, four o'clock in the morning every day to having like it as your day job. Not that we don't work until three and four in the morning every day. But that's an us problem. But yeah, we, you know, just just sort of having that foundation where we don't have to care about you know, health insurance or payroll or you know, all the intricate details of running a business, we get to stay technical founders and just kind of stay focused on the tech. It's been really nice for us.

39:05 Jared Edwards

Yeah, I think I'd add one more thing to that, because we mentioned that we got acquired by Kubeshop. But you know, there there was a lot of decision making at that time for us to on what we were doing with our project. And it wasn't really that much before we found Kubeshop that we decided we were going to open source the project anyways. And then, you know, we went and met with investors and a bunch of other stuff. And with Kubeshop, the nice thing was the two guys who have started it come from a previous company smart bear, where they built open source projects and they did it in a way where they never disenfranchise the open source even though they turned those projects into businesses. So like smart bear has like swagger and cucumber and you know, other open source projects that a lot of people know, a lot of people use, and they have always maintained that core open source. So that was really important to us, as well as when we initially discovered Kubeshop. And then obviously, as we mentioned, all worked out and got married about a year ago.

40:12 Miko Pawlikowski

Okay, so that's good retrospective. Let's look a little bit more into the future now. So other than the obvious world domination and preventing baby seals from getting clubbed, what's next for Kubefirst?

40:28 Jared Edwards

Take it away John .

40:31 John Dietz

Yeah, this is hot off the press, because we I actually just decided two hours ago. So we had a hackathon project not very long ago, maybe four or five weeks ago, the project that we didn't know if it had viability. But we wanted to see how well we could do it. We have this concept that we're going to be introducing in our next release that we haven't even put on our roadmap yet, it's actually going to jump the line a little bit. And it's this GitOps marketplace. So like, cloud marketplaces, or any type of marketplace, is a great story, right? You have a Kubernetes cluster, you want to add a thing to it, you can go boop, and you can have the thing in your cluster. The problem is that like it's in an empty cluster. And now you've just added it using kind of a click ops operation. So you've lost it as an asset in your GitOps ecosystem. So it's a bad paradigm, sort of to have a marketplace if you're trying to adopt GitOps. But we believe that everyone concretely should be adopting GitOps, that is a great disaster recovery story, it's a great asset management story, it's a great, you're basically taking a tried and true git foundation and marrying it to engine like Kubernetes, that you will die trying to make your desired state the actual state, and you just put the two together, it's like the greatest architectural decision, both systems are completely distributed, portable, etc. Like, there's really not a lot of good reasons to say no to GitOps in 2023, at least, at least on Kubernetes. And so what we're going to be introducing next is this, GitOps catalog that works like a marketplace, except instead of installing it to your Kubernetes cluster, we're going to install it to your GitOps structure in your Git repository, and allow Argo CD to be responsible for the delivery of that application to your ecosystem in an extensible way, where you can overlay, you know, configurations, and you can kind of take some base defaults for these marketplace tools. But then you're allowed to expand on what you mean when you want to install Tecton. What you mean when you want to install one of these other products that aren't core products of the coop first platform, but we want them to feel like their core products of your version of the Kubefirst platform. So that's going to be our next release is this GitOps catalog. It's kind of like a marketplace but it's bound to your Git repositories. And then beyond that, we're going to finish the job that we set out on with the 2.0, we 2.0 was kind of a re-architecture that allows us to support multiple clouds, to dot one that we released just a couple of days ago, introduces a new user interface to the Kubefirst platform. And then version, what was going to be 2.2, it's about to become 2.3. 2.3 is going to introduce workload clusters to that Kubernetes management ecosystem. So we're going to deal with all the nasty details of cluster lifecycles. And being able to provision a new workload cluster like a develop blue or develop green, actually add the GitOps applications to those clusters. Eventually, we'll get into the business of traffic switching and details like that. And being able to spin up and tear this down is all a part of our mission. So that's the next quarter for us probably is wrapping up with a GitOps catalog and all of the nuanced work of trying to get workload clusters to be a part of our story. But we hope that at the conclusion, you're going to be able to run a simple little Kubefirst install, you'll get this management cluster and you'll be presented with an new console screen that says, hey, we can create a whole multi cluster platform for you. And you can just be like, Yeah, I need a Dev, I need a stage, I need a prod, I need a demo, I need a prod blue and green, I need one of them in this AZ, one of them somewhere else, you know, eventually we'll get into the business of multicloud and all that kind of stuff. So that's the direction we're headed. Obviously, we're startup and nimble. So things change as things develop a little bit for us. But that's what we're trying to stick to.

45:30 Miko Pawlikowski

That sounds like a plan. The last one I have for year is, you know, I've got a little bit of a unique perspective, working so closely with people having pain points around two ranges. Where do you see Kubernetes itself? And you know, the broader ecosystem evolve? Like, where does it go from here? Like, once it's dominated completely the scene, is there one more way up? Is it always downhill from now? What's your take?

46:03 John Dietz

Yeah, it's a really good question. Do you have thoughts? Do you want to jump in on Jared? I've got one I could throw on the table.

46:09 Jared Edwards

Throw it on.

46:10 John Dietz

So with Kubernetes, one of the toughest problems that I see is the and it's starting to shift. But there's a challenge of chicken and eggs with infrastructure and platforms, where, you know, you need infrastructure's code. In order to create clusters, you need automation, in order to bootstrap clusters, that automation needs to live somewhere that's probably in your Git repositories. And so many products are ignoring the infrastructure part because it's easy to. So if our story was bring your own cluster, and good luck to you, there's no statefulness of the infrastructure that your platform is running upon. And that's not good enough. You could alternatively have infrastructure story that has to happen first, but then it's detached from your platform. And then there's this muddiness in between the two, that folks like crossplane and open control plane are trying to address where they're trying to say, you know, look, Kubernetes is extensible to anything. And it's true that it is, that you can establish a CRD and you can make Kubernetes turn on your coffee pot if you need to.

48:00 Miko Pawlikowski

You're not during that?

48:02 John Dietz

Not yet, but we haven't built a spaceship yet, either. So when you're trying to establish that Kubernetes can do anything. One of the biggest challenges is that of infrastructure's code, and automating the infrastructure's code, and you naturally want Kubernetes to be able to manage your infrastructure's code, especially when you get into GitOps, because you see this magical ability of setting desired state and allowing an engine to work relentlessly to make it your actual state. And that's a beautiful paradigm. Architecturally, you have a pull paradigm from a configuration standpoint, the system has to check in with your source instead of your source pushing to your downstream production, like the whole thing is very elegant. And Kubernetes is now with tools like crossplane. And with tools like open control plane, they're able to actually build out infrastructure in Kubernetes. But then how do you, you have to be in Kubernetes first, and where did you get the Kubernetes cluster? And why wasn't that in your infrastructure's code, which is part of the story later on. So something has to happen. We're trying to solve that problem. There's a whole bunch of people in the platform working group that are trying to solve the nuanced details of this problem. But there's a hole in between application and infrastructure in the Kubernetes space where that gap needs to be filled. We're trying to find the right recipe to fill it. I'm sure other folks are are trying as well. I know 500 companies are faced with the same problems and you know, they have to be able to provision platforms for their dev teams from scratch also, so everybody's kind of faced with the same challenges, the same nuanced chicken and egg setups, but I would love to see Kubernetes evolved to be able to accommodate that sort of core chicken and egg problem. Like, from an IAC standpoint, what I want out of the world is I want to be able to say, Hey, I would like a thing. Here's some YAML cloud, give me an EKS cluster, and that YAML could go to the cloud. And then I have an EKS cluster. But instead of it being a script ops thing that I did, I want that to be bound immediately to my desired state. And if we can do that, we all win, and we all high five and go home. But that's the missing piece of the Kubernetes story in my book.

50:42 Miko Pawlikowski

Beautiful visual. Yeah. I've got nothing either.

50:45 John Dietz

Yeah, all right. Yeah, let's just do that. It'll be great.

50:49 Jared Edwards

Somebody out there, we're waiting. Faster, he says.

50:54 John Dietz

Tick tock tick. Time is money.

50:55 Miko Pawlikowski

All right. I think that's probably a really good notes to end. Like you know, all good things to tape on this podcast running out. For anybody who wants to reach out, do they reach out on LinkedIn, do they reach out on Twitter? What's the best way to reach each of you?

51:14 John Dietz

Yeah, the the easiest way to find us, honestly, is kubefirst.io/slack. If you land in there, you'll be our principal Deborah Alfredo, introduce himself, let you know how to find the channels how to find us individually. And we're easy to find in there. We're all over the place on all the channels. So just ask anything. And we'll just pop out like it was a Batman symbol. But, seriously, like, no, there are no bad questions, even if you just feel completely in over your head on Kubernetes adoption. We were there too. That's why we built our project. That's why we endured and now have a company. And we are literally here to try and solve that problem for our users. So hop on in, kubefirst.io/slack. And we hope to see everybody there. Miko, it's been a great chance having a opportunity to talk to you on your podcast today. Thanks for having us on.

52:27 Jared Edwards

Thank you.