Managing On-Prem Developer Environments with Daytona CEO Ivan Burazin

This is Textron tv. Hey guys, thanks for the throw. We're here with Ivan Burin, who is CEO for Daytona, and they're building a platform for developers to provide a better experience that runs in an on-premise environment.

And they just picks up some additional funding. And we're gonna dive in. Ivan, welcome to show.

Uh, great to have me, uh, thank you Mike. So describe what it is you guys are actually doing, because we've been trying to manage developers and create these platforms, and everybody's been talking about productivity forever in a day, but what's different? What do we need to fix?

Uh, sure. So, um, our team's history with trying to help, I guess, developer velocity and, you know, make the developer experience better. Started with, I mean specifically with on utilizing the cloud or removing development off local host or, or at least for Segment.

Um, started a long time ago. So we started that in 2009. Uh, me and my co-founders, although I can say that we made a better developer experience then since, you know, um, technology the way it was back in 2009 was not, um, super ready.

We iterated on it for a while with a company called Code Anywhere, uh, but ultimately sort of paused, um, did other things. And we came back very recently now with Daytona. Um, the reason why is that we've seen a lot of large companies and so some of the companies people have, you know, most of the companies people have heard of.

But uh, some of the companies, some of these companies, people have heard that they're doing this. And so companies like LinkedIn, Uber, Shopify, Stripe, Palantir, Eventbrite, all these companies have built an internal, we call it a development environment manager. So it's a basically a tool that will manage development environments for engineers.

Some of them are only cloud or remote, some of them are local and remote. Um, but the idea is to have one standard type of developed environment so that engineers can onboard instantly versus, you know, wasting a couple of days, uh, allowing engineers, you know, check out a PR really quickly and work on that. Also, um, it enables engineers to, um, have all infinite scalability.

And it's not just like there's an argument that, you know, there's new Apple processors coming out every generation now exam three, you never need more. But the idea is not just that you need one developed environment that's larger. You basically have infinite, you know, disposable laptops, um, at your hand.

Um, and the last thing is basically security. If we're, if the product, um, which manage to develop environments is sort of behind the company's firewalls or on premise, so to speak, um, it is this as secure as it can be, right? It's not, the source code is not on some laptops somewhere.

And on that point, um, specifically I know that Uber was fined, you know, $120 million for source code leakage because source code that was on a laptop got, um, leaked. And with that, with some credentials for database with that was probably mine. And your credentials as Uber, you know, users back in the day, right?

Um, so like there are a lot of things that can help out with this. And we've seen that the market or these large companies have wanted this, but there's not a vendor on the market that allows that. And so that's sort of where we fill in fit in Is that changing.

'cause developers, so many of them wanna do, um, coding on their laptop and we've had a challenge getting them to move into the cloud in the first place 'cause they just wanna have it locally. So, um, we can move this to a more secure approach, I imagine. But how do we encourage the developers to play ball?

So the way we're looking at it is that, so there's some people call these products, um, cloud development environments and we don't on purpose. Um, when creating Theona, our inspiration was, um, was Spotify, um, which has basically, there's a team that's been running their standardization of development environments for like seven years. And they started it first by creating a standard that works on their local machines.

And then later on they expanded that to the cloud, so to speak. And so basically what they did was they enabled engineers to be able to pick and choose work where it suits them best, right? It's like, it's like, no, we're not gonna force you.

Well, depending on the product, maybe some projects have to be in the cloud or have to be so secure. But in, you know, for most things, if you're doing some front-end app, you might as well do it local because it'll work better for you. But if you have this large monolith, they have to spin up and it has to work and you want to have everything that's close as you can to sort of develop, uh, uh, a deploy a production version, then maybe spinning it up on a clog, which has all these resources may be better.

Um, and so that was inspiration for us, which basically again, enables developers to, you know, choose the right tools for the right job. Plus we're not talking about a browser-based editor. All the engineers will basically work on their local, you know, jet brains, uh, whatever it may be or vs code or whatever.

Um, and only the actual compute is off their machine. Hmm. Where does this fit in the DevOps workflow?

Uh, 'cause we have so many other tools that are floating around. So does this get integrated with my CICD? Does it sit with some sort of, uh, registry and portal?

What's the process? Oh Yeah, it actually, they're also companies that I, that have thought about creating a product, but they encompass the entire sort of DevOps workflow into their product, which we both know in larger companies is very, very hard. We basically fit into that.

So the same way developers have been working in your company, they will continue to, this is just one step before, um, everything else. And because a product like ours, uh, uses infrastructure as code to set up the development environment, it makes that flow from, uh, development testing, CI staging, whatever, so much more easier for the DevOps team as The developers themselves. Do you think that as a result of this, they're gonna spend more time writing code?

Because some people would say they only spend about two hours a day writing code and the other portion of their day is kind of managing development environments and maybe playing video games. But what is the impact on productivity for here? What should people expect?

Absolutely. So the, we did our own research and we've also like found a couple of, uh, papers on this research and we found that, um, engineers program or develop, um, so for their time that they sh would be working so outside when you remove, you know, um, overhead in the sense of meetings and administration, whatever that time that they have left anywhere from 50 to 70% of that time is actually lost on, you know, setting up development environments or waiting for bills and tests and stuff like that. All of which are a large portion of that can be basically erased, um, with something like this.

So you're talking about quite a substantial, um, advantage in productivity. Do you think that there are times when developers have a moment of inspiration, but the amount of effort required to go executed, they basically don't do whatever it is they just thought about. That was awesome because it's just gonna be too hard to get started.

Exactly. And that also helps because if you are, if you use, I mean, if you set a definition through infrastructure code for a development environment, be it, you know, utilizing Daytona or whatever it else is, um, the time it takes for a developer to get up and running. So time to first, hello a world so to speak, um, is basically counted in seconds, right?

Versus, I'll give you an example where a colleague of mine wanted to test something out and he said, oh, I'm gonna spin up, you know, an open source project. I won't name which one. It's super probably right now.

Um, and I'll just see how it works. It took, he was working on it for the last four, eight hours, so it was supposed to be just something, you know, really quick, let's test it out and see how it, um, how it works. And so he actually had a task in sort of Jira connected to that.

So he actually pushed through it and got it done. But if you're thinking about the average developer who's like, you know, in an afternoon or a Saturday or even during work, it's like, oh, let's try something out. Um, and you hit that kind of hurdle, you're probably not gonna push through, right?

So as a vendor, a software creator, um, or anyone else, like you actually want something like this, um, or in general a standard standardization development environment because it'll enable developers to pick it up really quickly. How hard is it to set up something like Daytona? What's involved?

Oh, to set up a Daytona, um, it takes you 25 minutes, um, mode. And there's two steps right now. So there's, for now you need to have a, there's an installer, you need to have a public domain, um, and you have to have a, um, identity provider or one of the identity providers being, you know, GitHub, GitLab or a Bitbucket.

And so those are basically the only steps that you have. And the rest is just installation. Um, and it takes about 20, 25 minutes, that's it.

And you're up and running. You can share the URL with your colleagues and they can log in with their credentials, um, which, and they basically get up and running. So the time to getting people up and running in a company is very, very small.

Who drives the conversation. We've heard about the rise of platform engineers, but, um, there's also SREs and all kinds of folks. So who's kind of stepping up and saying, yep, I'm gonna run the developer experience.

So I mean, we, we target, we have targeted and talk to the, the people that you mentioned right now, um, because that seems to be also the sort of the hottest trend right now. Platform engineering has to be super, um, on CubeCon, it was like Alder Ridge, but I've also found that recently the people that have been calling us the most have been basically, um, DevOps engineering managers or some type of, uh, title in that segment because they are the ones, or their teams are the ones that are feeling the pain when engineers can't set up a development environment or need to set up another one or have issues. So they're the ones that actually feel the pain and they're like, can you alleviate, basically the question is, can you alleviate this pain for me, please, if you can.

Thank you very much. Right? And so that's what we've found has been the most, because in a sense of developer experience is great and people are, you know, there's, we're talking to a lot of people that want to do that, but the, that seems more, unfortunately at this point, more of like a vitamin versus a painkiller.

So the people that actually have a pain right now seem to be the, you know, DevOps engineering leads Mm-Hmm. Might we one day apply some form of AI to all this stuff? Can we make it even simpler?

What's your sense of what's happening in the world? We see generative AI everywhere, so can it solve this issue as well? So it's definitely gonna touch it in the sense of, so there's a lot of, there's a handful of products right now, which are like AI agents.

Um, they're still not, you know, at the level you'd want them to be. But if you think about ai, they're like another team member. So they'll, you know, look at a request, um, they'll check out from, uh, they'll check out the project from the repository, they'll run the project and they'll contribute the code backwards.

And so ideally when you have an agent or like an ai uh, engineer on your team, ideally you'll want them to have the same, develop an environment as you or vice versa. 'cause you wanna be able to spin up what they've done right. To work.

Exactly. That's sort of like on, on the, on the one side. The other side is for sure, um, getting companies to implement a infrastructure as code standard for development environments.

And the standards right now are dev container, um, from Microsoft, which is open source dev file. Some people use Nix, um, nix the operating system, um, um, as well, they can use their, um, integration, their text file integration, but it seems to be another job that engineers have to do and they don't want to do it. So we're also tinkering with the idea and trying to see, can we create an AI product that can basically look at your repository and read me files and documentation, say, generate the, you know, the, um, the setup, the configuration files for you automatically.

And so that's what we see in the very, very short term. So we're talking six, 12 months. That's sort of where we're right now.

That's because operationalizing AI is a bigger challenge than people appreciate. It seems like. Absolutely.

All right. Um, as you think through where we are, you've been doing this for a while, what do you see people doing today in terms of managing developers and their DevOps workflows? It just makes you shake your head a little bit and say, folks, we need to be better than that.

So the funny thing is, and I've talked to people, um, at other dev tool companies that have been around for a long, long time. And so when you talk to developers or engineers, um, in the popular spaces, so you know, Twitter or you know, wherever you Reddit or conferences that you and I all go to, um, people will talk about cutting edge things and things have to be faster and better and whatnot. And that part is going own direction.

I think that's great, you know, better, worse, whatever. Um, but when you get to the large, large companies, like the, the place where they are is like decades for the most part. Like a lot of these companies still don't use Docker at all yet alone, you know, anything else.

So it's like, how can we, to your point is like, we can do this better. It's like basically we can make your company more productive, your people happier, and everyone will just be, you know, better off if we start implementing some of these things right now. And so that's what I see when I've been, you know, when I've been talking to these large entities, so large companies and the ones that we talk to mostly are not essentially tech companies, but they have large tech teams.

So I think, you know, aviation, finance, whatever. So they, they'd have like a thousand engineers or 2000 engineers, but it's not a tech company per se. And so that is where we've come often and you try to be nice about, and it's like you, we can do or you can do, at least it doesn't have to be with us much, much better than you're right now, Folks.

I heard it here. The truth of the matter is if salary and benefits are all relatively equal and you want the best developers, it's gonna come down to what is the developer experience. And if it's not a lot of fun, they're gonna go work somewhere else.

So think it through guys. 'cause ultimately it comes down to how much fun is the developer really having and that's where they live. Hey, thanks for being on the show.

Thanks for having me. And back to you guys in the studio.