July 10, 2025 • 35 mins
Reliable software shouldn't be an accident, but for most developers it is. Jeremy Edberg, CEO of DBOS and the guy who scaled Reddit and Netflix, joins Corey Quinn to talk about his wild idea of saving your entire app into a database so it can never really break. They chat about Jeremy's "build for three" rule, a plan for scale without going crazy, why he set Reddit's servers to Arizona time to dodge daylight saving time, and how DBOS makes your app as tough as your data. Plus, Jeremy shares his brutally honest take on distributed systems cargo cult, autonomous AI testing, and why making it easy for customers to leave actually keeps them around.
Public Bio:
Jeremy is an angel investor and advisor for various incubators and startups, and the CEO of DBOS. He was the founding Reliability Engineer for Netflix and before that he ran ops for reddit as its first engineering hire. Jeremy also tech-edited the highly acclaimed AWS for Dummies, and he is one of the six original AWS Heroes. He is a noted speaker in serverless computing, distributed computing, availability, rapid scaling, and cloud computing, and holds a Cognitive Science degree from UC Berkeley.
Show Highlights
(02:08) - What DBOS actually does
(04:08) - "Everything as a database" philosophy and why it works
(08:26) - "95% of people will never outgrow one Postgres machine"
(10:13) - Jeremy's Arizona time zone hack at Reddit (and whether it still exists)
(11:22) - "Build for three" philosophy without over-engineering
(17:16) - Extracting data from mainframes older than the founders
(19:00) - Autonomous testing with AI trained on your app's history
(20:07) - The hardest part of dev tools
(22:00) - Corey's brutal pricing page audit methodology
(27:15) - Why making it easy to leave keeps customers around
(34:11) - Learn more about DBOS
Links
DBOS website: https://dbos.dev
DBOS documentation: https://docs.dbos.dev
DBOS GitHub: https://github.com/dbos-inc
DBOS Discord community: https://discord.gg/fMqo9kD
Jeremy Edberg on Twitter: https://x.com/jedberg?lang=en
AWS Heroes program: https://aws.amazon.com/developer/community/heroes/
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
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.
(00:20):
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,
welcome to Screaming in the Cloud.
(00:40):
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
(01:03):
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.
Thank you for having me.
(01:24):
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.
(01:47):
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?
(02:08):
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.
(02:29):
I.
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.
(02:50):
Yeah, really six to one, half a dozen to the other.
I haven't formed an opinion on it yet.
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.
(03:13):
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.
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
(03:34):
for a while, but what makes yours different?
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.
(03:54):
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.
I, this, this compliments my everything as a
database if you hold it wrong life philosophy.
So I like this approach very much.
Yeah.
And that's essentially what it is.
(04:15):
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.
(04:36):
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
(04:56):
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
(05:19):
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?
No, that absolutely is something we address.
(05:39):
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.
(06:02):
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.
(06:24):
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,
and this is the problem with the CDK as well, where suddenly
you have the infrastructure deployment code intermingled with
(06:46):
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.
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.
(07:06):
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.
(07:29):
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.
What languages do you support today?
Today we support Python and Typescripts.
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.
We'll probably have go really soon and Java by the end of the year.
(07:53):
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.
Well, no, I said, I said you can write a
fully reliable distributed system in one file.
Fair
enough.
Which isn't even grander claim.
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.
(08:16):
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?
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
(08:38):
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.
(09:00):
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.
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
(09:23):
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.
(09:45):
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.
(10:07):
Yes, I know 99% of systems will never have to deal
with this, but that 1% will keep you up for years.
Funny you mentioned that.
So at Reddit I always kept, I always kept all of our servers in Arizona time.
Why Arizona Time.
Oh, so you are the bastard?
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,
(10:29):
it was the same as where we are, which was Pacific time.
You didn't have to worry about daylight saving shifts.
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
(10:50):
of that, because I live in the Pacific time zone.
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?
I do wonder, I know that the guys that came after me
for the next decade at least, kept it in Arizona time.
(11:12):
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.
I know a few people over there.
I will look into it.
Okay.
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
(11:34):
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?
(11:54):
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.
Yeah, and that makes a lot of sense.
The, it's always a balancing act because in the early days of building
(12:14):
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.
(12:35):
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
(12:57):
in the early days, changing architectures as li as simple as.
Changing lines on a whiteboard.
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.
(13:20):
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.
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.
(13:41):
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,
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
(14:02):
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
(14:23):
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,
(14:43):
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.
(15:05):
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.
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.
(15:28):
So good work.
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.
Yeah.
What kind of applications work best on this?
(15:50):
'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.
(16:12):
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?
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
(16:32):
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
(16:56):
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.
Mainframes, uh, the curse of everything.
(17:17):
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.
Yeah, exactly.
Yeah.
We're pretty sure that this mainframe is older than, definitely
older than our co-founders and probably older than me.
This episode is sponsored by my own company, the
(17:38):
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.
(18:01):
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?
Yeah, so.
So what's interesting is because the way we checkpoint your software,
(18:24):
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.
(18:46):
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
(19:08):
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.
(19:28):
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
(19:50):
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.
I like the approach quite a bit.
What's hard right now?
What's the challenging part?
What, what keeps you up at night?
So, honestly, the hardest part right now is, is getting people
(20:10):
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.
This is gonna ring super hollow.
(20:31):
If it turns out that so far the company is just you.
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.
(20:55):
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,
(21:17):
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.
(21:37):
That's the biggest thing is catching people when they want to build something.
And try something new,
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.
(21:59):
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
(22:19):
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
(22:40):
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.
(23:02):
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.
(23:23):
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?
(23:43):
Doesn't matter quite as much.
So you've, you've passed through that gate.
Good job.
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
in cloud cost and architecture are the same thing.
(24:03):
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?
Yeah.
And that's exactly where I was at.
Uh, and it was funny 'cause our more engineering minded engineers.
(24:26):
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.
You would think that, wouldn't you?
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.
(24:48):
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.
(25:09):
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.
(25:30):
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?
So that's the best part, right?
(25:52):
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
databases or horseshit databases,
I. Uh, we offer a free RDS the smallest RDS instance.
(26:12):
It's RDS.
Cool.
That's a real database as opposed to like DNS one of my horse shit databases.
Yeah, yeah, yeah,
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
(26:33):
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.
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?
(26:54):
Yeah.
If you exit our cloud, you would need your
own server if you're not already self-hosting.
Yeah.
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
that's fine.
I run it on Lambda because transact does require it to be running all the time.
(27:15):
Okay.
At least one.
So you can have, you have one.
Oh, that's the AWS version
of serverless.
Yeah, yeah, yeah.
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.
So we do scale to zero on our cloud because we eat the cost
(27:38):
of having that one last thing running to wake up the rest.
So we do truly scale to zero,
which is the right answer.
Good job.
I'm proud of you.
But yes, if you ran it for yourself, you would
have to have something running all the time.
It, it's counterintuitive, but making it easy for people to
leave significantly decreases the possibility that they will.
I.
Yes.
No.
Agreed.
(27:58):
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.
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.
(28:22):
What's the matter with you people?
Yeah.
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.
Right.
Exactly.
And so that, that philosophy is definitely carried through.
We make it just as easy to leave as it is to arrive.
Yeah.
This is the right answer.
I like what you've done.
Uh, there is some terrifying stuff you have about
(28:44):
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.
Because the Transact app is just a Python app or a TypeScript act.
(29:07):
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.
(29:28):
It's great.
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?
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.
(29:48):
Professional advice folks, do not do that when you break your system.
Python, you'll not be going to space today.
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
(30:09):
'cause you can't install the necessary dependencies, but.
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.
(30:31):
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.
(30:52):
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.
(31:15):
You're not getting back in the plane.
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.
(31:35):
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.
(31:56):
Now make another thing reliable.
Now make another thing reliable.
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.
(32:18):
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
(32:38):
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.
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.
(32:59):
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
(33:25):
and having a wide variety of examples in the documentation that get people to,
yes, we have a ton of examples and.
I,
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.
(33:48):
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.
(34:09):
Yeah.
Yeah.
So if people wanna learn more, where's the best place for them to go?
Find out?
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
(34:29):
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.
(34:51):
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.
Yeah, thanks for having me on.
We'll have to do this again soon.
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.
(35:13):
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.
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.
(00:20):
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,
welcome to Screaming in the Cloud.
(00:40):
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
(01:03):
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.
Thank you for having me.
(01:24):
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.
(01:47):
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?
(02:08):
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.
(02:29):
I.
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.
(02:50):
Yeah, really six to one, half a dozen to the other.
I haven't formed an opinion on it yet.
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.
(03:13):
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.
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
(03:34):
for a while, but what makes yours different?
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.
(03:54):
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.
I, this, this compliments my everything as a
database if you hold it wrong life philosophy.
So I like this approach very much.
Yeah.
And that's essentially what it is.
(04:15):
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.
(04:36):
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
(04:56):
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
(05:19):
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?
No, that absolutely is something we address.
(05:39):
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.
(06:02):
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.
(06:24):
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,
and this is the problem with the CDK as well, where suddenly
you have the infrastructure deployment code intermingled with
(06:46):
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.
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.
(07:06):
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.
(07:29):
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.
What languages do you support today?
Today we support Python and Typescripts.
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.
We'll probably have go really soon and Java by the end of the year.
(07:53):
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.
Well, no, I said, I said you can write a
fully reliable distributed system in one file.
Fair
enough.
Which isn't even grander claim.
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.
(08:16):
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?
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
(08:38):
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.
(09:00):
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.
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
(09:23):
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.
(09:45):
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.
(10:07):
Yes, I know 99% of systems will never have to deal
with this, but that 1% will keep you up for years.
Funny you mentioned that.
So at Reddit I always kept, I always kept all of our servers in Arizona time.
Why Arizona Time.
Oh, so you are the bastard?
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,
(10:29):
it was the same as where we are, which was Pacific time.
You didn't have to worry about daylight saving shifts.
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
(10:50):
of that, because I live in the Pacific time zone.
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?
I do wonder, I know that the guys that came after me
for the next decade at least, kept it in Arizona time.
(11:12):
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.
I know a few people over there.
I will look into it.
Okay.
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
(11:34):
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?
(11:54):
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.
Yeah, and that makes a lot of sense.
The, it's always a balancing act because in the early days of building
(12:14):
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.
(12:35):
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
(12:57):
in the early days, changing architectures as li as simple as.
Changing lines on a whiteboard.
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.
(13:20):
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.
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.
(13:41):
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,
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
(14:02):
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
(14:23):
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,
(14:43):
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.
(15:05):
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.
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.
(15:28):
So good work.
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.
Yeah.
What kind of applications work best on this?
(15:50):
'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.
(16:12):
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?
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
(16:32):
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
(16:56):
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.
Mainframes, uh, the curse of everything.
(17:17):
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.
Yeah, exactly.
Yeah.
We're pretty sure that this mainframe is older than, definitely
older than our co-founders and probably older than me.
This episode is sponsored by my own company, the
(17:38):
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.
(18:01):
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?
Yeah, so.
So what's interesting is because the way we checkpoint your software,
(18:24):
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.
(18:46):
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
(19:08):
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.
(19:28):
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
(19:50):
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.
I like the approach quite a bit.
What's hard right now?
What's the challenging part?
What, what keeps you up at night?
So, honestly, the hardest part right now is, is getting people
(20:10):
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.
This is gonna ring super hollow.
(20:31):
If it turns out that so far the company is just you.
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.
(20:55):
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,
(21:17):
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.
(21:37):
That's the biggest thing is catching people when they want to build something.
And try something new,
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.
(21:59):
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
(22:19):
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
(22:40):
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.
(23:02):
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.
(23:23):
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?
(23:43):
Doesn't matter quite as much.
So you've, you've passed through that gate.
Good job.
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
in cloud cost and architecture are the same thing.
(24:03):
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?
Yeah.
And that's exactly where I was at.
Uh, and it was funny 'cause our more engineering minded engineers.
(24:26):
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.
You would think that, wouldn't you?
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.
(24:48):
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.
(25:09):
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.
(25:30):
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?
So that's the best part, right?
(25:52):
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
databases or horseshit databases,
I. Uh, we offer a free RDS the smallest RDS instance.
(26:12):
It's RDS.
Cool.
That's a real database as opposed to like DNS one of my horse shit databases.
Yeah, yeah, yeah,
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
(26:33):
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.
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?
(26:54):
Yeah.
If you exit our cloud, you would need your
own server if you're not already self-hosting.
Yeah.
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
that's fine.
I run it on Lambda because transact does require it to be running all the time.
(27:15):
Okay.
At least one.
So you can have, you have one.
Oh, that's the AWS version
of serverless.
Yeah, yeah, yeah.
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.
So we do scale to zero on our cloud because we eat the cost
(27:38):
of having that one last thing running to wake up the rest.
So we do truly scale to zero,
which is the right answer.
Good job.
I'm proud of you.
But yes, if you ran it for yourself, you would
have to have something running all the time.
It, it's counterintuitive, but making it easy for people to
leave significantly decreases the possibility that they will.
I.
Yes.
No.
Agreed.
(27:58):
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.
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.
(28:22):
What's the matter with you people?
Yeah.
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.
Right.
Exactly.
And so that, that philosophy is definitely carried through.
We make it just as easy to leave as it is to arrive.
Yeah.
This is the right answer.
I like what you've done.
Uh, there is some terrifying stuff you have about
(28:44):
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.
Because the Transact app is just a Python app or a TypeScript act.
(29:07):
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.
(29:28):
It's great.
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?
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.
(29:48):
Professional advice folks, do not do that when you break your system.
Python, you'll not be going to space today.
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
(30:09):
'cause you can't install the necessary dependencies, but.
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.
(30:31):
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.
(30:52):
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.
(31:15):
You're not getting back in the plane.
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.
(31:35):
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.
(31:56):
Now make another thing reliable.
Now make another thing reliable.
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.
(32:18):
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
(32:38):
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.
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.
(32:59):
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
(33:25):
and having a wide variety of examples in the documentation that get people to,
yes, we have a ton of examples and.
I,
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.
(33:48):
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.
(34:09):
Yeah.
Yeah.
So if people wanna learn more, where's the best place for them to go?
Find out?
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
(34:29):
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.
(34:51):
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.
Yeah, thanks for having me on.
We'll have to do this again soon.
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.
(35:13):
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.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Special Summer Offer: Exclusively on Apple Podcasts, try our Dateline Premium subscription completely free for one month! With Dateline Premium, you get every episode ad-free plus exclusive bonus content.
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!