Reliable Software by Default with Jeremy Edberg

Transcript

Jeremy Edberg: And there's a really interesting use case around autonomous testing. So you know there's automated testing, which is what you're familiar, everyone's familiar with, right? You read a bunch of tests. Then there's autonomous testing where you essentially teach an AI how to test your system, which then in theory finds a bunch of stuff that you didn't even think of to test for.

And the greatest data set to train one of those ais is all of your previous inputs and outputs. So you can feed that into an autonomous testing system and train this, this perfect testing ai. Basically,

Corey Quinn: welcome to Screaming in the Cloud. I'm Corey Quinn. My guest today presumably needs no introduction for a large swath of. Folks listening and or watching to this, but we can't ever assume that Jeremy Edberg is a whole bunch of things, uh, Jedberg on the internet and has been around forever. Today. He's the CEO of something called DBOS that I'm certain we're going to get into, but he was the founding reliability engineer for Netflix.

Once upon a time, he was the first engineering hire at Reddit. A small website that you might have heard of. Uh, he's one of the original six AWS heroes. He's been doing this a very long time. Jeremy, thank you for taking the time to speak with me.

Jeremy Edberg: Thank you for having me.

Corey Quinn: This episode is sponsored in part by my day job, the Duck bill group.

Do you have a horrifying AWS bill? That can mean a lot of things. Predicting what it's going to be, determining what it should be, negotiating your next long-term contract with AWS, or just figuring out why it increasingly resembles a phone number, but nobody seems to quite know why that is. To learn more, visit duck bill group.com.

Remember, you can't duck the duck bill. Bill and my CEO informs me. That is absolutely not our slogan. So I, I guess we could always start at the beginning and work forward, but that's dull. I like starting at the, uh, at the present. Maybe we'll go backwards and see what happens. What's a DBOS other than thing your CEO of?

Jeremy Edberg: Yeah, so DBOS is a company that makes an open source library called Transact, which helps people build reliable software by default. Uh, and then we have a product that will help you run that transact application anywhere. Cloud, our cloud on-prem, whatever it is. Uh, and then we also offer a cloud for you to host your transact applications if you don't wanna do it for yourself.

I.

Corey Quinn: It seemingly seems that most people build reliable software entirely by accident, but doing it by default does seem like a decent way of approaching things. It is DBOS, and I am pronouncing that as debos correctly. I mean, I know you're, you did work at Amazon for a time, so I don't know if you're doing the whole, uh, a MI, it should be mispronounced as AMI thing or not, but you know, DBOS Debos.

Yeah, really six to one, half a dozen to the other. I haven't formed an opinion on it yet.

Jeremy Edberg: There's a story there. It used to be DBOS because the project started as a database operating system. Our co-founder was the creator of Postgres and Spark. So, uh, originally that was the premise, but what we realized was one that would take over a decade to build, and two, it would be very hard to commercialize.

And so what we realized is that the most interesting part of it was keeping state while running. And so we, that's what we commercialized.

Corey Quinn: So as you look at this entire thing, and I, I guess look at the landscape out there, it sounds almost like what you're building is sort of a modern Heroku style thing, which, you know, everyone has been trying to build except the company that bought Heroku, but I digress.

They're sort of coming out of, uh, hibernation for a while, but what makes yours different?

Jeremy Edberg: So that is actually what we were building, but what we realized is that the most interesting part is the library that you use to build with. And so our premise is that everything should be in the database you're.

Your application, uh, running state should be as durable as your data. And so that's what we do. We essentially checkpoint your software into the database so that you can roll back at any time, resume from a crash. Stuff like that. And so what ends up happening is every piece of your business process is a row in the database table.

Corey Quinn: I, this, this compliments my everything as a database if you hold it wrong life philosophy. So I like this approach very much.

Jeremy Edberg: Yeah. And that's essentially what it is. And so that's our main thing is that library getting you to build things reliably by default and then helping you run them. We do have the cloud, uh, and we were trying to be the easiest, best place.

But it turns out that that's really hard. And and most importantly, it turns out that people prefer the privacy and reliability of running it themselves.

Corey Quinn: Well, I, through no fault of your own, you've picked the wrong freaking day to have this conversation with me because yesterday I was programming in the only two languages I know brute force mixed with enthusiasm to build this dumb thing to stuff into a Lambda function where it will live.

And once again, I am. Dismayed to discover that there's no good way to deploy Lambda functions from development into production. There are merely different flavors of bad. Uh, originally I used the serverless framework, which went in some strange directions. I don't use it anymore. The CDK turns everything into a dependency update issue every time you want to use it.

Uh, the console gets you yelled at, but people use it like that anyway. And, and the only answer that I found that works reliably for me is I got something working with the Sam CLI many years ago, and I've just copied and pasted that template file around ever since with minimal changes, which is not ideal, but also honest.

Uh, is what you're doing, like does it address that particular side of the world or am I thinking about this in a two from a different angle?

Jeremy Edberg: No, that absolutely is something we address. So we really focus on developer experience and one of the biggest problems with serverless is the one you just said is that the local development story is terrible, uh, and the local testing story is terrible.

And so we focused on that. We made it so that when you use our library, it'll run locally exactly the same way as it runs in the cloud. So if you use our cloud, all you have to do is deploy. Uh, if you use your own cloud, it is literally the same application in production and in test, and it works the same way and it's all one file.

That's another big thing. When you use us, you can do pretty much everything in one file. We have Krons right there, so you don't have to use another service for that. Uh, we have queues built right in, so you don't have to use another service for that. Because that's another big problem with serverless, right?

Is lambda is Lambda and it's compute. And then, oh, I need a queue. Okay, you need this other thing. Oh, I need uh, you know, storage. Okay, you need this other thing. Oh, I need CR jobs. You need this other thing. And it's suddenly becomes this huge mess of config files and tiny little programs and. Get deployed all over multiple services,

Corey Quinn: and this is the problem with the CDK as well, where suddenly you have the infrastructure deployment code intermingled with the actual application deployment application code itself.

So then you wind up with, it's not really clear, at least to me, in many projects I see where the deployment stuff starts and stops versus the application logic itself.

Jeremy Edberg: So we actually lean into that. With us, like I said, you can do an entire fully reliable program with one file, uh, because we use decorators.

So you decorate your code. You say this function is, you know, uh, needs to be a step of this workflow. You can do Aron decorator, a queue decorator, and it's all in one place. And so really what you don't even have to worry about the infrastructure, it's essentially derived from your code. And we actually think this is better for the developer experience because then you don't have to think about infrastructure at all.

You do is you write your code and you say step one, step two, step three, cr, job Q and the infrastructure is just taken care of for, for you. You don't have to manage it anymore 'cause it's all in the database.

Corey Quinn: What languages do you support today?

Jeremy Edberg: Today we support Python and Typescripts.

Corey Quinn: The only two that really matter.

Sure. I mean, Russ matters. You wanna talk about it a lot and not do anything that's fun.

Jeremy Edberg: We'll probably have go really soon and Java by the end of the year.

Corey Quinn: Okay. I mean, because when you say, oh, you can write an entire program in one file, it sounds like yes, I can write anything in one line of code as long as I use enough semicolons.

Like same theory applies.

Jeremy Edberg: Well, no, I said, I said you can write a fully reliable distributed system in one file.

Corey Quinn: Fair

Jeremy Edberg: enough. Which isn't even grander claim.

Corey Quinn: It really is. Uh, and this gets to sort of one of my personal hobby horses. I see that there's a sort of cult of distributed systems where. Relatively straightforward things that you, that don't necessarily benefit from being distributed.

In fact, there's some drawbacks to it, seem to be forced on into that paradigm. Where do you land on it?

Jeremy Edberg: So I would say that most people for most applications do not need a fully distributed system. In 95% of the cases, your application will run with one or two, uh, you know, executors with a database. Right.

Maybe you want two or three for load balancing, for reliability, but you often don't need more than that. I think that is the, the biggest issue is people are, you know, especially when microservices are popular, they're ga, they're, they're waning now, but for a while, everybody build everything as a microservice, you know, from scratch.

Uh, a lot of people like, so we do everything in Postgres, right? And people are like, well, what happens when you outgrow your one Postgres machine? You know what? 95% of people are never gonna outgrow that one Postgres machine. It turns out that they can do quite a lot with one machine.

Corey Quinn: I didn't expect to hear this coming from you just based upon the read of your resume.

I did at the beginning. You've worked in places where you do folks launch something publicly at any of these places historically, and you're gonna get 10 million users on day one, and that is something that leads to its own. I guess life philosophy that the rest of us don't really have to deal with.

Like what if you get so many users, you outgrow a single postgre squeal database, it's, well, I should be so lucky. That sounds like a problem that I can solve with all the money that comes pouring in. But there's a But that I see a lot of folks. Doing the early optimization stuff, which is weird and I understand cuts against something I've been saying for years that people argue with in the other direction, which is even when you're building something small, scrappy, and local, the only true time zone for servers and databases is UTC because that is so freaking hard to unwind.

Yes, I know 99% of systems will never have to deal with this, but that 1% will keep you up for years.

Jeremy Edberg: Funny you mentioned that. So at Reddit I always kept, I always kept all of our servers in Arizona time. Why Arizona Time.

Corey Quinn: Oh, so you are the bastard?

Jeremy Edberg: Yep, yep. Because it was one hour off of where we were for four months of the year and the remaining eight months of the year, it was the same as where we are, which was Pacific time.

Corey Quinn: You didn't have to worry about daylight saving shifts.

Jeremy Edberg: No, no. Daylight saving shift in Arizona, so I didn't have to deal with it at all. And calculating what the log time was versus the wall clock was super easy. 'cause most of the year it's the same. And some of the year it was subtract or add one. Right.

So I almost never kept anything in UTC because of that, because I live in the Pacific time zone.

Corey Quinn: Okay. If I were to go and talk to people at Reddit today, since you were the first ops person there decade and two decades ago, damn near, uh, are there still vestiges there of things being kept in Arizona time because of that decision you made early on?

Jeremy Edberg: I do wonder, I know that the guys that came after me for the next decade at least, kept it in Arizona time. Uh, I don't know if they've still done that now. But, uh, that would actually be a fun, fun question to think about.

Corey Quinn: I know a few people over there. I will look into it. Okay.

Jeremy Edberg: What I do tell people is you should build, assuming that you're going to have to scale.

So all I've said, I've been saying this for decades, build for three, right? Assume that at some point you're gonna have three of everything, and that's a good optimization to make early on. But. Don't actually build it all. Like, you don't have to make three, you don't have to use three availability zones or, uh, you know, three servers right off the bat, but assume you will have that.

So don't use shared memory locally, stuff like that, right? Uh, like put things into a queue, put things into a, a, a storage place that can be expanded. Those are the kinds of things you should be doing from the start. And you know, not to bring it back home, but that's basically what our library lets you do kind of by default.

Corey Quinn: Yeah, and that makes a lot of sense. The, it's always a balancing act because in the early days of building something, it's, you can basically spend all your time building for massive scale that will never arrive, and that's all wasted effort and it slows you down in some ways, and you never actually ship anything.

Uh, there are far more companies out there that have failed from people over indexing on making the code better and not the important problems like, do we have a viable business because. When you have a good business, you can afford a bunch of people to come in and rewrite things and fix your horrible time zone choices and all kinds of other things down the road.

But the, it's a balance with anything like, I, I don't need to go out of my way necessarily to plan for massive scale, but I also should very much not be making decisions that are incredibly shortsighted that I'm going to have to back out stupendously because in the early days, changing architectures as li as simple as.

Changing lines on a whiteboard.

Jeremy Edberg: Yeah, yeah. Yeah. And like, I mean we're, I'm the head of a startup now and we have a small team and there's definitely places where it's like, you know, this is not the best practice, but we know that. And we say, this is not the best practice. This is what we're going to have to change when we get to the scale where it matters, and then acknowledge that and then move on.

Because we know that when we get to that scale, we'll be able to hire the extra people we need to make those changes.

Corey Quinn: Yeah. There's a. There's a lot to be said for that. So I have to ask Now this is sort of a rude question to to, to ask any startup founder, but I'm gonna go for it anyway. So you're building a library that makes it very simple to build and deploy a bunch of apps.

Awesome. Terrific. Great. I. Where's the money? Where? Where does it come in to the point where, and now in return for this open source library, I cut you a check. It seems like that's like step two, draw the rest of the owl for an awful lot of folks,

Jeremy Edberg: that is a totally valid question, right? This is the standard open core model question.

So we. We would love to see everybody in the world building on our free open source library. 'cause we just think it makes the world better. Where does the money come in? Once you start to need more than one of them, it's, it's actually complicated to operate. And so that's what we provide. So we provide a thing called conductor.

You connect your multiple executors to conductor and conductor manages moving the workloads around autoscaling, resuming all of that stuff for you, or you use our cloud and pay us money for that. And it's the same thing, right? You get conductor as part of using our cloud and that manages all of your autoscaling, uh, you know, VM management, all of that.

So we run our own cloud in AWS on a bare metal instance where we run our own fleet of firecracker VMs. And for those who don't know, firecrackers, the same thing they use to run Lambda. Uh, and so we run our own fleet. It's far more efficient, so we can charge a lot less than Lambda does. Uh, and if you use our programming paradigm of everything is a workflow, we also don't charge, you know, when you're computing, like waiting for an LLM because there's nothing running when you're waiting for the response.

Uh, and so, you know, if you use our cloud, it's super efficient. If you run it locally, it's actually super efficient and private. And then we'll help you scale and manage. That's where the money comes in, and that's where people pay us. They pay us for support. They pay us for conductor, they pay us for our cloud.

Corey Quinn: And I just checked, well, you mentioned this as well, you're MIT licensed as well, which means that if you're, if you're planning on doing a licensing rug, pull down the road, you're doing a terrible job of setting the stage for that. So good work.

Jeremy Edberg: Uh, hey, we do not believe in that. We, we believe in open source.

We believe in. We truly believe that the world would be a better place if everybody used our library. If our company goes away, so be it. As long as people are building reliability reliably, obviously we don't want our company to go away. We'd, we'd like to continue to exist, but.

Corey Quinn: Yeah. What kind of applications work best on this?

'cause very often when I talk to folks who are building a thing to construct applications with, they have a very specific vision in mind of what type of application it is. Uh, a lot of stuff I build tends to be, uh, ephemeral, stateless stuff. It's a lambda function and no source of truth. That sometimes gets a lot of strange brokenness when I try and integrate those things with.

Other stuff. Conversely, some folks are like, well, okay, we have a giant shared database. Uh, you, you should never do that. It's great. We're a bank. We kind of have to do that. It, it's a, it's a question of what are you targeting as the sweet spot?

Jeremy Edberg: Yeah. So, so we have customers all over the place, but the main use cases that we see are these data pipeline use cases.

So I need to get data out of one place and into another. Reliably in a way so we can guarantee once and only once execution because of the way we operate. And that is important to a lot of people. I need to guarantee that I got the data outta this system and that it went into this other one, but only one time.

And that turns out to be a fundamental problem for AI workloads. Uh, because. Training your AI or doing inference, you need to make sure that your data is moving from one place to another. Uh, and so that is a huge, uh, that a lot of our customers are doing, that they're using us for their agentic AI workloads, uh, managing their agentic ai or managing, extracting data from their legacy systems into more modern, often AI systems, things like that.

Uh, so we're working with, uh, a extremely large bank that you've definitely heard of, uh, to extract data outta their, uh, their mainframe system.

Corey Quinn: Mainframes, uh, the curse of everything. There's no good way around it. For better or worse, there's a, you wind up persistently living in a, in a weird place, let's put it that way.

Jeremy Edberg: Yeah, exactly. Yeah. We're pretty sure that this mainframe is older than, definitely older than our co-founders and probably older than me.

Corey Quinn: This episode is sponsored by my own company, the Duck Bill Group, having trouble with your AWS bill. Perhaps it's time to renegotiate a contract with them. Maybe you're just wondering how to predict what's going on in the wide world of AWS.

Well, that's where the Duck Bill group comes in to help. Remember, you can't duck the duck bill. Bill, which I am reliably informed by my business partner is absolutely not our motto. As far as the, uh, uh, what's the next step? What are the, what's the vision for this? Is it designed to go to effectively do the same thing and just keep iterating in the same direction?

Are there basically orthogonal, uh, pivots almost you can make as you continue to grow? Where is it going vis-a-vis where it is today?

Jeremy Edberg: Yeah, so. So what's interesting is because the way we checkpoint your software, we essentially record all of your inputs and outputs of your functions. And what that does is it means that we have this really interesting met database of inputs and outputs of your functions.

And there's a lot you can do with that. There's a really interesting security play there. Uh, there's intrusion detection that can happen nearly instantaneously, uh, with a simple SQL query. Uh, there is a lot of operational interest there. Uh, you know, 'cause you can see the ins and outs, the workflows, how big the responses are, stuff like that.

Uh, the response times, and there's a really interesting use case around autonomous testing. So, you know, there's automated testing, which is what you're familiar, everyone's familiar with, right? You read a bunch of tests. Then there's autonomous testing where you essentially teach an AI how to test your system, which then in theory finds a bunch of stuff that you didn't even think of to test for, and.

The greatest data set to train one of those ais is all of your previous inputs and outputs. And so you can feed that into an autonomous testing system and train this, this perfect testing AI basically. And that's, that's like the next step. And then the next next step is being the operations panel for.

Everything on the internet, right? So it's, uh, you know, start putting in chaos testing, start putting in, uh, other different ways of helping you operate, storage, management, whatever it is, right? That's the long term future is, is let us, uh, you write your code, we'll operate it for you, right? We're the operations experts for you, so we'll operate your stuff.

You write your code.

Corey Quinn: I like the approach quite a bit. What's hard right now? What's the challenging part? What, what keeps you up at night?

Jeremy Edberg: So, honestly, the hardest part right now is, is getting people to know about what we're doing, uh, getting the message out. Go to Market strategy. That is literally the hardest thing right now, engineering wise.

Uh, I mean, I have to say this. I'm the CEO, but I really truly believe it. This is the greatest engineering team I've ever worked with. These. Here's my favorite example.

Corey Quinn: This is gonna ring super hollow. If it turns out that so far the company is just you.

Jeremy Edberg: No, no, no, no, no, no. I have this amazing engineering team.

Uh, so we have these two co-founders who are grad students. Uh, they came out and immediately started this company. The, when I joined the company, so I, I wasn't there from the founding. I started a little after, uh, they told me, okay, uh, you know, this was in July. They said, we're gonna be launching Python support on September 12th.

I was like, you have a specific day in mind, three months down the line. Okay, whatever. Literally, September 11th at night, they deployed it and it, on September 12th, they announced it, and I, I, I was shocked that they were able to. Pinpointed that closely as a startup. Uh, and this is just an example of what they can do.

So I, I do not worry about engineering. People ask, some people ask me that, like, oh, what do you worry about engineering? I dot I'm not worried about engineering. I'm completely, that is the hard part, especially with a dev tool, right? Dev tools are, are really hard. There's no. Instant aha moment. Like a consumer application where you just try it and you're like, oh, this is great.

Right? There's like a learning process. You gotta have something to build. That's the biggest thing is catching people when they want to build something. And try something new,

Corey Quinn: which I find myself perpetually in the, in the blend of living with. So I am possibly your target market. So let me, let me talk through what I think about when I go to DBOS.dev and the thoughts that I have.

The first thing I always do is ignore everything you've put on your front page. That is invariably for any given company. Marketing has workshopped that to death or at least should have workshopped that to death. Great. And the thing I go to is one of the two places on your website where you have to be honest, arguably three, the one that we don't care about is terms and conditions.

You're going to be very honest and direct and if you spoke to people like that, you get punched in the mouth a lot. The second where you might be, uh, a little bit more direct is in the careers section because alright, what technology are they really using under the hood? People disclose a lot, but the one I start with is the pricing page.

And I look for two specific things on it. The, well, I guess first what I'm trying to figure out is, is this for me, because if I'm looking at this and I'm trying to do a side project and it's $5,000 a month or call for details, then I know I will not be going to space today. And I'm not your target market.

I'm, when AWS released Amazon Kendra, I was excited about it for the 30 seconds it took me to realize it started at 7,500 bucks a month, which was higher, and in turn money to organize my data instead. Uh, then, so you start the price, the one price you have, and this is $99 a month for your middle tier.

Fine, reasonable, that is, that is absolutely fine to deal with. But the other two are what I look for First, I wanna see a freeze trial or free thing that I can get started with today because I might be working on a problem and my signing authority caps out at $20. I don't wanna have to do a justification for something new.

You've got that. On the other end of the spectrum, we are a large enterprise. If there's not an enterprise offering where the price is contact sales, then it's you present as being too small time and procurement teams get itchy at that. They don't know how to sign anything that doesn't have both custom terms and too commas in the price tag.

So you want to be able to catch the low end and the high end, and what's between those two? Doesn't matter quite as much. So you've, you've passed through that gate. Good job.

Jeremy Edberg: Thank you. It's funny you should say that because we had this long debate, uh, at, at, at the company about the pricing page and how important it is, and I was on the side of.

It's where most people start. Uh, and uh, some other folks

Corey Quinn: in cloud cost and architecture are the same thing. And you, and you ignore that reality at your peril. I always start there because I wanna know not only what is it gonna cost, but what are the axes that you folks think about these things on and what are the upsell things and where at what point does my intended use case start to look like a pretty crappy fit for what you might wanna do?

Jeremy Edberg: Yeah. And that's exactly where I was at. Uh, and it was funny 'cause our more engineering minded engineers. Who, you know, were the ones who were like, no, no, they're gonna look straight at the docks. I said, well, some engineers will go straight to the docs and that's another place where you kind of have to be honest, right?

You have to, your documents have to be correct.

Corey Quinn: You would think that, wouldn't you?

Jeremy Edberg: Well, okay, sure. A lot. I guess Some people do shove marketing in there, but we generally try to make our documents as accurate as possible.

Corey Quinn: Le le less about marketing and more about, uh, pe. People write docs and they don't manage to step outside of their own use case and their own expectations, and they're too close to the product.

So it's cl the docs make perfect sense if you've been building with this already. Uh, classic example I love to use for this is Nix, uh, the Nix documentation assumes you've been using Nix for a long time, including their tutorial get started problem. Great. That needs some love. But the other thing I look for when I'm trying to decide for something like this, where I am building out a thing, is assume that at some point our interests are no longer going to align.

Maybe your company is going to pivot to social networking for pets regardless of what that thing is. I there, there might be a time where I need to deviate from the way that you've done these things. What does the Exodus look like to run this in my own AWS environment? And that's something that's not as easy to see from the shiny webpage.

You actually have to kick the tires on it. Or in my case, I ask you what's the exodus look like if I decide down the road that we're not strategically aligned?

Jeremy Edberg: So that's the best part, right? Like I said, we, we care about developer experience. You, the code is yours. It can run anywhere. Uh, the data is yours.

Generally, most people bring their own database. Uh, we do offer databases that you can use, but real

Corey Quinn: databases or horseshit databases,

Jeremy Edberg: I. Uh, we offer a free RDS the smallest RDS instance.

Corey Quinn: It's RDS. Cool. That's a real database as opposed to like DNS one of my horse shit databases. Yeah, yeah, yeah,

Jeremy Edberg: yeah, yeah.

Real database. You have to use real Postgres to for us. Yeah. Uh, but also you can use any Postgres provider. So a lot of people use superb base or neon or whatever it is, but, um, you know. You can bring your own. And most customers who are more than just a tiny hobby actually do bring their own. So the exit from our company is actually really, really easy.

You just take your transact app and run it for yourself if you're not already doing that against the database that you probably already own.

Corey Quinn: Got it. And you can deploy it into your own environment. Uh, does it presuppose that you have a server of some sort to deploy this on or fleet of servers? Does it deploy directly AWS Lambda?

Yeah.

Jeremy Edberg: If you exit our cloud, you would need your own server if you're not already self-hosting. Yeah.

Corey Quinn: Okay. I, I have to imagine the event of an Exodus. People are not like, well, I wanted to run on only on Lambda for budgetary purposes. Like, that's great. You might not be the target market for this thing. And

Jeremy Edberg: that's fine.

I run it on Lambda because transact does require it to be running all the time.

Corey Quinn: Okay.

Jeremy Edberg: At least one. So you can have, you have one. Oh, that's the AWS version

Corey Quinn: of serverless.

Jeremy Edberg: Yeah, yeah, yeah.

Corey Quinn: Doesn't scale to zero. And they're like, oh, we've never said it scales to zero. And then I look at the way back machine when they first launched serverless, and it says prominently scales to zero.

It's don't try it. Pretend I didn't read what I read. I remember these things.

Jeremy Edberg: So we do scale to zero on our cloud because we eat the cost of having that one last thing running to wake up the rest. So we do truly scale to zero,

Corey Quinn: which is the right answer. Good job. I'm proud of you.

Jeremy Edberg: But yes, if you ran it for yourself, you would have to have something running all the time.

Corey Quinn: It, it's counterintuitive, but making it easy for people to leave significantly decreases the possibility that they will. I.

Jeremy Edberg: Yes. No. Agreed. And that, that was our philosophy way back in Netflix. It was when everyone else made you call to cancel Netflix, just put a cancel button right on your, your profile.

Corey Quinn: Oh. Every time a company was whining and crying, when California changed the law that if you can sign up online, you need to be able to cancel online. And the wailing and gnashing of teeth, it's like. Making it difficult to cancel is not a business practice I find ethical. What's the matter with you people?

Jeremy Edberg: Yeah.

Corey Quinn: Yeah. You don't, don't annoy. Don't make it just inertia. The only reason people continue to spend money with you, you want happy customers, not hostages.

Jeremy Edberg: Right. Exactly. And so that, that philosophy is definitely carried through. We make it just as easy to leave as it is to arrive.

Corey Quinn: Yeah. This is the right answer.

I like what you've done. Uh, there is some terrifying stuff you have about the open source version on that pricing page. You mentioned that it has a built in time travel debugger, which is awesome, but yet presupposes At one point I built something that was working, uh, so you know it's better for people who are good at things, uh, but you also say it runs on Linux, windows, and Mac.

Uh, that's insane. Explain that to me, please.

Jeremy Edberg: Because the Transact app is just a Python app or a TypeScript act. Anywhere that you can run Python, you can run transact apps. So you can run it locally on your Mac. That's how most of us do development, uh, Linux obviously. And yeah, you can get, uh, we do have people who use Windows.

Actually a couple of our engineers use Windows. Uh, one of our engineers was a long time veteran of Microsoft, loves to use Windows, and so he runs his stuff locally on Windows. It's great.

Corey Quinn: Got it. So does this run, so if, if it runs in a developer environment, does this run inside of a Docker container? Does it run, uh, using the system?

Python, heaven forbid? I mean, how does it work?

Jeremy Edberg: You can do it however you want, right? It's up to you. You can put it in a Docker container, that's fine. You can splat it straight into your system. Python, if you want, that's fine too. Not recommend it.

Corey Quinn: Professional advice folks, do not do that when you break your system.

Python, you'll not be going to space today.

Jeremy Edberg: Not recommended, but you can do it if you wanna shoot yourself in the foot like that. We don't, we are not opinionated about what your development environment looks like other than you have to have our dependencies. So that's, that's the main catch, right? So using the system, Python is probably not gonna work 'cause you can't install the necessary dependencies, but.

Corey Quinn: Another thing I look for in tools like this, especially as I think of it from the more complicated enterprise perspective, uh, there needs to be something of a golden path that guides me through things. Otherwise, you wind up with death by configuration options, the decision fatigue, analysis paralysis becomes a real thing.

So by default do a bunch of stuff. Like what are the worst examples I can think of, of, uh, of. Making that painful for customers, go ahead to the console and try and set up the, uh, a CloudFront distribution. Uh, they may have changed that somewhat recently, but. A few years ago at least, it was brutal. There are, there were at least 70 options, five of which most people used, and it was terrible and it, it was confusing.

So you need to give people a chance to deviate from that golden path as well as having it. So, okay, here I need to do something a little bit different. Instead of using RDS, for example, I want to use superb base or neon or something else. But once I've done that. I want to go back to the golden path.

Aside from that deviation, so many tools are, once you eject, you're done. You're not getting back in the plane.

Jeremy Edberg: Yeah. And, and we totally agree with you, right? That, that here's the golden path. And the golden path is take our sample apps and modify them, uh, and then you can modify them and deviate in whatever area you want.

That's our total philosophy for our entire product actually, is all of our competitors. When you want to add durability, they make you rewrite your whole thing to their. Style, right? You gotta say, this is gonna be the reliable part for us. You add a decorator to the one thing that you care the most about and start there and then you can expand from there.

So our entire philosophy is about. Easy, gradual introduction, right? It's take your big piece of software and make one thing reliable. Now make another thing reliable. Now make another thing reliable.

Corey Quinn: That's the challenge too, is people wind up perpetually finding themselves in worlds where the things they care about are not necessarily things others care about.

And finding out where those points of commonality are and where those divergences are is super handy. Um, one of the biggest problems you're gonna have with getting something like this, uh, adopted is that it's not adopted already. And it's, it's sort of paradoxical, but like the number one thing I look for when I'm trying to do work with a deployment system is, alright, what community support is there?

Uh, I want to ideally not be the only person who's ever tried to hook it up to a load balancer, for example. Uh, that's never great. Uh, and like, especially if you're a, if you claim to be a hyperscale cloud provider. That's a problem for those folks. Uh, for something like this, it's a lot more fluid, but it also increases the likelihood that I'm going to blunder into sharp edges at some level.

Jeremy Edberg: Yeah. Yeah, that's a huge problem and a big thing with DevTools, right? Is you have to bootstrap that community. Uh, we, we are doing kind of this typical what a lot of the DevTools now do. We have a discord, all of our employees are there. They can answer questions. We set up Slack channels with our. Most of our customers, you know, all of that stuff.

But you're absolutely right. The bigger the deployment, the easier it is to run. You don't want to be the first, uh, and I totally get that. And that's a bootstrapping problem, and that's a bootstrapping problem that pretty much everyone has. We've tried to make it as easy as possible by hiding most of the complexity

Corey Quinn: and having a wide variety of examples in the documentation that get people to,

Jeremy Edberg: yes, we have a ton of examples and.

I,

Corey Quinn: I, I hate the, oh, wow. There's five examples here. And none of them mapped to anything remotely like what I'm doing. And like, I often tend to view that as a leading indicator that I might not have a great time with this just because I am already off the beaten path. When you build something purely in Lambda, for example, without any real stateful stuff or server side things.

That's often not well supported by an awful lot of stuff out there. So I know going into that, that I'm, I'm an edge case. Some things embrace that edge case and some don't seem to know that they exist and that latter category, I, I don't have a great time with those.

Jeremy Edberg: Yeah. Yeah.

Corey Quinn: So if people wanna learn more, where's the best place for them to go?

Find out?

Jeremy Edberg: Uh, so if they wanna learn more about DBOS, obviously start at our website. dbos.dev d-b-o-o-s.dev. If it's easier to remember that way, uh, that's the best place to start. Or docs do DBOS, do Dev is if you're the kind of engineer that we talked about earlier who likes to dive straight into the documentation, that's actually a great place to start.

We've got a quick start there and so on. I personally like to learn from just reading examples, so like you just said, we have a ton of those and that's usually where I start. Uh, but yeah, our GitHub, please go give us a star. We would love to get that. Uh. It's just, uh, DBOS Inc. On GitHub. Those are the best places to Start.

Corey Quinn: And we will of course put links to all of this into the show notes because that's what we do.

Thank you so much for taking the time to speak with me today. I appreciate it.

Jeremy Edberg: Yeah, thanks for having me on. We'll have to do this again soon.

Corey Quinn: Absolutely. Jeremy Edberg, CEO at DBOS. I'm Cloud Economist Corey Quinn, and this is Screaming In the Cloud. If you've enjoyed this podcast, please leave a five star review on your podcast platform of choice.

Whereas if you've hated this podcast, please leave a five star review on your podcast platform of choice along with an angry, insulting comment. That is no doubt set to Arizona time.