Tommy McClung, Release | KubeCon + CloudNativeCon North America 2023

This is Techron tv. Hi everybody. We are at Coup Con again, back with more great guests or great topics, really interesting, uh, topic that we're gonna be checking into here around kinda rapid development and innovation.

How do we get, how do we get something that shows our idea very quickly? So, I'm joined by Tommy McClung, who is CEO, founder of Release. Welcome.

Thanks. Thanks for having me. Yeah.

First time we've talked, I'm excited to hear about, about release. First of all, you uh, I heard a little bit of your kind of origin story Yeah. To use a, you know, a, uh, d and d kind of language or whatever.

Tell us a little bit about where you came from to come up with the idea of what you're now doing at. Sure, yeah. I've been a software engineer since early two thousands.

Uh, working on systems management, helping developers be productive my whole career. Most recently prior to this, I was the chief technology officer at a public company by the name of TrueCar and, uh, environments, um, making those developers productive. We had 300 people in the technology team.

Was a, was a really big challenge and environments, whether those were staging, development, local production, partner environments, qa staging was a, was a big challenge. Um, so my co-founders and I, uh, built a bespoke, uh, version of that, uh, environment management, uh, for that company and realized, hey, there's probably a lot of other companies out there dealing with this problem. Uh, turns out every engineering organization deals with how do we get our developers access to an environment that looks like production that I can develop against, I can do database migrations against.

Uh, and we were not unique. Uh, it turns out that this is an issue that almost every development team has to, has to deal with. So that's, it's like that 60% that isn't about writing code.

How do we get some of that back into That's right. Trading softwares. And, you know, we spent millions of dollars, uh, with teams of DevOps engineers and building that in-house product, uh, which really was a product that we had to manage and maintain.

And, um, you know, we weren't in the business of DevOps there. We were in the business of car buying. And so I always felt as the CTO, like, it's a lot of money and energy going into something that obviously makes us more efficient and more productive, but isn't necessarily, uh, serving our end users.

Um, and so I just saw the opportunity and, and, and we started it in about 2019 into 2019. And that, that to dwell on your past, but I think one of the great things from your experience is you think the radical transformation automobile industry, auto selling, you know, from listing cars on a lot to doing it all over our phones and interacting, buying, selling, whatever it might be. Right.

Um, you know, that it'll all happen in one step. There's a whole series of innovations that had to happen very quickly over time. Yeah.

And I would imagine probably the team you took over wasn't quite there yet to take on that big of a challenge that fast. Yeah. And, and you know, when you're a high growth company, um, satisfying and serving your customers quickly, that's what it's all about.

Or the competition will. Right. And the competition will, and you know, they massive innovation there, uh, prior to me getting there, but it was slowing.

Um, and technology was a big part of that. And it, you know, it's, there's a lot of inertia behind a company that's been there for 11, 12 years. Right.

And decisions technically that were made. And ultimately we had to re-platform, uh, the whole thing, move it to the cloud out of data centers, uh, containerize, um, all of those things were a part of that, but it really didn't solve it. We, we built agile teams, you know, we had agile scrum teams, but if the underlying technology doesn't support that rapid iteration, you can have all the processes you want, it's kind of lipstick on a pig.

So we had to tackle what that core problem was. And that for us was environments being available so we could do pure true CICD. Yep.

Yeah. You're not gonna run an indie race on a gravel road. That's right.

You gotta have the, we needed a Ferrari ferri. Exactly. Well talk about what you're doing.

'cause there we have data to back up. I run our analyst firm, Texas Research, and there is a lot of interest on how do I get, uh, developers productive quickly, but in the right way. Yeah.

So they're not worrying about doing all that, all the make work I call it. That's right. But also they're not dealing with the worked on my machine problem.

Right. We all dealt with our whole career. So tell us about what you're doing.

Release. Yeah. So release is environments as a service.

Um, you can, uh, from with a click of a button, spin up an entire stack, uh, including all the infrastructure data. So it's literally reproduce your complex distributed application. And we do that across the software development life lifecycle.

So if you're a local developer, uh, and you need to share your local machine with your product managers, your QA managers, you can use our Docker desktop extension to share your, your, your local machine if you need to then have it in the cloud. Let's say you're developing a large microservice application and you can't run it locally because it's too complex. You can spin up a full environment, develop your microservices, uh, against a, a full replication of what your production environment looks like.

We have ephemeral environments, and those are really useful for, like, you do a pull request and an environment spins up automatically on that branch. You then can run all your automated tests, you can preview that environment. Some people call those preview environments.

Um, and that's part of what happens when you, uh, use us. And then we have support for managing, staging, any number of staging environments you want to create, and also production environments if you want to manage your production environments. So across that whole SDLC, managing, building, recreating and tearing down those environments is what we do.

Um, and it's challenging because every company that we work with has a different bespoke stack. And so I think one of the things that we are really good at is being able to take what you have, which might be in Amazon or GCP, it might be, you know, scripts and CICD, you know, tasks and things that you've created in order to get your tests running and, and, and get into production. The challenge for a company like us is being able to replicate your environments.

Um, and that that really is what we're the best at you, bring us what you have, and we will get it to a place where you can recreate from nothing, um, your environment, which is a really, really hard problem to solve. Exactly. The question I wanted to ask you, because to do ephemeral environments like that, to, to spin something out that quickly, that has to be declarative.

It can't be That's right. The hard coded stuff we've been running in our CICD pipeline for five years. So it sounds like that's part of what you're doing of how do you do discovery against requirements, helm chart and Yeah.

Are, are, are, uh, requirements files and things like that in the directory and whatever else you can pull from Yep. This is what your environment looks like now. That's right.

Let's be able to create that. Yeah. So we'll do an analysis of your repositories that make up your app.

Okay. There's a lot of fingerprints in there. Home charts, terraform files, docker files, docker compose files, package JS o Yep.

We then take that and create a blueprint. Uh, we call it an application template out of it. And that is this gold standard definition of your application, but it's the application infrastructure, data, all of it.

That alone is a valuable product. Yeah. How many people don't know that?

I mean, and it doesn't exist. Like when we started the company, we tried to find a standard that would be declarative, that could sh show you what your application needs to run. And it really doesn't exist.

It exists in scripts, it exists in some files over here, some files over there. Mm-Hmm. So we created a format to do that.

Um, and that is what drives the heart of the system. And it's not just the infrastructure and the software, it's also what is the workflow needed in order to recreate it. You might need to do a database migration, see a database warm up a cache.

You might, there's all sorts of things you might need to do to make that environment useful. And that's all part of that, uh, application template that drives everything. Then that can be checked into source code.

And if you wanna make modifications to it, add services, add infrastructure, you do it there. And then every environment gets that from that point forward. So there is a discovery process at the beginning.

Once you have that, now you've got this, you know, ever living blueprint that is your source of truth for what your application looks like. Great. I, I'm, I'm curious about, so you mentioned doing local development.

Yeah. Do people pretty, pretty quickly move every, even the development up to the cloud just because the whole environment's there or now usually you stay working on your own machine and it's connected to the cloud? Yeah, that's a good question.

It's, it's a hybrid actually, a lot of times where some developers want to develop locally. Um, but you can with release through our CLI run a command that turns your laptop into a, a, a mirror where it's syncing all your files into a cloud environment. So everything you change locally ends up manifesting itself in that cloud environment.

So doing GitHub pulls, right. Trying to, it's a remote, we call it remote development environment. Okay.

Um, and that becomes really useful when you start getting, you know, end number of services beyond just like a, a stack that would run locally. And it also is useful when you're developing collaboratively. You might have other engineers that need to see what you're working on, product managers, qa, um, and a lot of our customers like to use it because it looks more like production than what you're running locally.

Uh, developers like it because you can use any tools you want. You don't, you're not limited to vs code or Right. Whatever.

You use your, I've been managing a Vim file, VIM RC file for 20 years that if you force and get rid of me, I, there's no way I could do anything any other way. So, um, one of the design principles of that was let the developers use the tools that they want. Exactly.

Um, don't force me into something that I already have. What I, hell, I, yeah. Yeah.

Uh, so yeah, I mean, our, our mission is to help people release their ideas to the world fast. And we look at environments as a big important part of that that usually is left as a second class citizen, uh, and gets cobbled together and slows the organizations down a lot. Yeah, exactly.

Yeah. Um, you know, one of the things I think applied, uh, in what you said but didn't mention is oftentimes developers have to contact switch between different apps or environments Right. Or revs of software, or we deploy for different, differently for different customers.

That is complex. And that takes a lot of time to spin all of that up, make sure I'm in the right environment. Yeah.

And is it up to date with what's in production? So, you know, times 10, all the things you would do in one. Yeah.

Yeah. That's the same thing. Like, you know, if you have to switch to different project, click a button, you have that environment.

Right. So, um, especially when you get into more complex software development ecosystems, it's not as simple as I work on this one thing all the time, and I think that's a really good point. Cool.

Did, did you, uh, so how long have you been doing release? How old's the company? We started in 2019.

19. Um, yeah, we've, you know, grown quite a bit. Been it for a while.

Yeah. We've been at it for a while, and I think that's, uh, really important because the only way to get this to work is to see a lot of customers and see what they're struggling with. Yeah.

And the thing I'm most proud of now is it just works. Uh, well, and, and let me add to that, I'm guessing this, having worked with a lot of developers is it's pretty black and white where they're gonna use your stuff. That's right.

They, they like it, love it, or they hate it. Yeah. Usually it's gotta be love.

It has to be love to really keep it. Yeah. So when you're creating developer tools, development environments, what you're doing, you, you got a tough audience.

You gotta satisfy it right up front and keep, keep it there. Yeah. And keep moving the ball forward, but keep 'em with you so that they're happy.

And we become a very critical path in the SDLC mm-Hmm. If we stop working, they stop working, everything shuts down. So we spend a lot of time on reliability, making sure, you know, issues are dealt with very, very quick.

We have, one of the highest marks we have is our support team. They're all really great DevOps engineers that are, are doing that work. So yeah.

We're mission critical for our customers and we, you know, we, we spend a lot of time on that. Tommy, it seems like one of the challenges, I'm sure there are many in doing this, is the variety of environments that you have to deal with from a legacy mainframe application too. I'm in five clouds and I didn't set all those up.

They all look a little different or very different. You know, the variations are permutations are infinite. Infinite.

Exactly. Did you have to kind of pick a, a path through, there's this technology stack and kind of widen that as you develop out? Yeah, that's exactly how we did it.

Yeah. And what was that? I mean, we started with containerized applications on Kubernetes.

It was the easiest place to start. There's a lot of things built into Kubernetes that, you know, make environment creation a little bit easier if you know how you're, how to do it with namespace and Mm-Hmm. Um, that's where we started.

So at the beginning, the, the very first apps had to be containerized, Kubernetes, uh, kind of AWS applications. But as we've grown and the complexity of our customers have grown, that satisfied a certain slice of, of potential users. But it turns out, um, the more interesting problems in this space occur when you have a more diverse ecosystem and it slows developers down more.

So we had to expand that into, okay, now what if somebody is running, you know, their, their services on EC two on a vm, what do you do? Right? Uh, what do you do if they want to use ECS?

What, what do you do if they want to use anything in Amazon that wasn't within that slice? So we didn't reinvent the wheel there. Um, we leaned into open standards.

So Terraform, Lummi, A-W-S-C-D-K, helm, you know, the open standards where you would've defined these things already, you still use those. Our blueprint, um, essentially binds it all together. So the more complex you get, we now have the ability to broaden out and go build and rebuild anything that you might have in your stack.

There are still certain things we don't deal with mainframes, you know, we're, we're, that's why I mentioned that as an edge case. Yeah. We're still working, uh, and you have to be in the cloud.

Um, you know, we've kind of narrowed our focus to that, that, that being said, we've had a lot of interest from companies that aren't. And that just means there's a lot of opportunity to go, you know, solve a lot more problems. But today it's cloud-based and, uh, cloud native stuff.

Think about, uh, pipeline security software, supply chain security. I mean, a lot of focus on making sure I've got good, good images, base images, et cetera, code that gets created by developers. But the whole pipeline itself has to also be secured.

Yeah. If you don't poison the pipeline with whatever might get injected into it, uh, what do you do? How do, what do you have to do to secure that?

'cause you've got a lot of different people working in those environments and they can get created too, right? We let, yeah. We let those teams pick and choose what they want.

Um, you know, if they're using some DevSecOps tools that, you know, they've picked that they like to do image scanning or whatever it is that fits right in, you don't have to do anything different. Um, we really are just focused on the environment creation side of it, and being able to fit within whatever framework they currently already have. So you don't dictate, we don't dictate it.

We let you use whatever it is you're gonna use already. Um, all of the environments end up running in our customer's cloud accounts. So they have full control over all of what is created.

Um, it's not hosted by us, it's, it's just, we're like a control plane that, that, that does that. And if they want to bring in their, you know, security scanning tools or whatever those things are, they can just do it right within the way they do it today. Very cool.

Excellent. Any, any announcements at the show you're making or? No, no, no.

Big announcements. Um, you know, we're, we're here talking to customers about their challenges and problems. We do have stuff coming up here pretty soon that, uh, there's a lot of interesting things going on in ai.

Um, I do wanna ask you about that. Yeah. One of the things I've been working on is how do you, how do you start your AI projects so they'll naturally flow into a workflow pipeline as opposed to my experimentation.

That kinda shows up as an oddball thing that nobody knows what to do with. Yeah. We look at that exactly the same, uh, with AI as we do with regular, uh, environments.

Um, the underlying infrastructure's different. The software stack that runs on top of it is different. Mm-Hmm.

So let's say, you know, you're a data science person and you wanted to get started. You have your Python notebook that you're working on, but you want to train a model, run it against, you know, some big GPU systems. That's a pretty difficult problem for a data scientist to solve.

So we look at that problem as it's a flavor of an environment. Um, and we have some partners that we're working with there that will allow us to spin up, you know, let's say you need a thousand GPUs to run your, uh, train your model against, that'll be accessible through an environment, just like it would be any other pipeline that you're using with us in order to create other environments. So it's a really interesting time.

Um, software development, application development is changing pretty rapidly. The good news for infrastructure companies like us is that machines are needed to do all of this. And, and making those machines useful to developers, AI developers, data science, uh, developers is, is a similar problem.

It just has a different twist to it. Different end users, A big impact on people's productivity. So, and cost savings.

Yeah. Uh, those things are not cheap these days. Oh no.

And so, you know, we see a lot of opportunity in doing that in a very efficient way. Um, so there's some really cool stuff coming on that front. And we built a, a bot infrastructure.

ai. Um, it was kind of an experimentation of ours just to kind of get our hands into it. A lot of us have done that.

Right. Kind started that pilot and it taught us a lot about what's needed here, how good the open AI models are, how fine tuning is gonna be needed to do some of the more kind of future looking infrastructure things. ai, you can see some of the work that we've done up there and, and play around with it.

It's all free. ai. So check it out.

Yeah. Folks, sign on. You have like sandbox or test Yeah.

com. com. Okay.

Release. com, which is where our environments as a service is. ai is kind of where we're messing around with AI stuff.

Oh, I see. Okay. com, you can just start for free, right on the homepage.

You just click the button and off you go. Excellent. Tommy, fun talking with you.

And yeah, you too. We'll have you back. Talk about some more AI stuff.

Yeah. Is that developed? That's awesome.

Congratulations on the success and, uh, great to meet you. Thank you. Look forward to talking to you again.

Thank you. Another great conversation. We're tossing it back to you.

Back to the control room. We'll be back in just a moment here from Kku Con.