Ivan: Onboarding time to get a new engineer on board it takes like two weeks or three weeks for a week, whatever it may be.
Ivan: Just like setting up a new project. usually takes a bunch of time and developers waste about 56 percent of their productive time just on development environment issues. So like, can we get all that out of the way?
[00:00:20] Introduction
Andrew: Hello, welcome to DevTools FM. This is a podcast about developer tools and the people who make them. I'm Andrew and this is my co host, Justin.
Justin: Hey everyone, uh, I would like to introduce our guest today, uh, Ivan Boraisen. Did I say that right?
Ivan: You said that pretty good. Thank you. That was
Ivan: awesome.
Justin: Okay, cool. Uh, so Ivan, we've had the chance to meet at a lot of the social events that you put on. You put on a Daytona DevTools, uh, like social hour, um, and you've done it in New York, NSF, and London, and like, I would love to talk more about like how you managed to run a company and travel so much, but, uh, you are, uh, one of the co founders of Daytona.
Justin: Um, and we're really excited to talk about that, but before we dive in, uh, would you like to tell our listeners a little bit more about yourself?
[00:01:08] Ivan's Background and Career Journey
Ivan: Sure. Um, thanks for having me. I'm super excited about this one. I've like listened to the podcast quite a bit. Also am a proud owner of a bunch of swag that more than one person has stopped me and asked me where, uh, have I gotten it? So, um, that was pretty awesome. Um, so myself, co founder of Daytona before Daytona, I co founded or I found it, sorry, this, Developer conference company called shift, which was acquired.
Ivan: Um, and I worked at the company that acquired it for two and a half years. Before that, I co founded a similar company called code anywhere. And before that I did just a bunch of other things that might not be related to what we're doing. Uh, but post sort of code anywhere, shift and, uh, Daytona has all been basically for developers specifically.
[00:01:51] Balancing Travel and Work
Andrew: So before we get into, uh, the stuff you code on, uh, let's go back to what Justin said, you travel more than I think any person I know, like you are con you, you actually live somewhere in Europe, but I don't know if you're ever actually there. So like, why do you travel so much? And like, as Justin said, how do you manage doing that while like running a company?
Ivan: Sure. Um, yeah, I travel quite a bit. Uh, wife gets angry on that. Um, that I'm not that much home. So wife and child, um, are in Croatia. I am born Canadian, raised in Canada, but Croatian heritage. So moved to Croatia at some point. While I was at school, finished school there, um, got my first job. I did then, uh, live abroad, went to Boston, lived there for a while, lived to other places in SF back and forth for a while, but ended up getting married and sort of having a family in Croatia.
Ivan: Um, it's a really good setup that we have, especially with a child, but there's not much things to do outside of. Um, people come to Croatia for Yacht Week. We live on the Mediterranean coast here. It's a wonderful place for holiday, but not the best place to get work done. And because of that, it is sort of my job to, you know, make this the best company I can.
Ivan: And a lot of it has to do with interacting with people. And you're going to interact with people, probably not. In Croatia, except on the summertime. So then I mostly am in New York. So I'm there at least a week, a month. I'm there. So quite often, but I'm also in San Francisco and London and whatever, because when you're, when you are on a plane already, it is super easy for me to hop into another place for, you know, an event, a conference or whatever it may be.
Ivan: And so I sort of made a. Thing of it, uh, inspired by our common friend Swicks and Angel Investor in Daytona, who usually when he lands in a place does this sort of like Like ad hoc meetup where just like buys everyone drinks. And I'm like, Oh, like, I'm going to steal this from you. This is super cool. And that's how like the dev tools meetups began.
Ivan: And now they're fairly big. I mean, the one in San Francisco last time was I think 75 people, something like that for an ad hoc meetup, just to like founders and investors in the dev tool space was pretty good. The one in New York last time, I think it was like 30, 40 people. Justin was there. Um, so it's really, you know, picking up.
Ivan: Yeah. Um, the interesting part is we even have sponsors for them now, which is insane. Um, as something I just do as a hobby. And I think it comes back from the conference days as well. So that is something I do. I try to get the most out of traveling. So if I'm not at home, I'm either meeting with someone at an event, creating your event or, or, or something that's connected to Daytona specifically.
Justin: Do you have any, given that you travel so much, do you have any like hard fall travel tips, like do this one thing if you're going to travel a
Justin: lot?
Ivan: So I have no jet lag ever, and I actually, I think, wrote a post about this quite a while ago, and again, not DevTools, but, um, like, one thing I read a long, long time ago, and it actually works for me, I sort of brainwashed myself, I think, for it to work, is that I change all my clocks on wheels up. So when your plane takes wheels up, set all your clocks, your laptop, your phone, everything to the destination time and act like it's that.
Ivan: So let's say if I'm flying from Europe to the U. S., I will not sleep at the plane at all. I'll just work because just your day is just longer. Uh, but if I'm flying the other way around, it's night. So it's like 2 AM as soon as it's wheels up and then you try to go to sleep right away. And then when you land, you go to sleep at the time you're supposed to sleep in that place.
Ivan: And obviously if you can't get any cardio in the morning. Get a lot of caffeine in the morning, melatonin in the evening and do all these things are just to hack your, your, uh, circadian rhythm. And I do that. So I'll hop across an ocean and just be, um, ready to go. I think the last meetup I did, um, in New York, like I literally landed from Europe, um, to New York that day, did the event and just went to sleep afterwards.
Ivan: So, um, yeah, I guess that's something you have to teach yourself to do.
Andrew: Cool.
[00:05:41] The Evolution from CodeAnywhere to Daytona
Andrew: So, uh, let's switch up gears a little bit and get into what you make as a company. Uh, let's talk about Daytona and then after that, I want to roll it back because you've been in this space for way longer than I realized before researching
Ivan: Yeah. I'm a super old person in this space, like very long. So Daytona essentially is a open source. Development environment manager. Sometimes some people call it CDE. Uh, we say it's not, the CDE means cloud development environment. Daytona is not necessarily, doesn't necessarily manage just the cloud development environment, it manages all your dev environments together.
Ivan: And so basically what it does, it automates everything so that you have this seamless experience, no matter where the dev environment is running, if it's local, local host or an Amazon or wherever it may be. Um, and you as a developer, you're You know, just get into coding. You don't have to think about anything.
Ivan: You'd have to go through a readme file. You don't care about these things. Um, it's all automated for you. And so that is what Daytona is. And yeah, the, the, the journey, as you mentioned, it started in 2009. I didn't know. I don't know how many people actually realized that
Ivan: specifically.
Andrew: Yeah. I was very surprised that 2009 it started as PHP anywhere, I think.
Andrew: Right.
Ivan: Yeah, Yeah, PHP Anywhere. Yeah. So we founded the very first, I think, I think, uh, browser based IDE in 2009. And I don't know how many of the listeners here, there are people that are older, I'm aware, but there are probably people that weren't doing this thing back in 2009. Um, so, um, A lot of time has passed since, since we've done this with one of the first or the first that started it.
Ivan: And when we started, it was basically just like a notepad type editor and FTP connector as time progressed, sort of, and as web 2. 0, for those don't remember actually happened. We could actually do like syntax highlighting and all these things in the browser. And because this was such a long time ago, we had to build everything.
Ivan: So we built our own IDE, like multiple versions of it, our own orchestration platform. I mean, we even create our own authentication. Like we did. Everything, um, by ourselves. Um, and CodeAnywhere had some success. I think two and a half million people have signed up on the platform throughout the years. And it's still interesting that when I meet people today, they're like, Oh, I've used CodeAnywhere.
Ivan: I'm like, wow, I didn't know it was like popular. It was never going to be a super successful company for two reasons. One, it was very, very early. In sort of the technological, technological life cycle, but also at the time we had no idea what the difference between a user and a buyer was. And we were trying to sell to a user being the individual developer versus a buyer, which we now know is like an CTO type office engineering manager type person or CISO, not the individual person self.
Ivan: And so that is, those are two things that we sort of didn't know when we started. And that's why it was sort of never was that successful, but it did teach us a. bunch of things, especially and specifically about the infrastructure layer that we had to build to offer a browser based IDE. And that's sort of where Daytona came from.
Ivan: That's sort of like the idea behind Daytona.
Justin: So is Daytona, like, would you describe it similar to, like, GitHub Codespaces or Gitpod, and then it's like the all inclusive, it's your environment, like what it's running on, and the editor, and like everything, like, put together, or is it like, More focused on getting, uh, just, you know, common dependencies and everything sort of packaged up together and letting you kind of interact with it however you want to, um, I've seen a lot of, like, attempts at creating, like, unified development environments in Docker, like Docker containers, uh, to varying degrees.
Justin: So, like, how far along the access do y'all
Justin: go?
Ivan: Sure. There's a lot of things that we actually do. And might take it back to why we actually created Daytona because it's also sort of like, Why the hell would you make a same company twice? It's not the same, but it's very similar. Especially when you got burned the first time. And so the reason why we were actually at some point code anywhere, had about a million dollars invested.
Ivan: We ended up buying back all the shares from investors and just sort of stayed online. It still exists, but it's basically just the founding team owns it. We went to do other things. I created the conference, sold that, and I was working at this other company, which was supposed to stay for a lot, lot longer.
Ivan: I was running the developer experience there, but ended up leaving because about two years ago, we started, the founding team started to get a bunch of inbound interest around code anywhere, or more specifically the infrastructure behind that. We got inbound from like potential customers, analysts, and even acquirers.
Ivan: And all of them were asking a similar question and it was, we don't want the browser ID. We don't care about that. Like nothing of that is needed, but our developers are wasting so much time. There's a couple, there's actually three issues, but there wasn't so much time setting this up, can we have something that will automate and make their lives easier, but there is a constraint.
Ivan: Like we have to be able to run this thing. Like self managed. And so as we were like talking to all these people, we found that all of them have a similar set of issues. And we even, we even went further and started, you know, interviewing other people, searching the internet for anyone that's mentioned cloud development environments or something similar, we found like just a bunch of people and reached out to all of them.
Ivan: We found that. Most tech companies are tech first companies. So your, your Slack, your Shopify or Spotify, your LinkedIn event, right? Like these companies have built something internally just to solve this, but you're non, what I call non tech first companies. So, you know, anyone in aerospace, insurance, banking, whatever, have not created these things.
Ivan: And then. We sort of distilled further. So why did they create them? And so they created them for three different, three main reasons. One is developer productivity or happiness, meaning, you know, onboarding time to get a new engineer on board. It takes like two weeks or three weeks for a week, whatever it may be.
Ivan: But not even that, just like setting up a new project. It usually takes a bunch of time and developers waste about 56 percent of their productive time just on development environment issues. So like, can we get all that out of the way? The other thing, the second thing is scalability or compute restrictions.
Ivan: So we might have like M3 Macs and they work awesome and whatnot, but even that is not enough if you want to. You know, spin up another dev environment that you want to help someone with out with, without shutting out you shutting down yours, or it just might be too big that it can't fit on that. Or even you, like a lot of people now want GPUs, like, how do you solve these, these, these issues?
Ivan: Well, basically you'll call up your DevOps team. They'll enable an EC2 instance. You'll have to connect to that. It's just like a pain. And the last reason is actually security. So a lot of very like stringent compliance focused companies, Offer their engineers a single way of work. And that is through a virtual desktop interface.
Ivan: And a lot of people do this. So using remote desktop or Citrix to log into a server and then have your ID there with all that lag is a very shitty experience. It is terrible, right? But these companies want to make sure that the source code stays within the bounds. Of the company. And so how do you solve that?
Ivan: The only way to do that is either through that or a system like Daytona, which enables you to have everything set up on that server, but have an ID on your own. So sort of to culminate how we started, we got about a bunch of inbound interest from all these companies needing these things. And we actually figured that out, that it was essentially the infrastructure layer of CodeAnywhere, or that was the basis of it.
Ivan: We ended up creating a new one. This is what these companies want, and they want to self manage it. And we went off to sort of build this new product, which ended up being Daytona. So to answer your question, it is about the security automation scalability of these dev environments and deliver it to an engineer using their favorite IDE.
Ivan: So there is a browser based IDE if they want, most often than not, they choose not to do that, but they use their, you know, JetBrains or Cursor or VSCode or whatever they want.
Andrew: Do those IDE integrations require any work on your part? Are you like creating plugins that plug into VS code to do something?
Ivan: Yeah, we, we have to create integrations for all of them. It can work with just, uh, all of these IDs have the ability to connect to remote dev environments. So they can do that by hand to connect to a Daytona instance. But the whole pitch is that it's like super seamless and easy to use. So developers can basically use a web UI or the CLI or the plugins that are in these IDs to create a new workspace and it just spins up for the magic.
Justin: That's awesome. Like what, what stage of company do you typically see that your customers are at? Is it like a larger established company that is like a non traditional tech company? So they haven't like yet got to the point where they've like built their own solution, but they have like a big enough team where it's like a really painful thing.
Justin: Do you see it at any like earlier companies? Like what is the, what is the sort of like life cycle?
Ivan: I very, very large companies. So I'd say like a thousand engineers plus is, is what we've been seeing where the biggest pain point is. Because we also know this as engineers, like if the three of us are working together on a startup, the pain points are not. That terrible because you know, we figured out through osmosis, you know, it sort of works.
Ivan: And then as you grow, it's sort of there, but when you have those paper cuts times a thousand, 2000, 5, 000 engineers, then it becomes very, very, very painful. And everything slows down to lift it to a halt. And so that's why we've seen that these are the companies that want this the most. Now, recently we've started getting inbound from like smaller companies, like 20 developers and whatnot, and we're happy to take them on board.
Ivan: We even have like special. Types of contracts for these, because from our perspective, it's more interesting to have them as a use case than it is as a customer. Nothing wrong with that, but I think we can help them even more because of their size. And they can help us in other ways that these traditional companies cannot, because the feedback loop from these large, large companies is very, very slow.
Ivan: I have to tell you, it's insanely slow. The sales cycle is insanely slow and the feedback is insane. So, so like what we do when we work with smaller companies, Companies, it is mostly, can we get that feedback loop faster so that we can iterate faster and solve problems faster?
[00:15:58] Ad
Andrew: We'd like to stop and thank our sponsor for this week, but we don't have one. So if you'd like to sponsor DevTools FM, head over to devtoolsfm slash sponsor to apply.
Andrew: And if you want to find another way to support the podcast, head over to shop. devtools. fm where you can buy some merch and rep the podcast. With that though, let's get back to the episode.
[00:16:17] Open Source Strategy and Business Model
Andrew: So one of like the main selling points, I think, of Daytona is like the ability to self host it. And like your whole thing is open source. So like, where, where does the contract come in? What am I paying you for other than to use the piece of technology?
Ivan: Absolutely. So the whole thing is not open source. So that's very specific. So we did a lot of research on open source, like every, I feel that every week there's a new open source drama every week, like there's a new one, maybe not every week, but there's a, there's a drama nonstop. And so when we were thinking about it, we started first as a, you know, on prem enterprise solution proprietary.
Ivan: That's how we started because we weren't sure how to create an open source. License and or product. That we won't either kill ourselves or, or, you know, kill our users or, or screw something up long term. And so we thought about it for a very, very long time. I think it was like nine, 10 months that we spent, you know, on the back burner trying to figure this out and talking to everyone that we could.
Ivan: And what we understood is that. We, if we want to enable a open source project, you should not open source the core value of that, or to be more specific, you shouldn't open source the core value to your customer. You should open source the core value to your user, if you can. And that is something that took us a while to figure out.
Ivan: And when we thought about it, like, who is our user? Okay, it's the developer. They don't care about scalability. They don't care about authorization. They don't care about, uh, audit logs. They don't care about, you know, SOC 2 compliance. They don't care about any of these things. They just care that there's like one command and it spins up automatically running.
Ivan: We're like, okay, that was like a, it took us a while to figure that out. And then we decided to sort of carve out that part of the enterprise, Daytona and create it as its standalone. Product and open source that. And then when we're thinking about it and the reason we wanted to do that, there's, it's actually twofold.
Ivan: If you open source the entire enterprise product one, it's useless to the individual developer. So the people that can actually might want to use it, contribute to it, it's useless for them. The only person it's useful for is someone in the enterprise. And that's the person you want to sell it to. So that's why we decided to make a distinction between what is proprietary code and what is open source code.
Ivan: And then we were thinking about, you know, open core. Like GitLab or whatever it may be. And our thought behind that is like, how many contributors will we actually get? If it's this huge repository with multiple folders that have multiple different like licenses, that's like, Oh, what can I do? What can I work on?
Ivan: What can I not? And so we decided to split up into two repositories, the, which is harder for us long term to manage it, but we feel it's easier for the user and or contributor because it's a really small repository. It's a really small project. You know, it's in one language, mostly. You can just like check it out, fork it, work on it, and it gets the job done.
Ivan: And so that is how we decided to, or how, what we decided to open source. And the last part was essentially like the license itself. It didn't go in that order, but when we were thinking about license, now that we've pulled out, what is the value for the user, but not the buyer, it didn't really matter what the license was.
Ivan: So we can make it as liberal as possible. And so basically we put it as Apache 2. 0. We decided that versus MIT just so basically, so the name Daytona stays in there. Like we made it so you can just, you have to reference it, but that's the only real restriction that's in there versus going into other more complex licenses.
Ivan: And as I've talked to a bunch of open source founders as well, I did not know, or was not aware of the degree of hate for all other licenses. Not that everyone hates all licenses, but there's like, there's tribes of people that hate other licenses. And like, If you're like MIT and Apache, you're all good.
Ivan: Like no one hates you. Right? So when we were thinking about that and sort of back to your original question is we open source, what is valuable for the user and hopefully the Daytona open source becomes a way of work for every single individual or developer in the world, that is the plan. And people can, you know, build on top of that fork yet.
Ivan: They can do whatever they want, contribute to it. That's great. But everything that the actual buyer wants is proprietary and that's not open source. So essentially. Yes, you're buying it to self manage, but you're also buying it because you actually can't get it without a license.
Justin: think that makes a lot of sense. This is a, this sort of like open source business model contention we see in a lot of places, like database companies, especially I think are having this like long moment of just trying to figure out like, is, you know, building a database company possible on like a standard open source license?
Justin: And, you know, in general, it's seeming like the answer is that to know, because I think one of the insights here is like, like what you were saying, it's like. Are you opening, sourcing it for the user? Are you opening and sourcing it for the like, company and, uh, or for the enterprise? And I think that, you know, if your product is hard to separate one from the other, then, you know, it becomes like a bit of a challenge.
Justin: And you have to think more critically about licensing.
Ivan: I was just going to say that I agree with that. We know a bunch of open source companies are doing great. So super base, um, the CEO is an angel in Daytona as well. Love them doing really great, but you have a lot of these to your point, database companies where it's open source and the only value that they're giving him is a SAS platform.
Ivan: On top of that, now, maybe some of them are building extra things in the SAS, which is essentially proprietary, which makes sense. But other than that, that is a very, very tricky business long term, right? Because anyone, you know what happened to Elastic, um, but anyone else can actually host it and do it themselves.
Ivan: Another specific one is where people will just put the whole thing on, uh, AGPL, which is like, Oh, like, So Amazon can't do this, sure, but your buyer can, and then they're not buying it from you, which is also an issue. So I feel that there's a lot of problems with that. And it seems to be getting worse because people are now, especially with the last issue about a month ago, where people are now trying to even move away from open source because founders nor investors seem to understand the nuances of it.
Ivan: No one is taking the time to read these licenses. And now it's either. The understanding is everything is free or we're not allowed to do anything. And which is neither of them is true. And then people are starting to push away, which I think will be very bad or detrimental for the industry in general, especially for DevTools.
Andrew: Yeah, I feel like AI has almost pushed this issue a little more, because, like, right now we have, like, Hugging Face, which is like, uh, AI GitHub, and it feels like when you're looking at it, like, oh, these are all things that I could use, they're open source, I know the weights, but then you get into the licenses and it's like, None of these could I build a company on?
Andrew: And it like, I can understand the, the knee jerk reaction of, Oh, anything, but those two licenses is like, it's kind of too hard or impossible to use.
Ivan: Yeah. It's very complex for the user. And I remember when we were talking to one of, like, we consulted with a bunch of lawyers as well to figure this out and they're like, Enterprises will not use it unless it's one of the few licenses that they understand, because it's just like complicated, they don't have time to use it.
Ivan: And then the question is, does, is it even valuable to be open source then? Like, what is the, what are you trying to achieve putting it out there? If it's going to be too complicated for people to use that, right? So. I mean, that's my thought as well. Like there is source available, which is not open source, but it's just the code is out there.
Ivan: And I think that's fine if there's a use case for that. So we might put our proprietary code source available, which is the reason is an enterprise can download it and run the thing by themselves to try it out essentially as a demo. But that's the only value I see in that. Anything else to your point, I feel it's like super complex and you might as well just not do it because it's too much effort for very little value to anyone else.
Justin: Yeah, if you're starting a business on open source, definitely important to think about this deeply. Um, cool.
[00:24:00] Comparing Daytona with Other Solutions
Justin: So let's, let's talk about Daytona a little bit more. Um, so, you know, I, I'd asked earlier is like, okay, how does this, uh, You know, compare with something like code spaces or code anywhere in its original form.
Justin: And so can you talk a little bit more about, like, just the trade offs of the like, Oh, you're, you know, one click you are l. You have a browser based I. D. That has all the stuff to it and like what you're trying to deliver with Daytona.
Ivan: Sure. I mean, I could talk about like code spaces, for example, and like differences and there's some very obvious one and there's some more nuanced ones. The obvious ones is You know, Codespaces is a SaaS product, meaning if you want to self manage it for any reason is it, it could be just cost. You just want to run an AWS versus, you know, Codespaces server, which is Azure underneath, but you want to run on GCP.
Ivan: Like you can't do that. The other thing is it only works with github. com and we have a bunch of customers that not only do not work with github. com, but they work with, you know, GitLab and GitLab on prem or Bitbucket and Bitbucket on prem. So you have to have like multiple of these Git providers, which they do not have.
Ivan: And this is just like. You know, just the beginning part, which a lot of companies cannot consume that, but more than that, if you want any sort of complex dev environment, so, you know, Codespaces supports dev container, which I think is great, Daytona does as well, but they only support like single, let's call them container, uh, dev environments, which is great, single repository, single container, which is great, but if you need different actual hardware, you can't get that.
Ivan: But more than that, if you need any complex, like poly repo configurations, like that is not there. Like they can't solve that. So there's a lot of things. And I can tell you, like half of the companies we talk to in any stage of our sales pipeline, like half of them are like, Oh, how do we set up, you know, multi repo repositories?
Ivan: And how do we get this up and running? And every company has a different way to do that. And is there a way to solve that? And so a service like Codespaces, then not. Solve that at all. So just when you look at that, like for the vast majority, it's not even a feasible thing. So with Daytona, essentially what we're trying to do is solve these very complex dev environments that these large enterprises actually have, and that all have created some weird ways of like hacking this together internally right now.
Ivan: And can we give them essentially that one click button for the developer, but still have that complexity underneath, and that's sort of where we're striving to and trying to achieve.
Andrew: So on the homepage, I see something called dev containers mentioned a lot. It's like even one of like the top line items, uh, on the homepage. So what are dev containers and how does Daytona use them?
Ivan: Sure. Dev containers, uh, dev containers or infrastructure as code for dev environment standard. So dev container, it was created by Microsoft. That's why we sort of initially went with them.
[00:26:44] The Power of Dev Containers
Ivan: Our bet was because it's Microsoft, you're gonna have a lot of public GitHub. Open source repositories using that and because it's part of Microsoft, it enables some things inside of VS code.
Ivan: So inside the editor to be called on as well. What that means is basically if someone has set up a dev container properly, you don't have to read a readme. You don't have to like look at what ports to open. You don't have to think about what libraries to install. You don't have to think about even what plugins to do on VS code.
Ivan: It will run through all these things and will build your dev environment to spec. And it will work instantly, right? And that is something that they have done, and we wanted to Enable that initially through CodeAnywhere. So CodeAnywhere, just taking a step back, sorry, CodeAnywhere, Daytona. Uh, Daytona will, so many words, Daytona will, when it, when it starts, it will create a virtual machine for you or container if it's local host, it will then check out the repository or read through the repository, it will look if there's a configuration file.
Ivan: So in this case, the dev container, but there's also multiple ones, which we'll get into in a second. If there is, it will execute against those. And if it doesn't, um, then there's like base container images that they don't, we'll use and try to figure out the best possible one. Then it will connect to your local ID.
Ivan: We'll exchange, you know, keys, make sure everything works. It will add a reverse proxy. So then I can actually give you a preview of what I'm running. Like it does all these things and everything's deterministic. The actual, um, configuration of the dev environment, if there's no dev container, right? So. That is why we've seen a lot of people, it has become the de facto standards.
Ivan: The other ones that exist are dev file. There is Nix, obviously, which Nix has been around for a long time. There's Phlox, which is a variation of Nix. And so there's a bunch of these standards. To create dev environments to work out of the box, but none of them has taken off in the sense that every single dev environment has that except for the fact that definitely never seems to have more than anyone else.
Ivan: And that's why it was a bet for us originally. Let's go and support DevContainer and we're now adding support for Nix and Flux and DevFile and all these others. And that's also sort of one of the reasons we were mentioning earlier is like the DevContainer's AI sort of project that we launched quite recently.
Ivan: So when we look at when Daytona creates a dev environment, the only thing again, that's not deterministic is if there is a file there. And so, Our thought was, how do we make it so that every repository in the world has a configuration file without everyone having to do it? The easiest way we thought of was, can we create sort of this AI project?
Ivan: It's an independent project. It's completely open source. Again, it's Apache 2. 0. It's not perfect. And the reason why is we hope that other people will, you know, 4k contributed embedded in their products, because if we can get to a place where every repo can be on the fly red. And then generated a configuration file, then every dev environment will work automatically, which inherently means that every new developer, no matter what his work, whatever they're working on will instantaneously be able to get up and running.
Ivan: And that's good, not just for enterprises, but I think open source in general, because you can then, you know, contribute to any project, whatever your, however small it may be, because it takes you like 30 seconds to get up and running without having to, you know, debug, set up this dev environment, read through the readme and all these things.
Ivan: And then it ends up not working like 30 minutes in, and you're like, Oh, You know what, screw this, I'm out, not going to do it. So that is sort of the, what is DevContainer and why we look at it. So hopefully.
Andrew: So DevContainer AI will just like look at a repo and generate what it thinks will be a working DevContainer for it, given like the readme and like a package. json and stuff like
Andrew: that?
Ivan: So figure out what it needs. So it's essentially trying to be you as a human that will go read everything and then write it out. And so it works like 80 percent of the time, it doesn't work completely. There's still lots to do.
Ivan: And that's why we haven't officially embedded it inside the Daytona product. We will, when it gets to a point where it is, but hopefully other people will do that and they'll bend it in their products as well later. So it's not for us specifically. We definitely believe that the world. We should live in a world that every repo has a configuration file in there.
Ivan: Ideally, like if it's DevContainer or something else, it doesn't matter to us, but we ideally would like that.
Justin: So you mentioned working with like alternatives besides dev containers. So, I mean, you could have docker files or like nix flicks or, you know, any number of ways to, like, set up a consistent environment. So how do you try to interface with these other configurations?
Ivan: So we, we have something just what we call builders. And so we have builders for these and we've built out, we have test versions for all of them. We should hopefully deploy that publicly very soon. They all work. The logic behind them is all identical, which is great because it makes, Our life from a interface perspective, super easy, right?
Ivan: It's just like pick a repo. We will check if there is any of these inside. And if there is, we'll just build the dev environment against that. So it's really easy for us to do for, for Nix. And I mean, Dockerfile is the easiest because you can embed a Dockerfile in the, in a dev container anyway, and it'll just, you know, execute against that.
Ivan: So that's easy. Um, Nix and Phlox, they work in the same logic and it's, it's, it's Works fairly well. We're just getting ready to launch that really soon. So the idea is that we just have these things called builders and we'll check if any of them are there automatically. And if there's more than one, you essentially pick which you, when you want, and then Daytona will build the environment against that,
[00:32:12] Challenges in Building Daytona
Andrew: this product as a whole is like pretty hard and complicated to build. And you've also put in the wrinkle of we want to be able to run it on premises and for it to serve enterprise customers. So what has been the hardest part about building something like this? Since you've done it twice.
Ivan: Yes, I've done it twice. I think the hardest part is all the integrations coming together in a single feasible interface. So like, how do you get all that there? Because you're essentially like an infra layer. You're connecting from both sides. So you're connecting on one end to your point. Oh, it has to run on AWS and GCP and Azure and any other random, you know, infrastructure you want.
Ivan: It has to connect to all these Git providers. It has to have all these builders in it. It has to connect to all these IDEs. So it feels like you're an intersection. Of absolutely everything and the flow, no matter what the inputs are from these other vendors have to be the same using Dayton itself. And so the, the hardest thing is like, when we're looking now about how to solve. You know, poly repo projects, be it that they're using, you know, a Kubernetes helm to set them up or they're using Terraform or something else. How do you create that so that it looks the same to the end user developer, no matter what is actually technically happening underneath. I think that is probably the hardest part.
Ivan: Every other integration is possible because you can integrate anything with anything. It's just like time, but how do you integrate it in a way that's That always feels seamless and consistent to the user, no matter what they're doing. I think that's probably the hardest part of that.
Justin: Do you also have to handle things like shared secrets or like secret environment variables that would be like required for development environments and stuff? Is that a layer in this?
Ivan: So Daytona automatically for there's a, there's multiple levels on the enterprise product, there's a user level, a team level and an organization basically level. And so you can set up SSH keys environment variables in any one of those. Levels, and there's also project levels. Sorry. There's multiple of those forgot that as well.
Ivan: So I, as a user can define it for me and it will be injected in every workspace. And then someone that runs a team can define it for the team and that will be injected in the workspace or someone that set up the project for that project specifically, and that will be injected. So, yeah, we handle all of that.
Ivan: So it's as easy as possible for the developer.
Justin: Yeah, I find that this is like a pretty common Frustration with basically like every company ever. It's like, Oh, here's this like an environment variable file. Let's like, figure out how to share this. And a lot of the companies that I've worked at or with recently have been like, kind of unifying around like password managers, like one password or something like that.
Justin: But it is still a bit of a inconsistent aspect and can be pretty tricky, especially if like, I mean, you know, you want to make sure that you're never accidentally using production environment variables, like unintentionally. And, um, you know, it's like something that as someone's onboarding, if they're just like grabbing the variables and they don't realize what like the difference is, or you haven't documented them well enough, that's a, it's a real risk to do something pretty gnarly.
Justin: Maybe this like leads to another question is. Um, often you have these segmentations between environments. Like I have a production environment and a development environment, for instance. And you've talked about, um, segmenting, like, secrets and environment variables across, like, these different layers. Uh, how would you handle, like, different environments?
Justin: Are they just treated as, like, different projects in a team? Or, like, um, do you have, like, first class support for, like, different environments?
Ivan: So can you reiterate the question as how
Justin: Yeah, yeah. So it's, like, if you're, if you're, like, Oh, I want to like do something against like our staging environment. Is that sort of like outside your typical development environment? And so it's like treated as like separate or like
Justin: is there something like
Ivan: we treat that as separate. So we handle everything that's in the dev environment itself. So for development, staging is sort of the next level, which we have not touched yet. So we touch into preview environments just because every dev environment itself is a preview environment in the sense of Daytona.
Ivan: So we sort of touch on that, but like staging production or anything outside of that, that stays outside of our purview for now.
Andrew: there any other big features of Daytona you want to cover before we move on to, like, more future y, nebulous topics?
Ivan: I'm Tom, Kotoli okay with nebulous topics.
Andrew: Okay.
[00:36:40] The Future of AI in Development
Andrew: So let's let's talk about a I a little bit. You just released a big old article about development in a I just the other day, and I'm interested to see how that intersects with the work that you do at Daytona. So what do you think the future of our our coding looks like with a I as our friend?
Ivan: Yeah, it was a very big article. I'm surprised a lot of people read it. It was like, it's a 15 minute read. So it's like very long for, for today's attention span. Um, the point of the article was I was trying to distill what is happening in this market of AI coding and where we as a dev environment manager sort of fit.
Ivan: And the easiest way I thought was actually writing it out. So it was like a bunch of. Of research and talking to a bunch of AI coding founders to sort of figure out where this world is going. And obviously these are all bets, right? Like there's like a bunch of people trying different things, anywhere from full autonomous coding to co pilots to AI assisting humans to humans assisting AI.
Ivan: There's also those variations of them. Like there's all different variations of where this is going and what's happening. What was interesting for me as a co founder of Daytona. Was that most coding agents right now, code assistants or full, whatever it is, run on your local machine, most of them run inside of your ID, which means that the ones that are inside of your ID only have access to files.
Ivan: They don't have access to file system itself, so they can't actually go out and run the code, which is. A constraint for sure, but you have the, you know, all hands Devon, AI type companies, and they have like sandbox dev environments where the AI can work and figure these out, which is great. I'm like, okay, these companies have a, let's call it Daytona S type thing happening underneath it.
Ivan: And like, okay, that's very interesting to us. Like, where does that go? And where does that lead? And the more I talked to all these companies, I found that most of them have an issue, at least of. You know, where is this running? Can the AI agent figured this out without saying, okay, here's a, you know, sandbox environment, you know what it is, but more than that is like, can it actually execute the code of what it's doing to figure out what to do?
Ivan: Cause you'll have a lot of these AI, uh, coding assistants, which will actually in the background, you know, try things out and figure out what will work best, and then it sort of ships that to you and you only see that visibly. So now fast forward. Imagine if. The AI co pilot or fully autonomous, whatever you want, can actually spin up multiple dev environments, the entire dev environment, and then try to execute different paths to solving a problem.
Ivan: And not only that, imagine it can like snapshot, Oh, I'm going to try something different than it just snapshots another complete dev environment and then goes off a different path. You can essentially get a unlimited number of variations to the solution. Which I think is super interesting because in our world, where humans code, you're running on one dev environment.
Ivan: Maybe you have two or three on because you want to like switch between them, but you're actually working on one in a world where AI coding is really taking off. You can imagine if, if you want to get to a solution in X amount of time, you will spend up a hundred, a thousand, 10, 000 of these at the same time, vertically.
Ivan: Just to get the output as fast as you can. Obviously this depends on like your, your constraints between time and money. But if money is not a constraint and time is, and we're not talking about a lot, but like in that time, can you spin up a burst of these environments? That is something which I believe is a huge tailwind for remote environments in general, because how are you going to solve this?
Ivan: There's no way you're solving this on your, on your local machine. And there's no way you're going to solve this just by spinning up EC2 instances. There has to be a layer. An interface, let's call it, that the AI agent can interface with and spin these up specifically for them. And that's what I think about and that's sort of the genesis of the article came from me trying to distill that, but it went in different directions because I don't think a lot of people are interested in that specifically.
Andrew: It is definitely an interesting angle, and it does sound very, very expensive. Spinning up that many dev environments at the same time. It also seems interesting from like an AI perspective. Like if you use cursor and you have a big repo, like we were trying to use it at work and one of my coworkers doesn't really believe in it was like, okay, ask it this question.
Andrew: And the guy who's super into AI was like, okay, I'll get back to you in six hours after it's done indexing all the code. So it's like doing that on each developer's machine just makes no sense. And maybe having some sort of like. Always on AI in the cloud development environment, like the cloud engineer.
Andrew: That seems very interesting to me.
Ivan: I mean, that's sort of, those are some of the key points that I think that, like, I have a lot of opinions on interfaces, so I don't think something like a Devon AI new type of interface is the long term solution. Not saying that they won't switch to something else, like, whatever, but I don't think that's the interface there.
Ivan: But what I do think they're doing really well is to your point is like, there's a Devon AI somewhere On one layer, and then it spins up these development binders underneath and then it interacts with them. I actually don't know technically if it's in the dev environment or outside. I would build it outside if I could, because then it can be like a human and manage all these things, um, on top of that.
Ivan: And so I, I see this happening and I see that that is the only way to get to the solution, which we want. And to your point with cursor as well, cursor does a lot of these things really, really well. And I'm pretty sure that cursor won't be able to, um, long term, Get to where they want to, if they can't spin up at least another parallel dev environment, sort of shadow dev environment where they can run these tests, at least one, um, while you as a human are working with them.
Ivan: And so like, how, how do they solve that? And I don't think you solve it by setting it up by hand as a human, but it will be a service that cursor will either hopefully use us, someone else build their own, whatever. But I do believe that it's the only way to solve that problem itself.
[00:42:45] Security and Access Control in AI Development
Justin: It does feel like to me that, um, another interesting, it's like a little bit parallel, but a little bit separate problem here will be just like knowing what, An AI service has access to, um, and this is like another reason why I think about dev, dev containers, especially when you get like into an enterprise context and you're like, okay, we understand their value and having like some AI service and or component and our infrastructure or something to like, help our engineers move faster.
Justin: But like, there are like, certain parts of our code that are, you know, maybe like. Audited and like supposed to be very secure. And like, you're like wanting to treat those like very separately than like other parts of your code base. And, um, just having control over access and indexing and like, you know, how these things actually interact with your infrastructure, I think is probably another interesting challenge, because if you just have, you know, a developer on your team and they're just like enabling an AI agent using any third party tool on code on their file system, it's, you know, potentially like.
Justin: You know, full scale access to this, what could be sensitive system, uh, which is like untenable. So it's like, it seems like there's going to be this future of like, how does AI interacts at an enterprise scale? And I suspect a lot of it looks like dev containers, things like Daytona, like helping manage, uh, access.
Justin: Um, but I'm curious to hear
Justin: about your thoughts on that.
Ivan: Yeah, absolutely. That is something that you have to think about. So one of the key values is rigid for Daytona is like the security management layers, like what can this developer do, what they have access to, what repos can they spin up in these different environments, similar to that. Each essential, and this is like a, you know, very new thing that we're thinking about is like each user will also have to have, Credentials specifically for their AI engineer.
Ivan: Like what can their AI connect access this repo? Can it spin up this infrastructure? Can it do these things? And when it does these things that you know that that one did it. So did Yvonne's AI do this? Or did Justin's do this? Or Andrew's? Like who's did it and who has access essentially? Like, will this be another person in your role based access control?
Ivan: Maybe, maybe not. But it definitely, there will be space. In the product itself, where you will define what the human can do specifically and what each can do. And then what each person's AI can do, um, to be able to be sure, as you mentioned, like what they have access to, what will they spin out? What will they deploy?
Ivan: What will they contribute? Like what they will do is very, very interesting. And it is one of the things that you will not be able to solve again as a SAS product for these large companies, because they're very, very scared of what may happen.
Justin: Yeah, this is so fascinating to think about.
[00:45:32] Predictions for the Next Five Years
Justin: So, um, you have worked on this problem of, like, consistent development environments in various forms for many years now. So taking what you know now and where you are at, when you think about, like, how we write software in the future, uh, or how you, like, Interface with development environments at an organization or whatever it may be.
Justin: What do you think are going to be the biggest changes that we're going to see in the next, like, five years?
Ivan: I was talking to a lot of people about this. And there's a lot of different people have completely different answers on what they think will be the future. From what I've distilled, I feel that there's basically going to be two, which are very similar to what we have today. So right now we have like the IDE, the text editor, whatever it may be.
Ivan: And I believe that will be there for the next, you know, five years for sure. Like there won't be variations, we'll add new feature sets and that, but I definitely feel that that is where it's going to go. In the meantime, there will be these like new. Like they might even exist in the sense of like a low code type things.
Ivan: So like a web flow type app, which is not for developers in the sense of engineers, but it is for people that want to make things, maybe that exists. But I think that's like a different vertical, like a no code type vertical, rather than this isn't a whole new interface. The other one is basically just like creating issues, like plain text, natural, like English language or whatever you want, where it's like, here is like a JIRA, you know, you know, Ticket, you know, um, here's what we need to be done and the AI goes out and solve it.
Ivan: So I feel that it's either here's the specification of what I need. Go out and build this thing. You get a PR, you can comment on that, you know, get back. Or it is the IDE that we know and love today with more updates and things that are. More attuned to the AI itself, everything in the middle, I feel doesn't actually have a place in the world.
Ivan: And I might be wrong. You can quote me on this. Like I can absolutely be wrong on this being in a space. Like I built a couple of versions of ID, like the only companies that have succeeded. The only company that succeeded in the last couple of whatever decade to create an ID or a text editor, uh, is Microsoft.
Ivan: And that's because they put a lot. Of both, you know, financial support into getting that done because it's part of their overarching mission. The other company, which is there is like JetBrains, which has been chugging along for a long, long time and been successful, but before that you had like Eclipse and Visual Studio.
Ivan: So I don't see another company coming in, even though we see a lot of now companies creating the AI ID. It makes sense from a developer interface standpoint. developer time perspective, like you want to own that interface, but it is such an expensive interface to own that if you don't have revenue from somewhere else, you can't make that happen.
Ivan: My only bet is if there's a new player, it will be one of the hyperscalers that creates their own. So like someone that can pay for that, a AWS, a Google, a whatever. I don't know if they're working on this. I have no inside knowledge, but I feel that they're the only ones that That can have the backing to create, to create a successful product that the developer eyeballs have enough value that they can monetize it later on.
Ivan: So that's why I don't think that a new interface per se will work because I don't see, I don't know, you guys can tell me, I don't see either of you like switching to a new interface because, Oh, because it's AI feature, right? Like. I don't know,
Ivan: but that's my sort of take on
Andrew: Yeah, I've personally tried to switch to cursor a few times, but I just don't see the value all that much. Like it, it would take a, a large amount of value for me to go, okay, I'll throw out my eight years of using VS code and the muscle memory there. Try to learn a new new tool.
Ivan: And even on that
Ivan: cursor is Like a fork of VS codes. Like it's it's like, it's mostly as good. And so a bunch of people in our team as well, like they did, they, the words were cursors too shiny or some variation of that. There's like too much going on. And they basically fallen back to either, you know, co pilot or continue dev with like sonnet inside.
Ivan: And like, it works like what they need to get done gets done without like, Yeah. Obfuscating your interface too much. And again, we may be like the quote unquote, older generation. I'm probably older, older, older generation. So the newer ones might change, but I feel it's going to be a very, very long and expensive battle to get there.
Ivan: And I don't think there's a payoff at the end of that specifically. But again, I have been wrong.
Justin: Yeah, it'd be interesting. I mean, so I've switched over to cursor pretty much full time and with pretty good experience. I think that, like, you know, a lot of this depends so much on like capabilities, speed and price. Um, you know, so it's like, you know, If the capabilities continue to increase, uh, the sort of the sophistication and the correctness of the responses continues to like get better, we're going to be looking at like a very different world.
Justin: My, my sort of like personal, uh, experience with cursor is like the big thing that it really gives me is like just a better auto complete like code plus plus, or, you know, copilot plus plus, right? It's like, I'm like renaming one. Element an array and it like auto completes like all the renames and all the elements in the array, you know, just like little things like that are powerful.
Justin: But I think of, you know, like you were saying, Yvonne about like. What is the future of collaboration on teams and especially like with non technical contributors or like low technical contributors is like creating an issue on a repo and getting a first pass PR auto generated by some, you know, system that like.
Justin: realize that like somehow based on some rubric detects that like, yes, it can like attempt to solve this problem and gives a PR that developers can like look at, edit, approve or whatever. And the sort of like underlying velocity that we get from a lot of those things. But I do think that You know, a lot of it really depends kind of on, you know, can we get more local inference happening, uh, where it's like not all cloud based, uh, can we like bring down the price?
Justin: Um, because it's like the, the iteration loop can be quite expensive with this stuff right now. And, you know, and obviously it's very resource intensive in terms of like just pure energy costs. And I think if we scale this up to like the broader industry, it's, it's going to get, you know, uh, The prices are really depressed right now because of just like VC flip, like subsidization, but it'll be interesting to see like where it goes.
Justin: And if we can maintain this pricing or if like, you know, I don't know, innovation like somehow reduces or increases the efficiency
Justin: or
Justin: something.
Ivan: I mean, there's a lot of talk and there's a lot of speculation depends on like, does the scaling law still apply? So like we've seen like the curve and we haven't seen anything go like all the models have sort of like gotten into a similar spot when you look at the graph. So like, do the scaling laws still apply?
Ivan: And if they do, then great. Then that makes sense. But if they don't, we don't, I don't know, but if they don't like the, the cost of tokens will go down for sure. And then you'll get to a place where I also mentioned, this is like, You'll probably get, and a lot of these companies already do this, where they have like an agent using multiple models or actually multiple agents doing different things.
Ivan: And then you can do very, very small models that are very good at one specific thing. And then you have essentially sort of a DevOps type thing running as your copilot or AI coding, whatever it may be. And if we get to that place, then the inference costs can be super small because the cost of tokens will go down essentially on their own.
Ivan: But also the amount that they will use will be super small because they'll just be very, very fine tuned for a specific use case. And I think that happens when, I think that happens when scaling costs, scaling laws sort of slow down because the only way you'll get to the next level of success, if you're a cursor or whatever, is by, you know, connecting these together and figuring out the best possible way.
Ivan: If scaling laws continue to go up, then the easiest way is just, oh, slap the newest, you know. LLM, that's the biggest one out there and it works and then you'll pay for the compute. So I think there's something to be said about depending on how the future continues to grow. That's how soon we get these things.
Ivan: There's an analogy. I used to be big on video games as a kid. So consoles, I used to watch all the generations. And it's always interesting. Consoles aren't that much of a thing, I think, anymore. I guess. I don't know. Um, but, but way back when, when you got the first video game on like a Super Nintendo or on a PlayStation one or whatever it was.
Ivan: Like the graphics on that compared to the last one were crap, right? It's because you can figure out what you can do with that hardware over time because you, you, because there was the only hardware you had. And it's not that absolutely the same. Don't get me wrong. I don't think it's the same argument for what we're talking about AI coding.
Ivan: Um, but if the scaling laws don't apply or don't grow that fast, then we'll be actually have to figure out by using multiple models to get to the next jump in quality, to actually be able to get users off whatever they're using to using you. And I think that breeds creativity that sort of lock into that, because right now to your point, VCs are paying, and then we can all sort of do that because we're just throwing money and just getting the most expensive one.
Ivan: And at some point. Be at the sea that AI bubble sort of pops or slow down or the scaling laws don't apply. Then we'll sort of get that creativity, which I think will be the biggest unlock for all engineers everywhere.
Andrew: Yeah, it's an exciting time. We'll see if all our jobs go away.
[00:54:58] Closing Thoughts and Reflections
Andrew: Uh, so that wraps it up for our questions on this episode. Thanks for coming on. This was a very interesting look into like remote dev environments and being able to pick your brain since you've been in this space for almost two decades now is super interesting.
Andrew: So thanks for coming on.
Ivan: I'm super happy to be here. Thank you so much. Both of you for having me. It's been an honor to be on one of the podcast, one of the few podcasts I actually listen to all the time. So
Ivan: appreciate it so much.
Justin: Thanks for your support and looking forward to your next event in New York. Uh, always, always a good time.