DevOps Past, Present, Future and Cloud Development Environments – DevOps Chats Podcast EP4

Hey everyone, I am Alan Shimel And Mitch Ashley. And you're listening or watching DevOps Chats. Fantastic.

Hey, Mitchell, I think we, it took us, was this the fourth one that since we restarted the series and we finally got it right? That's right. Old habits never die.

I guess we, I guess they do after the fourth try. Well, we just had to get our timing down and because, you know, when we used to record these, we didn't have Zoom and latency issues. We were sitting next to each other.

That's right. Yes. And, you know, and, uh, you know, and Chantilly, Virginia are getting ready to go meet Oh, Wherever we were on the road.

Yeah, exactly. You know, but, but that's progress for you. Um, or maybe not.

Anyway, Mitchell, we, we've got a good DevOps chat, uh, lined up for this week. We we're gonna start incorporating something we really wanted to do, which was to kinda leverage this amazing library of interviews that we have from Textron tv Mm-Hmm. You know, that really take great dives into, you know, subject like DevOps.

We look at it six ways from Sunday Right. Into every aspect. Yep.

And, um, so I'm excited to do that today. And we're gonna, it's an interview you did. Yeah.

With, uh, Ben Potter from Coder. We'll, we'll get into that. Very much so, you know, there are over 6,000 videos on Textron tv.

Now. It's, that's crazy. DevOps or, uh, Textron tv.

YouTube channel is just like, hacked with content. I think also it's probably 4,000 or more there. We might have purchased it at one point, but I think it was 4,000 or something.

And we'll be adding more to that, including this podcast. We're gonna start running on the YouTube 'cause we wind up playing episodes of the podcast now on the Tech Drunk TV Daily Feed, which then makes its way over to the tech Drunk TV YouTube channel as well. So, you know, this is like, uh, trying to look up Old Star Trek episodes on where you can see 'em on streaming tv.

And they're on, they're on Paramount and Netflix and, and Pluto TV and, and, uh, you know, all these other stations. It's the same way. Joined.

I joined a Facebook group, um, that's all about the original Star Trek. And I get all these posts, you know, like, remember this episode, remember this, the Doom Machine? Remember this?

Mm-Hmm. Who was this character? I, I, I think I belong to the same ch to the same group.

That's pretty Freaky. I told you, I recently got a really great, I haven't seen you yet, so I haven't wor I haven't even worn it yet. I may just save it for a while.

But it's, it's the Star Trek episode with the alternate universe Spark with a Beard. Oh, yes, Yes. Uhhuh Evil Spock, but kind of, you know, still good spot.

Still, still, right. He still had the Good Core. Yeah.

I can't, maybe I'll save that for RSA. I'll wear that one day. I think So Con or both?

Maybe both, Yeah. Or maybe Q Con in Paris. Um, Mitchell, before we jump into Ben Potter interview, though, I, I thought we'd spend a little time talking about DevOps next, as we're calling this great report.

You're, you're starting to fo frame out right now. Um, but really the report is just a reflection of the actual marketplace. Mm-Hmm.

com. com. Wow.

Time Flex. Yeah. And DevOps, you know, DevOps has been around at least two years before that.

Mm-Hmm. At least maybe three. Um, but it's not the same DevOps.

Well, in many ways it is, but in many ways it isn't the same DevOps as it was 12 years ago. Right. And why don't you, you know, take first crack at this, you know, how do you think DevOps is different, or how do you think it's even the same as it was then?

I still remember you calling me up and say, Hey Mitch, um, there's this thing called DevOps. Do you know, know anything about this? com, we're starting this site.

And, you know, I was like, no, I'm not really that up on it. Let me go figure it out. And I went and read Gene's Kim book and his book, and then introduced it to the IT team that I was running back then.

Um, but it, it was really early and it was, it was kind of hard to figure out exactly what it was. And then people started doing it and kinda learned some of the principles out of the book. And one of my first ahas was, okay, it's not a technology, it's a how, it's how you do software, how you create software.

And technology is all in support of that. And it's kind of rethinking that. And of course, the having the cloud and elastic resources available to you could change how you do software and microservices and Cloud native came along.

So it's interesting, it's kind of like the way Agile was that it really transformed away from monolithic thinking or waterfall thinking to more sprint and iteration, but doing that in a whole software development process and, and pipelines. But it was still very tool centric in terms of, this tool fits in this slice, this tool fits in this slice and this fits here. And they all have their own ecosystem of plugins, or maybe they integrate or maybe they don't.

So you end up in the tool integration business as a IT team or development team. And today we're, you know, it feels like we're at a different place. I mean, it is, it is not everywhere.

And not everyone is doing DevOps at the same level. They're all on their own kind of curve of adoption. Some have been doing it for quite a while, but we've gotten to this place where there are platforms that you can do end-to-end DevOps, if that's how your organization kind of thinks about solving this.

There are sort of much broader suites. We start out as a CI tool and now we're a CI ICD and we're this, this and that with security, with ai, with this. So all, all that to say, the reason why we're doing this DevOps next report is to try to lay out and help everyone, all of us understand, including, including me understanding where we really are in, in the evolution of DevOps, but more importantly how that's setting us up DevOps next for the next three, five plus years as we introduce more things, more ai, more generative ai, more different kinds of applications, more mobile to the AppSec that we're doing already on the web or whatever the next technology or, or approach, uh, driver that comes along at modernization, whatever it might be, to, to really recognize that it isn't just a set of discrete disciplines that we're hanging together in a linear process.

It is really an ecosystem of capabilities that we can craft into the best way to create software. I love it. You know, listening to you Mitchell, I'm, I'm reminded of the old commercial line thing was, or, and Wells, you know, for Gala Winery or whatever, you can't make wine before it's time uhhuh.

And you know what, you can't make DevOps before it's time either. Can you, can you have a DevOps without Agile? Can you have a DevOps without lean Mm-Hmm.

Could you have DevOps without the cloud? Exactly. Can you have cloud native without DevOps?

I think that we're pretty sure. No, but Yes. Yeah.

I mean, to your, to your point is it is, I mean, whether you're gonna go go back to the manufacturing side or think about how we're using Agile ling and software, the other thing that's happened with DevOps, you know, well, as I do, is it's the ideas behind it. Everybody has said, well, I can do that in my part of the business. Right?

I can do that in the product group. I can do that in operations. I can do that in my business strategy and planning, you know, this iterative cross-functional teams, all those things we learned in Lean and Agile and brought in with us into DevOps.

It was interesting when I think one of the first DevOps, uh, enterprise summits, they went to the auditors had a panel and they're all excited about part of this. They could see how they could play as part of this whole process. And that, that, that was an eyeopener.

It's like, okay, there, there's really, this has gone far beyond what we thought it might be Far beyond just developers and ops. Exactly. Um, and, and I think that's another, so I, I think that's a big lesson that will probably shine through in the DevOps next report, which is, as much as everyone wants to focus on tools, it really isn't just the tools.

It's, it's the culture of having a cross-functional team of doing things like, uh, uh, blameless postmortems of, of, you know, communication, open lines of communications of trying to automate, go faster but better. Mm-Hmm. Right.

We do it with our software, but we want, you know, we talk about platform engineering platform. Engineering's part of this whole discussion too, right? We want to, we, why do we do platform engineering to go faster, to do more Activity With less Right?

To, it's that it's the same driver. It's part of the same dynamic of, of what, you know, what drives DevOps. And you know, I wouldn't have guessed this 10 years ago because I, I think fell into the chapter that a lot of other people did, which is, you know, we focus on the tools.

We focus on the tools. Oh yeah. Well, that's what we buy.

Yeah. com, right? Absolutely.

So we focus on the tools, but I, I'm, I'm really looking forward to see what do we hear about from a cultural pers perspective Mm-Hmm. On, on DevOps and how people are taking that undefined, you know, axiom around, uh, culture and applying it into real life business situations, not just software development. I think that's a, a big piece of this.

It's interesting for me 'cause, you know, uh, the gray hairs mean I've been around for a while. I remember the methodology wars, and it's about this is you have to follow the methodology and which methodology is the best one, and this is the next better one. And you know, it never set right with me because every organization operates differently, right?

Yeah. You can't force everybody into one mold. And this is the right, because I call them the religious methodology war, I mean, it really was.

It's just like, you know, you're going to heaven. You're not, 'cause you're not following, not following the methodology or whatever. And, and when Agile, kind of agile came out and really made a lot of sense to me, 'cause I'd already been part of the total quality management training, the iterative improvement and all the different techniques that we learned there and way of making it, making iterative progress and, and improving quality, what whatever you're working on.

com to kick that off, it just, it just seemed like a lot of things came together at the right time. Yeah. Timing's everything we know that from Yeah, absolutely.

Timing, timing is everything. And, and I, I think you're a hundred percent right. You know, I'll tell you, by the time this podcast is available, our newest site, tech strung, ITSM will be out.

And a lot of people may be saying it, TSM, that's not new. Where, where are you? I got the AI thing.

But why ITSM? Because when we think about the religious wars around process and around, you know, how to do things for a lot of people, ile, ITIL, right? IL uh, is the very definition of it.

Definit Mm Mm-Hmm. But there's much more to ITSM and even ITIL itself has changed over the years. Yeah.

And you know, in my, and I wrote, this was my opening, uh, my opening story on, on Techstrong, ITSM. My opening post was that, you know, ITSM is part of this continuum that we have, you know, agile to where agile leaves off DevOps picks up where DevOps leaves off ITSM mm-Hmm. Picks up.

And, and of course there's places in there for things like platform engineering and SRE and SLOs and, and you know, all of the various disciplines that have developed to fill in the gaps here. But there is, it's definitely a continuum. And you know, I, and I think one of the lessons learned is, again, would DevOps be here if not, but for Agile lean and what would be cloud and blah blah, blah, had idle not been what it was, would DevOps have evolved differently?

Absolutely. Oh yeah. And had DevOps not evolved, would idle still be what it was then instead of what it is now and what it's morphing into?

That's, that's a perfect example. I remember interviewing a couple of folks from Axios that wrote, updated I Title iv, I believe it is, and really Going Axo, it was Axo Axo, thank you very much. Right?

Um, and and they were, and they, and I didn't realize it, but they had gone back in that iteration and said, yeah, we kind of went down the process for process sake. That's my interpretation. And prior, it just got a little too dogmatic, again, my words.

But they went back and said, how do we incorporate this stuff from Agile and DevOps? And, and they did it. They did it at yeoman's yo person's job of trying to really open it up and make it more flexible and adaptable.

And I'm sure that that process continued. But I think that at least one of the reasons why, you know, ILE and ITSM, you know, both are still widely adopted. You know, they, they didn't just kind of go by the wayside and something else replaced it.

They're still no, a huge part of No, but, and they're still evolving as is DevOps Mitchell, we could talk about this all day, but we're never going to get to your Ben Potter interview. Um, why don't we, why don't, why don't you set the table for that one? I'd love to.

Um, uh, a few weeks ago I got to speak with Ben Potter. He's had a product at a company called Coder. And I, I've long been interested in how the development environment is changing for software creators and, you know, how far ID IDs have come and cloud development and developing at a Starbucks or in the plane and on the plane.

And one things that what coder does is, is provide cloud development environments, right? So you could quickly stand up or utilize in an, in an environment. And if you're starting out in software, it doesn't sound like that big of a deal.

Maybe it saves you some steps, right? Um, or if you're starting out on a new project, you know, it's a, uh, it, it's a, a, a saver an aid when you're working in an organization where you might be supporting five or six applications, or even two or three. There might be half a dozen environments or more for each one of those applications.

Here's this version with this database that we're supporting for these customers. Here's the second iteration of that. And you've gotta have, you've gotta have environments to go to be able to write code, test code, deploy it for each one of those iterations.

And it gets really complex really fast. And as I was talking with Ben about, you know, so I don't do this every day anymore and it's for me to get, you know, okay, what do I need to update to get this in sync with what, what's out there for that, even for, for our environments? You know, it, it's, it's a cognitive overload and I'm not doing it full-time every day across a lot of complex environments.

And so it's a real productivity boost when you can turn it on and have that environment. And so it was pretty fascinating talking with Ben. 'cause he talks about AI and some of the new, new things that are happening.

I think folks will really enjoy listening to Ben. So any thoughts? Absolutely.

Take a look at the video or listen to, I know, I, you know what? I know coder is gonna be with us at CubeCon in Paris. I'm looking forward to catching up with them in person there.

But let, let's roll, let's go to the video from a recent text on TV interview and we'll be back right after. Well, hey everybody, have a great pleasure of being joined by Ben Potter. Ben is head of Product with Coder.

Welcome Ben. Mitch, happy to be here. Excellent.

I'm glad to have you on, um, talking about great things. You know, and it, this has come up a couple times for me recently chatting and when I was at, I think in Chicago and, and talking about, um, cloud development environments. Matter of fact, even a friend of mine on an AI pro AI project, and I were talking about that, so I'm really intrigued to chat with you.

Um, let's just set some context for folks. You know, if you don't know what a cloud development environment, hopefully the name describes it well enough, but is there any more you should know when we're talking about what is a cloud development environment? Yeah.

The, the very basics are, we're trying to replace developer laptops, meaning, um, developers will always need a laptop or a desktop. But, um, so many applications and, um, are moving to the cloud. Yet developers still have to run these applications, whether it's one service, um, 10 services or even dozens of services all on their local machine or some hybrid where they're running some on their local machine, some on the, the cloud.

And, um, as these environments get more complex, especially in, in large, like enterprise organizations, um, it, it becomes unrealistic to be able to run these on a, on the, the local machine, especially when, uh, developers essentially forced to use a lockdown windows machine. Mm-Hmm. So what we see happening is developers are creating virtual machines.

They're running their code there that also has a drift from the place they're deploying it. So what, what a cloud development environment tries to do is give developers a very identical environment to that of which they're deploying, that they can test and, and develop against using their, their favorite editors, whether that's vs code or JetBrains. So sometimes when people think cloud developer environments, they think of a, a browser editor with limited tools and limited keyboard shortcuts.

Um, that's not the case. Developers can keep using their editors, but really they have an environment they're developing against. It's very similar to where they'd be deploying.

So that's kind of the main concept, or at least that's how we define it at, at coder. Great. And then do you actually, well, you know, IDE tools, like if you're, you know, you're using Visual Studio or whatever your favorite Python or whatever IDE is, some of those have integrated with it, like home Brew for your Apple, right?

To be able to, to do, uh, uh, package management and update and set environments in different contexts. I have to be honest with you, at least for me, I don't do it every day, but when I do it, it, it's kind of complex to go back and remember now how do I set that? Where, where's that is do I need to upgrade this?

Is that set up with my environment where I'm pushing this to it? It's, you know, it taxes me and I, you know, I'm not doing hard stuff either. Yeah, that's, that's exactly right.

We, we have users who have to follow maybe 30 to 45 steps to get their environment set up. And, um, those, those steps are oftentimes very specific to a, an operating system or a, or a version of an operating system where if someone upgrades to an M1 Mac, for example, and they were previously on the, the Intel ones, it's a whole new set of steps and that hasn't been updated. So what, what a lot of our users, um, do is they, they automate away all those steps.

So developer can just click a button and using these powerful cloud technologies such as Docker and, and, and virtual machines, or even Kubernetes, uh, developers can get these reproducible environments with all their tools set up. So essentially it turns those 30 steps into, into one. I mean, someone has to, to automate it and create those, those images.

But it's, um, kind of a one to many relationship where you kind of have the, the confidence that everyone on the team can use that, those same tools. Cool. So what's the developer experience like?

Are they using an ID that's run IDE that's running locally on their environments, connecting to a cloud development environment? Are they using an IDE in the cloud? How does that work?

Yeah, That's, that's a really good question. And there's, there's two paths that we can support. So the, the modern, um, editors, which, uh, we vs code and and JetBrains are the two main ones have support for running them locally on your machine.

Meaning you can have your theme, your keyboard shortcuts your layout, but then you're connecting over essentially SSH into these remote servers where the file system and the terminal is. So all the tools are pre-installed on the remote server, but then it's kind of this like thin client server model. The, the other option is entirely through the web browser, which is, which is pretty magical.

Um, both Microsoft as well as, um, US at coder have a version of vs. Code that runs entirely in the web browser. And in that case, the full IDE is running, um, remotely.

And a developer could connect with even an iPad or, or a Chromebook and, and do the development that way. So that one's, um, it, there are some limitations. Um, it's, uh, you don't get all your shortcuts, but if you're kind of quickly switching between services, it's, it's a great workflow.

I could see that especially like, Hey, Ben's on vacation, I've gotta step in and, and yeah, I kind of know that environment, but I'd sure like a turnkey press a button, I'm a press a browser, you know, browser key I'm in, I'm in, and I don't have to worry about, you know, making sure my IDE will connect to it and Okay. You know, where's the cer or credentials, et cetera to get to that. And then how do we move around?

Yeah, that's exactly right. It's kind of, it's, it's great for those kind of times that you only need to go into environment maybe once a month. Um, it's maybe a service that you don't always maintain, or like you said, like, maybe I'm on on vacation and I only have my, my iPad and I need to hop on and, and do something.

You can kind of have the, the ease of mind that it's all there and, and working. Mm-Hmm. And we, we talked a lot about, I'm trying to remember the term, but the, uh, cognitive load, that's the word, um, that, that we put on developers.

We do that in all kinds of jobs, but we especially put on developers of, there's cognitive load of building your environment and there's cognitive load of like doing your job, and then there's everything else too. And that content text switch across all of those is mandate. I mean, that's where you lose your productivity.

You know, I, I I think of software, a kinder, writing a book. You're not gonna write a book a sentence at a time. You're gonna sit down and write a chapter or write part of one or this part of the story or whatever, and you gotta stay there a while.

Right. You can't deal with interruptions, why's, why developers wear noiseless headphones all the time if they aren't working from home. Um, you know, how does a cloud environment help you with cognitive load and context switching?

Yeah. Our, our tagline actually is, is keep developers in flow. Um, and we use that at both internally.

So how can we make sure that when we're meeting with the development team, it's only in certain times and we can reduce meetings and, and also externally in the, in the products that we build. Um, one of, one of the main ways that, that we help with that is there's this huge expectation, um, from, from like the, the, the DevOps kind of paradigm for developers to start building their applications with best practices in mind, whether that's mm-Hmm. Where they download their packages from, or how often they scan or, um, what kind of languages and, and libraries they use.

And, um, with coder, you can essentially create these, these recipes for developers to get into an environment that has all of those things installed for them. So if a developer goes to install a package, they don't even need to configure or run security scans. You can have confidence that they're downloading it from a trusted source Mm-Hmm.

Wherever that those artifacts are and whoever you're scanning it from. Um, we're also seeing that with, um, AI and LLM tools. We have a lot of our enterprise customers re-installing these tools in for the developers so that it can kind of handle these, these operations that normally you, you, it's pretty difficult to, to enforce or even like encourage developers to use these best practices, but by having them by default in their editor where they spend the majority of their time, they don't have to spend a lot of time switching out of your editor and, and doing other stuff.

I think there's like a pretty famous quote that, like, it takes 15 minutes to, like a context switcher to fully get back into flow. Mm-Hmm. So, as much as possible, having these best practices pre-installed inside your editor as opposed to having to go out and read some wiki to, to get things set up the right way, um, the, the better.

So we're, we're essentially trying to only like only really let developers focus on like what, what they need to, which is like the, the libraries and, and then the, the code and then the rest can kind of take care of, take care of itself through automation. Mm-Hmm. I like to, I like to say the best way or fastest way to get something done is not to have to do it at all.

Right. Like, just let it be done for you. Right.

If you can, um, well, let's talk, let's talk about the AI side of this. 'cause one of the questions I have is about a cloud development environment is, you know, not all the resources could be put in the cloud or into your environment, right? I have databases, I have APIs that I'm testing with to third party services by own applications, you know, a plethora of things that, you know, no, there is no, no application is an island, right?

It's, it's all connecting to everything. How do you deal with that, um, deal with when you need to talk to other services or maybe in your LLM your training data and you need to, uh, keep that updated with the, the latest that you're using or that's coming, you know, getting ready to get pushed to production. How, how do you deal with the external things that aren't in your cloud environment?

Yeah, so we, uh, uh, uh, have a, a kind of policy, the way we deliver our software that we only want it to be self-hosted. Meaning we give the software to our customers and they install it in their AWS or, or on-prem environments. Um, that's because we have a lot of, um, secure regulated customers who mm-Hmm.

Very, really much value owning their, their network, so that that gives them control over which endpoints and, and network things they want to expose. So one argument, or one example I had earlier was ensuring that artifacts only get downloaded from a secure artifact store as opposed to the, the public registries such as Docker Hub or NPM, where, um, there's no vulnerability. There's so many vulnerabilities there.

It's, it's all good. It's All secure, don't worry. Exactly.

Um, and, and on the, on the AI side, we, we do have, um, even some of the most like regulated customers using AI with coder, but they have control over that those network firewalls, whether they have an an on-prem model that they're using or something, um, exposed through chat GPT, they expose only the, the aspects that they want. What's super interesting about AI to me is that, um, even the, the, the customers that really value security are accepting the risk to use these AI models because of the productivity benefits that they have. And, and at coder you can kind of, well, we use it because it's self-hosted.

You have control over the full, the full network that it's, it's deployed on. Um, another use case we've seen is it's, uh, pretty difficult to get developers access to, to GPUs. Um, Mm-Hmm.

There's, there's a way to for developers to like schedule if you're doing AI development, maybe to schedule out to a build farm. And another use case that we've seen for people who are doing very advanced AI development is they wanna fall GPU workspace in the cloud, or even multiple workspaces. So we, we have templates that code or to let developers get a, a workspace with a GPU attached.

So if they're training a model or working against a, um, if they're working against a local LLM that, that isn't like training based on your company data, that they have the, the horsepower to do so in their, in their cloud. Mm-Hmm. Excellent.

Um, how about data protection? Right? Test data, right?

Uh, you, you need to test with realistic data. Sometimes it's, you know, data that you don't wanna escape, right? You, you don't want that data leaked.

How do you protect assets like that? Sounds like what you just described would help with that if you're running it within your own, you know, you're in your own environments with your own security controls. Yeah, that's, that's a really good question.

Um, the way that we're seeing our users doing this now is they're deploying a, a database with, with either customer data or mock customer data inside the same network that they have coded, deployed in. Meaning that a developer doesn't have to open a firewall in their local machine to access it. They're only connecting it to it through their cloud, IDE.

So this cloud IDE is on the same network as the customer data or test data or mock data. And multiple developers are able to develop against it. So they're not downloaded onto each CDE, they're not downloaded onto each local laptop, which is a huge security risk.

It's all staying within the boundaries of, of your network. And it can even say in within the boundaries of a, of a web browser, which then can be secured to make sure people aren't copy and pasting out of it and, and doing things like that. So we, the, the, the real benefit there is because you can put coder in your own network where the data is, it can never nec it never has to leave that, um, that network.

It can all just stay in, in the web browser or on that environment. Um, so kinda last, last question. I, I could talk to you for another two hours, but last question is, um, you know, right.

Tool for the right job, right? Um, what maybe what are things that aren't a great, you know, fit for trying to use a cloud development environment? So don't go down that path.

That's not the best way to do it. Yeah. Anything that's super, um, latency sensitive.

Mm-Hmm. So Web development's a perfect example of what's great. You can develop against a, a modern editor such as BS code, you can preview your changes in the web browser.

Um, that's great. If you're developing a video game, um, you'll run just, I was say game of development. Yeah, yeah.

The, the game is, is compiling and, and developing, uh, and essentially being sent back so you can get a full desktop environment through coder, but it's, it's pretty slow and it's, it's not ideal. I'd, I'd much rather do game development on my, my local laptop. Mm-Hmm.

Um, another one that comes to mind is, is iOS development. Again, this is one of those things where technically it could be done, we created our, our product to run on on Mac hardware, but there isn't a great solution for provisioning mac hardware for iOS development. There, there's some solutions out there that I'm closely looking at.

'cause I'm, I'm interested. Um, but if you're doing any form of kind of app or game or even even desktop development, it's not ideal. Again, it, it can be done if you, if you have some of those, those pain points such as like data security, but, um, web development using visual studio code as well as like jet ranges.

This really the, the sweet spot that we're seeing now. Um, what, what I think some people think when they hear CDE is that if you have a large complex service, it's actually not a good fit for CDE. And we're actually seeing the opposite, which is the more complex the service you have, the, the more you benefit from automating the steps away and giving it to a developer.

Um, and I think something else is if people, people think maybe if they're later or earlier on in their cloud native journey, that it's not a good time for CDEs until they're fully onto the cloud. And the opposite is also true. We, we have, um, some of our largest customers are using CDEs to get more developers to develop applications for the cloud with those, those practices.

So, um, those are kind of two things that you, you might think wouldn't be a good fit, but would, but yeah, it, the, the game development is, is not, it's not great. I, I tried it. It's not, it's not fun.

Yeah. It's always those edge cases or, or unique cases. And you Yeah.

You know, you mentioned Mac and Xcode isn't really happy to run itself in other environments. I'm sure that's a bit of a challenge. Well, where can folks kick the tires?

You know, um, anybody that's a developer technical person would like to, you know, let us turn it loose. Let us check it out, kind of see how it works. Yeah.

com and our GitHub is also coder. So it's pretty, pretty easy to remember. Um, on the, the website, you can get a trial to try the, the enterprise features, but the core product itself is actually open source.

So, uh, if you're a developer and want this either for your, your home setup or maybe a, a small team entirely free. com as well. Okay.

Excellent. Well, Ben, it's been fascinating talking with you. Um, I'm definitely headed there.

I'm gonna go check it out. com right? com?

That's right. Yeah. com.

You always get asked these days, 'cause sometimes it's not. I hope you'll come back again. It's, uh, been fascinating talking with you.

Ben Potter, head of product with coder. Thanks, man. Yeah, This was great.

Thank you Mitch Mitchell. That was a great interview. Did a nice job there with Ben, and, and good for them.

I, I like what coder's doing It. It is, and Ben was fast, fantastic to talk to because he's working with so many different customers and he's got all these experiences and use cases and as well as heading up product. He's not just a product, you know, here's the, here's the roadmap and here's where we're going.

He's really out there pressing the flesh and rubbing elbows with developers and figuring out what they need. So I think that's what made it such a compelling, uh, interview and discussion with him. Yep.

Many thank you much many thanks to Ben and the coder folks. Um, Mitch, I think we're probably a little over time because of the interview and everything, but this was a great DevOps chat. Um, we'll be back next week with another one.

Sounds good. Same place, same bat station. Bat channel, Right?

Yeah. Wherever you're listening to this, keep that dial where it is for, uh, tech Strong and DevOps Chat. This is Alan Shimel And Mitch Ashley.

Take care. We'll see you soon.