In this RedMonk conversation, Ivan Burazin, Co-Founder and CEO of Daytona, chats with Kate Holterhoff, senior analyst at RedMonk, about the challenges developers face in managing their environments and how Daytona aims to solve these issues. They discuss the importance of developer experience, security in development environments, and the role of AI in transforming the developer landscape. Ivan shares insights into Daytona’s roadmap, including their open-source and enterprise offerings, and emphasizes the need for a seamless developer experience.

This was a RedMonk video, sponsored by Daytona.

Transcript

Kate Holterhoff
Hello and welcome to this RedMonk Conversation. My name is Kate Holterhoff, senior analyst at RedMonk and with me today is Ivan Burazin, co founder and CEO at Daytona. Ivan, thank you so much for joining me on this conversation.

Ivan Burazin
Thanks for having me, Kate.

Kate
All right, so let’s begin with some background here. Can you tell us a little bit about yourself? What is your history in terms of education, career? Yeah. Just anything you’d care to share?

Ivan
Sure. I mean mostly been solving or catering to developers most of my career. So at very early beginning probably a quasi developer. So did websites and whatever. But after that created a company called Code Anywhere way back in the day, which is one of the first browser based IDEs, which led to the company which we are today, but in the meantime also created this developer conference. So a conference focused exclusively on developers, did that for almost a decade, sold that and led the developer experience initiative at this fairly large private company. And so today again trying to make developers lives better, hopefully happier with Daytona, which is a, what we call dev environment manager.

Kate
All right, and yeah, let’s shift directly into that here. So talk to me about Daytona. What is Daytona?

Ivan
So Daytona, the reason we built Daytona and sort of how it started is when way back in the day when we were creating this browser based IDE interface, unlike Google Docs or whatever, you actually have to have a runtime to be able to execute the code and run the code. And so when we were doing this in 2009, 10, 12 and like way, way, way back, there was very few things off the shelf that we could use. And so we had to build all of these things around the infrastructure to be able to execute code. And that was a good learning — like today in Daytona we use a lot of off the shelf things. Like we don’t want to rebuild, you don’t want to reinvent the wheel, right. But we did learn sort of how you should structure these things. And what happened was probably about two years ago we had a bunch of interest. And I think also it was really interesting was there was a RedMonk article actually that said next year is the year of cdes or cloud development environments, another word for what we are. And that’s when we were actually contemplating to come “back into the space.”

There was, like you all wrote an article about that. We got people from other analyst houses interested because their customers were interested. And so what they were interested in was not the SaaS browser based editor, but a on prem enterprise solution to automate these dev environments. Because they have become so complex in these large organizations. It was very, very hard or it is very hard still for people to onboard, but not just onboard, but to collaborate on other parts of the company. Like once you’ve got it set up and running, that’s fine, but if you want to help someone else, it’s very, very hard. And so it just became this big pull to sort of suck us into this space which had not been solved. And so we were very wary about that. And we did a bunch of research and found out that it is an actual issue. And so what is the issue and what are the problems? I should probably get into that — is we divide it into three segments which is developer productivity, security and scalability. And developer productivity is what a lot of people associate this with, is that, you know, one button you spin up your dev environment, it works.

You don’t have to read through the readme, you don’t have to like debug. No works in my machine problem. Great. Scalability is what we refer to when the machine that you work on or that you got from the company is constrained by the resources that it has. So very often in companies like you can have a brand new M4 Mac. Awesome. And you still might not be able to run the entire dev environment that you want. And so how do you solve that? Well, you usually have to get a EC2 instance or something from your DevOps team. You have to connect to that. It’s complicated, expensive, and you have to also work bother the DevOps team. And so that’s scalability. And the third one is security, just the CISO vertical. Especially in very security stringent companies, they must as a mandate have all the source code behind their firewall on prem whatever. And the only way to do that is via VDIs, which is a very, very terrible experience and more costly than something like a Daytona. So we offer like a good experience. So like one that you would like to use versus I don’t know if people have used VDIs.

I’ve used them in my career. Like I would not want to work eight hours a day in that. And so can we get a great experience developers while also making sure that everything is secure and then hopefully it’s more cost effective than the VDI itself.

Kate
Right. Yeah. The problems that developer environments seem to solve really take me back to when I was a practitioner and I remember at one point I had this very old operating system running on my computer because it would break our developer environment if I tried to update. And so it was such a problem, I know for many developers that are actually working in this space to try to make sure that they have this consistency for all the engineers working in there. And I feel like the sort of problems that you’re identifying here with these VDIs, et cetera are — it’s just so universal and I’m surprised it hasn’t been solved yet. So it’s great that Daytona is sort of moving us in this direction, but it does bring me to this question that I have about why Daytona came about, which is why do we need to manage developer environments? You use the acronym DEM, Development Environment Management, and Daytona is a platform for those. So how did this need come about? Why is it that management is something that’s going to solve the pain that I personally experienced as a practitioner and I know folks are still grappling with.

Ivan
Yeah, it’s part of it. It’s interesting that no one solved it yet. I think that it was not enough of a pain back then because to your comment, it’s probably like you just don’t update and it works. That’s the solution. But also, if we think about the history of what an IDE is like an integrated development environment, for the most part, when you used Eclipse or whatever it was, NetBeans, Visual Studio, the original one, they were IDEs in the sense they had everything integrated in that piece of software. They’re like very large pieces of software where you would remember this also when I was like much younger, we’d open up Visual Studio and you create a new project in it. You type code and you hit run. If the code was correct, it would run right like that was it. There was nothing else to do. Like fast forward. Today I was talking to one of our customers or onboarding them as a customer right now. The dev environment that they have — this is their words. It takes them two to three weeks to get one person onboarded. Like that’s how long it takes because they have to spin up some services locally, they have to spin some of them remotely.

Then they have to spin up their own, some proxy, I forgot which one it was. And the developer has to do all the networking to make sure that all connects and all works and the back to the IDEs. Today most of us use text editors essentially, not IDEs. And the reason is because you actually can’t fit all of these things inside that one piece of software. There’s all sort of like microservices or even more specific. What we have quite often is multiple monorepos in one system. And so the idea itself cannot solve it. So we’ve fallen back to really good text editors, which is usually Vs code. And the developer now has to go and figure all this stuff out, right? So we’ve gone from a place where the software would solve a lot of it, where now the software has become so complex that it does not solve it, and now we need a new solution to solve that again, which. It sounds sort of cyclical and all that, but I feel what Daytona is trying to solve is sort of bring us back to that place where it’s like, open this thing or point to a git repository in our case and just actually start coding.

Like, not worry about anything else. Everything else is ready to go. You just have to worry that the code that you write is actually good and does what you want to do. And so that’s how I feel. And looking back, how the illusion and why there wasn’t that much investment to solve it before, because there were sort of like the way we coded before was good enough or it was not a big enough pain point to actually validate a solution like Daytona.

Kate
Right. And it seems like the agnosticism of the systems that you support then would have to be extremely broad. I mean, every cloud, every IDE. I mean, how is Daytona able to manage just the breadth of development environments that modern engineering departments leverage?

Ivan
Sweat, I guess that would be the answer. It is one of those… I forgot what the word was watching an interview of the founder of Plaid. Plaid, the Fintech, the very successful one that was supposed to be acquired by Visa. And so basically what they did is just like they connected all the — they have one interface that connected all the APIs of all the banks in the United States of America. Right. And so it is more, I think the word was like a grind project versus a technological product. Not saying that Daytona is not complex, it very much is. But one of the biggest problems creating Daytona is like being able to work with all these providers of infrastructure, so cloud providers on prem, whatever it may be, on one hand, all the IDEs on the other, all the git repositories, and making sure that no matter what variations or combinations you use as a user, that the interface and experience is the same. I think that is the biggest job of Daytona, per se. So when your question is like, how do we do that? Very, very hard, I think. And also when you look at dev environments, the ones that we support and the ones that we’re going to support, right now it’s mostly monorepo projects.

Now looking at poly Repo projects and spinning them up, there’s different ways to spin this up. And we’re trying to right now define a “standard” for the user interface. No matter what you’re using underneath to spin these up, that it feels quite the same. And so I have to say that the architecture of that is probably the hardest part of the job.

Kate
Wow. Okay, so it sounds like I was able to intuit that just from the fact that my brain was exploding thinking about the sort of multiple possibilities, or infinite possibilities rather. Yeah, let’s pivot a little bit and talk about something that you mentioned, which is Developer Experience. So at RedMonk, of course we’re always thinking about developers and how they interact with the tools that are part of their workflows. So I was really interested to find a blog post on Daytona’s website by Nikola Balić called the Developer Experience Revolution, which certainly piqued my interest. Nikola’s the head of growth at Daytona, and in this article he’s arguing for the importance of “modern DX focused tools.” So I’m interested in the role that Developer Experience plays in Daytona’s roadmap and your go to market strategy. How has Daytona made prioritizing Developer Experience central to its value proposition?

Ivan
Sure, I mean, there’s so many things. I mean, prior to Daytona, I was, the title was Chief Developer Experience Officer, I think I was one of the two or three people that had that title. Interesting title for sure. But what we had to do with that job or what was the mandate or what we had oversight under was everything from sign up from the PLG motion to the documentation to what the API looked like. There were so many things to, you know, community building events, whatever it may be. So all of that sort of falls under, I feel, Developer Experience. So on a very, very high level, it is like every interaction developer has with your company and or product can be measured under that. And then specifically what do you do to make your developer experience as good as it can be? I mean there’s very, there’s specific things that I can always say and I’m actually — the one thing I start off with mostly, and Daytona’s not perfect yet in that sense, but I definitely feel that documentation is something that most companies don’t work with a lot. And I feel that especially if you’re a dev tool, if you’re an API, whatever, like your product is the docs, almost like that is — like if you think about when a developer interfaces with your product, it’s probably more with the docs than the actual product.

And so that’s why I feel like docs should definitely be assumed. You could think about it as product and invest as much time as you can to make them as good as they can be. And I’m saying with a caveat, is that we’re trying really hard and I still don’t think we’re there in the sense of like the docs, but we’re trying very hard with that. Everything else falls in the product itself, we call them basically paper cuts. And so like as a developer, so first, time to first value is like, if you set that from the idea to, oh, this is a new product, I want to try it out to actually getting value… like, how long is that time? Is it an hour? Is it a half hour? Is it two days? Is it five minutes? Is it 35 seconds? How fast can you get to that value is probably one of the best indicators that people are going to try it, see the value at least, and then see if that value is actually valuable to them and then move on from there. So I’d say that documentation and after that would be what we call paper cuts.

And paper cuts are… some people say it’s like design, but I don’t think it’s design. It’s more than that. It is the interactions which you have with a product that lead you astray or blocker. So you try, you’re going through this path and then it sort of stops. Or doesn’t do what you would expect it to do. And this could be in a CLI tool, it could be in a dashboard, it could be in anything. But basically, how do you sort of like sand off those sort of like edges to the software to make it an enjoyable experience as much as you can. And I say this because when you look at companies like, so Vercel, I’m just going to pick on Vercel right now. And you have these Internet memes. I have nothing against Vercel. Just like Internet memes, I think, DHH put it up where it’s like, oh, this is just like AWS hidden behind this. And they’re just charging a premium for that. And it might be true, but what premium are they charging on? They’re charging on that great experience. Just the experience of using anyone that’s used Amazon or AWS.

It’s just like that’s the worst thing in the world? And a lot of people are super happy to pay the extra just to have it better, easier, faster, get to what they want. So that’s sort of my take on that. I’d love to hear also yours if you have anything to add on that. But that was an example that’s very showing or telling of what you can achieve with great developer experience.

Kate
Yeah, well, I mean, I think you’ve hit the nail on the head. In terms of Vercel and sort of these abstractions that we can, you know, that are using developers unwillingness to deal with all the sort of fiddly bits that go on with a lot of infrastructure. Yeah, absolutely. There’s a real market for that. But I also think that it points to the fact that, you know, developers are extremely important to making a lot of these purchasing decisions and that ranges not only with the sort of backend IT folks who have historically made a lot of these purchasing decisions, but also developers who are working towards the top of the stack. So in my own research I focus a lot on JavaScript developers and they tend to be the ones that are targeted by Vercel. I mean they call themselves a front end cloud. So this is a sort of new era of targeting front end developers in particular and noticing that they are the ones who increasingly making these decisions. But I think you point to this idea of abstractions which is extremely important to how a lot of products are finding their niche in the developer tooling space right now.

And so, yeah, making a product that is going to appeal to developers by making their own lives easier and yes, sawing off sharp edges and making sure that they’re actually enjoying the tools that they’re using. Absolutely. That’s a surefire way of making sure that they’re actually going to use the products available to them, not let them just become shelfware, but also make the difficult parts not so terrible. You have mentioned security a couple times. Absolutely. A lot of times developers don’t want to think about the problems of security because that’s not what they want to be doing. They want to be writing business logic. They want to be doing the fun parts, building features. They don’t want to be dealing with — everyone jokes about YAML, right? I knew some front end developers who were in YAML hell, that’s not what they want to be writing. So I think if Daytona is able to make sure that these developers are able to work on the parts of their job that they actually enjoy. Absolutely. That’s what makes developer experience so key to making sure that products are actually meeting developers where they are, but also, yeah, that they’re improving this entire domain of developer tools so that everybody is satisfied. Everybody is getting what they want, be it the CISOs, folks who are interested in security, or just the developers who want to not hate their lives, who want to not become burned out by doing labor that they don’t find appealing. That isn’t the sort of joy giving part of their career choice.

Ivan
Absolutely. So, yeah, glad we agree on that one.

Kate
Yeah. And so I did kind of bring up this idea of security here, and I actually would be interested in maybe pivoting this to talk about some of the ways that Daytona is looking at security, because you speak a lot about the hybrid approach, so that Daytona is leveraging both local and cloud development. And so I’m interested in why that would be more secure than just working on local or on prem. How is the cloud actually helping companies to maintain their security posture that they need?

Ivan
Sure. I think it goes back to… so a lot of people in enterprises will probably know Microsoft Outlook, for example, everyone uses Microsoft Outlook. And so if you think about Microsoft Outlook, you have this desktop, there’s a web application, but the vast majority of people still use the desktop one because it’s just a better feeling. And so everything feels like it’s local. You’re working on your machine, there’s like an offline mode, whatever. But if you’re in a large enterprise and for some reason your laptop gets, you know, stolen, you are let go or you leave or whatever it may be, whatever reason, the security team can revoke all access to that email and it’s gone from the machine instantaneously. Right? It is absolutely gone. For software development that does not exist. Like, there’s no way to do that. All the, like, most developers are working on their local machine. And even if they’re working on a local machine, some of that can be tamed or looked at. But if they’re working inside of a Docker container, for the vast majority of companies, that is a black box. Like, not only can they not revoke it, they don’t even know what is going on.

And so people might think, oh, you know, Big Brother, whatever. But the companies that I talk to, it’s not about oppression in the sense of like, oh, are you working your eight hours a day? Or whatever it is? Like, are the things that are running, are they allowed to be run? Can we flag if something’s running that’s not supposed to be an insecure, you know, whatever dependency library are you connecting to APIs or whatever that are, you’re not allowed to. Is traffic going through the network that it’s supposed to do? There’s all these things that you can now manage through a, or see or have observability through a system like Daytona. And so Daytona gives developers that same Microsoft Outlook analogy, although not all of them have used it. Whereas you can use your desktop VS code. It feels local. You know, it is. There is a local option as well, but in general, most of them keep all the source code or dev environments in the cloud, in the cloud being on prem like an actual IBM HP server inside a data center or AWS, if people choose that as well. And so you as a developer feel that it’s there, it’s local, everything’s proxy, it’s local host.

But the, you know, SecOps people in the company can, you know, revoke access, remove this. It is not on your laptop. Actually, there is observability tools that are there and more are being added, reporting tools. All these things that you might need post the fact of any sort of security issue and that in today’s world is not feasible at all. And so when we talk about security, that’s sort of what we talk about inside Daytona.

Kate
That makes sense. All right, and so I gotta ask, let’s talk about how AI is transforming the developer environment space. How is Daytona looking at our new AI era?

Ivan
Sure. I mean, AI. I think I wrote an article about — the title, I took it from someone else, so it’s not a great title. AI Agnostic Infrastructure Middleware. So like a very, very long word. The idea behind it is that AI coding is here both as an augmentation of humans and fully autonomous. But there is a lot of limitations. So you’ll see a lot of demos and most of those demos are like fairly, fairly simple apps. Like if you try to do something more complicated, for the most part it doesn’t work. I’m talking about the autonomous ones where the augmentation is pretty good. It can be better, but pretty good. And so looking at how things work right now, the way it works, and I take Cursor as an example, and they’re doing really well. They wrote this whole article about how they actually have an invisible electron pane that you can’t see while you’re typing in Cursor and the AI using the code base and the file you’re on, trying to figure out, you know, what is the best outcome and what it deems the best. Basically, that is what you see as a suggestion to what you’re doing.

And so there’s, there are limitations to that. It’s not perfect, it’s very far from it. And the reason it is far from it is that coding is not just files, it is like runtimes and outputs and debuggers and linters and all these things that a human has. And the AI actually doesn’t have access to that, really. I’m not going to get into anthropics like whole use my computer as a human part, but as an AI agent, coding agent, right now they don’t have access. And so what we talk about now with Daytona and dev environments management, remote dev environments generally is, is this or the way we see the future going is imagine an AI agent can actually spin up a replica of what you’re working on and actually test and see outputs of what it is trying. You would then get the suggestion or the output or the PR what you had gotten would be tested because the AI could spin up a identical dev environment, see the output, if the output is desired, it will send you back, oh, here it is. Because it already knows the output is right. And that is only if you think of like one to one.

So if an AI agent is equal to human and they’re just working on one, but an AI agent could in theory spin up to 10, 15, 30, 100, 1000. These dev environments, of course, if you have budget like all of them cost something, right? And so you can think about, let’s say you’ve raised a new round or whatever, you are a large company and you have to get to a outcome very fast. You’re like, okay, I can spin up the dial and have much more vertically spun up these environments to get to the desired outcome as fast as I possibly can, right? And so in a world where a lot more will be done, coding done by AI, I feel that the only way to do this, and we’ve talked to a bunch of AI co generation companies, they all have this bottleneck or the ceiling right now and they’re all trying to figure this out. And so there is no standard yet around this. And so we’re trying to work with as much as we can to define a standard around the API endpoints. An agent would need to be able to always get the information at once and spin up and spin down these environments.

Kate
Yeah, that’s huge. So not only are we thinking about this in terms of the developers who are using AI code assistance, but also in terms of our agentic future, which is going to be throughout the entire stack that there’s suddenly going to be AI. I mean I’ve heard folks talk about AI native now is I think the buzz word. So. That’s the word. So, yes, our AI native future that this is also going to be part of it. And I like this idea of working on standards collaboratively because it seems like that is sort of the inflection point when we know that a technology is mature enough that there is sort of buy in from enough organizations and enough enterprise customers that are willing to invest in this and try to figure out what is going to work across the board.

Ivan
Yeah, I mean you have to try it out. Like it’s also all thesis, like you’re not sure what you’re doing. So we’ve actually just recently launched a version of OpenHands, previously called OpenDevin, that runs on Daytona. So it’s like a SaaS product, but it’s OpenHands, it’s running on it. We’re also doing one with continue.dev which is a copilot, similar to GitHub Copilot, and it runs on Daytona infrastructure. And so it sort of, we did it to first see if it was feasible. And then the other is it’s a conversation starter with all the companies where it’s like, hey, we’ve already built this thing. Like you might as well use it because it’ll make your life probably easier. Anyway. That’s how we think about it. And we’re very much into experiments at Daytona and those are some of the experiments we’re doing. And we have some more coming up. And I think it’s really exciting when you see something that you’ve created, you can just add on things on top. In this example, in OpenHands, a continue or someone else and it just works magically out of the box. So we’re very excited about that in the future.

Kate
I can see why. All right, so talk to me about the roadmap at Daytona. What else should folks who are interested in the space be thinking about?

Ivan
So the roadmap for Daytona, we have a open source product and we have an enterprise product. We’ve actually split them up into two different ones. Unlike a lot of companies, I think we didn’t open source the entire, let’s call it enterprise product. There was a couple reasons for that. One is the licensing becomes very complicated if you’re trying to give something open source that you also try to sell or put on the market because you’re trying to figure out, oh, can I make it open, but sort of restrict something, do I give this out, do I not? And so I think there’s… and we’ve seen a lot of issues with that recently. You know, companies having clawing back licenses, whatnot and so we really didn’t want to do that. And it’s also when you think about, like the value, what you’re trying to do is the thing that you open source, you’re trying to give value to one set of people. The thing that you charge for, you’re trying to give value to another set of people, right? In our case, you want to open source the value of the developer. And that developer also doesn’t want this like, clunky, huge thing that they have to install.

They want just like this quick one button, spin it up, it works. And so what we did, we created the core, let’s call it Core of Daytona, which is the developer experience. Like one button, it spins up a dev environment. You point where you want to run it, it does all that. And that is like Apache 2.0, actual open source. Anyone can, you know, fork it, use it, do whatever they want with it. And then we have the enterprise, which is actually the open source is upstreamed into the enterprise, and the enterprise is everything the enterprise actually wants to pay for. And so who are you giving value to then? Well, we’re giving value to the DevOps manager, CTO, CISO, whatnot. And so what are they interested in? They’re interested in team management, compliance, logging, audit logs, sso, like all these different things. And none of that is in the open source because the individual developer actually doesn’t care. So we basically have these two products, one that upstreams into the other. And for the open source, just like getting back to the question, which is roadmap, Daytona open source is, you know, it’s been out there since March.

We have like 10,000 people, stars on GitHub, a bunch of people using it, and a lot of the functionalities are actually done, one of the most important things that’s coming up is basically it was a CLI tool only. And so GUI Dashboard, we didn’t want to do it at all, but it just seems that people like it a lot. And I guess that’s why Docker did it and everyone else did it. So there is a graphic user interface coming very soon just to expand the amount of people it can actually attract. And the second thing that it’s adding, and this will go upstream to the Enterprise as well, as we talked about before, is creating — right now it’s like monorepo dev environments, where in the future you’ll be able to have multiple monorepos. Like you can do microservices right now, but actually very complex multiple monorepo environments that will spin up multiple physical VMs or containers and also be able to connect to external services on AWS or whatever it may be. And so that is something that will be launched both in the open source and the enterprise.

And probably the biggest thing outside of the AI native things that we’re adding in there, that would be probably the biggest thing that is coming. From the enterprise side, it’s just a bunch of “boring things” where it’s not exciting. It’s like, what new things does compliance want out of the product? And that is what we’re building. And so that is mostly the open source, the enterprise side that is coming up.

Kate
Yeah. So just, just a few things. Just a small — I get it.

Ivan
Small bunch of things. Yeah.

Kate
All right. Well, it has been an absolute pleasure speaking with you today, Ivan. Let’s just kind of round up by talking about how folks can keep up with what you’re doing at Daytona. So what are your preferred social channels and how can folks, yeah, what’s the best way to maybe get in touch with you if folks want to follow up?

Ivan
Sure. Daytona.io, the website is probably where we have everything and all the information is there. Obviously there’s a community Slack, GitHub is there, Twitter and LinkedIn. So all of them are there. Also, if they want me, first [email protected], feel free to shoot me an email. Also, I’m in the Slack, so you can DM me directly in Daytona Slack if you join, so yeah.

Kate
All right, easy as that. Well, I’ve really enjoyed speaking with you today. Again, my name is Kate Holterhoff, senior analyst at RedMonk. If you enjoyed this conversation, please, like subscribe and review the MonkCast on your podcast platform of choice. If you are watching us on RedMonk’s YouTube channel, please like subscribe and engage with us in the comments.