Ep. #73, Serverless Made Easy with Brian LeRoux of Begin

Brian Douglas: Welcome to another installment of JAMstack Radio.

On the line, I've got Brian LeRoux.

Brian, do you want to introduce yourself and tell us why you're here?

Brian LeRoux: Yeah, sure. I'm a Webbie web developer.

I've been doing this web thing for quite a long time, and I'm a big fan of the empowerment of what the web has enabled, and I've always kind of hung around the front end web community even before there was one.

And I think the reason I'm here is to talk a little bit about the JAMstack but also my company, Begin, and how we kind of intersect with that world and what that whole world means.

And I guess it's worth mentioning.

In my former life, I worked on a project which is renowned for being one of the most loathed projects on Stack Overflow, PhoneGap and/or Cordova.

And so to the listeners, I apologize if it gave you trouble.

It wasn't my fault. It was Adobe's.

And if it was great for you, then that's awesome.

It was because of me.

Brian Douglas: You worked as an Adobe employee at the time?

Brian LeRoux: Yeah, I did.

Well, I started working on that project with sort of a group of misfits in Vancouver in 2007, 2008 timeframe.

And PhoneGap is like a lot of Webbie open source projects.

It was immediately a huge success right away. I'm joking.

So we started working on it in 2007, and we kept working on it until about 2011 when we got acquired by Adobe.

Brian Douglas: Oh wow.

Brian LeRoux: So there was a long period of questionable opportunity cost spent working on that one, but it grew consistently the entire time.

And then by the time we got acquired, it was a runaway train.

I think we ended up becoming responsible for about 20% of the app store.

And today, I think the torch has been taken up by Ionic, that crew with the Capacitor JS stuff, and they're still growing like gangbusters.

So there's definitely something to this internet thing. It's always growing.

Brian Douglas: Yeah. I mean even with the mobile space.

We've got Ionic and then React Native and Expo and all these other--

What was the one? The one made in Dart, Flutter?

Brian LeRoux: Oh, Flutter. Flutter's cool.

Yeah, I like that one.

And I don't mind Dart. Dart had such a strange start that I think it sort of alienated itself with the JavaScript developers, but luckily time has gone on long enough that it looks a lot like TypeScript and no one knows.

Brian Douglas: Yeah. I mean, that's how it feels. Yeah, exactly.

Brian LeRoux: It's typed.

It's a beautifully designed language.

It came from a lot of the best minds at Google.

It's funny that it found its niche over in mobile though.

That wasn't something I had expected for it to happen. But yeah, it's cool.

Brian Douglas: Yeah. It definitely came out of left field, for sure.

But speaking of left field, so we originally met at Reactathon three years ago.

I was MCing, and then you were one of the speakers.

You gave an amazing talk. I think you were talking about Arc at the time.

I'm not even sure Begin was around at that time.

Brian LeRoux: Probably not. Yeah.

So Architect is the open core as it were of Begin.

And Architect is a framework for building serverless apps.

And there's a bunch of these out there, so the first kind of question usually is, "Why would you have another framework for serverless apps? We've got Terraform. We have Serverless.com."

And the reason is because we needed to build something that was going to have really good latency characteristics for building a bot.

The first version of Begin was actually a Slack bot.

And you can't have a bot that's got a cold start.

And unfortunately the early versions of serverless frameworks out there did what everyone does, and people still do this today.

They'll take a function, and you'll put an express web server in it.

And that works. And it's totally OK to do that.

I don't want to dissuade anyone from trying it out because it's fun to do.

But as your app grows, your function will get larger because you're going to add more code to it.

And as you're adding more and more code to it, it's going to cold start slower.

And so you want to break that up into a bunch of small functions, and most of these frameworks don't really guide you down this road.

And so this is one reason that Architect's a lot different from other projects out there, in that we guide you into a path where you're splitting up your app into constituent single-responsibility principal functions that are very small.

And the first sort of inclination to this is, "Oh no, now you're going to have lots of functions."

Your Rails app has lots of functions.

It just doesn't have any isolation between them.

So this is the only major difference, that you're isolating these things into their own little containers.

And then when they go to cold start, there's no penalty because they're loading less stuff.

So we kicked off Architect, I think we open sourced it in 2017, and it's been under very active development ever since.

We're now doing something like an average of four or five pull requests from external contributors a week.

We had 80,000 downloads last year.

And as a measure of the year prior, in 2019 we had 10,000 downloads.

And so there's a real acceleration towards serverless.

People are looking for ways to do it that are frictionless and that have really good latency characteristics, and that's kind of our sweet spot.

Brian Douglas: OK. And speaking of sweet spots, tell us about Begin and what that is.

Brian LeRoux: Yeah. So this is always fun.

When you've got an open core, there's like a, "What's the relationship between the open thing and the commercial thing?"

So Begin.com deploys Architect applications.

And the commercial entity that is Begin.com is set up to make this whole thing very frictionless.

One of the main things I learned with Architect, it's front end developers are rightfully terrified of Amazon.

They look at that AWS console, and they think, "Whoa, what am I looking at? Where is my app, and how do I make sure that it doesn't blow my credit card out of the water?"

And so that intimidation level is something that we sort of strived to solve with Begin.

We sign in with GitHub. You click one button.

You'll have an app deployed on Amazon in roughly 30 seconds or less.

And that's not an exaggeration. We timed this.

Much of our deploys usually net in around seven to 13 seconds. My goal is to get that to zero seconds.

And this is not because Begin is super special.

This is all downstream of scaling capability of AWS, but all that complexity of getting started is kind of locked away from a lot of developers.

So Begin just makes this frictionless and lets you get started really quick.

Brian Douglas: OK. What is the process of getting started?

I mean, I've done this myself, but for the sake of the listener, how would they sort of begin with Begin?

Brian LeRoux: Yeah.

And this is something I think we are going to always have to make easier.

Right now, you sign in with GitHub, and you can select a starter template app, and you're off to the races.

We're looking at making this a more local development workflow friendly situation.

You can use all of our stuff locally today.

But to get started, it's very similar to Heroku.

You sign in with your GitHub, and then you generate a repo, or you'll hook us up to an existing repo, and then we just start deploying every time you commit after that.

So, it's fairly frictionless, but my ideal would be it's completely frictionless, so like there is no sign in step, and then there's just magic, and you deploy.

And we'll get there.

It's an interesting challenge because you want to have the CI/CD, and you want to have the GitHub integration.

You want to put people where they're comfortable in their working.

Really when you're a developer, it's all about feedback loops. It's all about having like the shortest amount of feedback. You don't want to have to wait for a deploy to find out you had a bug. You want to find that out on your local machine to fix it before you deploy.

And staging environments and fast branch deploys kind of help with this, but you really need an amazing, kick ass local dev experience, and that's another thing that we get out of Architect and the open core and something that we're striving to make easier with Begin.

But right now, pretty much, if you've got a GitHub account, you should be 30 seconds away from deploying on Amazon.

Brian Douglas: OK. Excellent.

I love the seconds in deploying and that your goal to get down to zero.

It's one thing that, when I worked at Netlify, that I sort of took pride in that I was able to stand on stage or write a blog post.

And from the moment you figure out Netlify existed, like you're only about 30 seconds from having a site actually in production.

I love that strategy for adoption.

And it sounds like you're loving that too as well.

Brian LeRoux: Yeah. And I mean Netlify really-- They made this mainstream in so many ways, and we look up to what they've done and a lot of the work they've done especially for developer experience.

It's great, and we just want to bring that to the whole stack and have that for like everything that you do with AWS infra in particular.

I can remember when GitHub first launched Jekyll support on GitHub pages.

And this was a big deal back then because back then, if I wanted to stand something up on the internet, it was a real rigmarole .

You had to find your DNS.

You had to likely get signed up at Heroku, but maybe it was Linode.

You had to set these servers up and reverse proxies.

And Tom Preston-Werner and crew there were just like, "No. You're deploying a static site. Just put that up there and let that be the thing," and then Netlify really took that and ran with it.

The question I have now for the JAMstack, and this is more of like a heady kind of philosophical question.

We know that deploying stack assets is faster.

And we know that having it pre-rendered means you don't have to do any work on your server to get that stuff over, and that's great, and it works.

There's obviously trade-offs along the way.

You have to wait for build steps.

If you have a huge app, it's going to take longer to get it up there, and you'll be waiting for it to deploy, but generally these trade-offs are pretty good, and they're fairly manageable if you use a service like Netlify.

At some point serverless compute, in particular Lambda, is going to drop to zero cold start, and it's not an if. It's a when.

And right now, our cold starts are around 50 milliseconds 5-0 milliseconds, so not something humans can perceive.

The reason we did all this static asset Jekyll stuff was because we didn't want to wait for servers to do things.

We don't have to wait for servers anymore.

So the challenge for the future of the JAMstack will be, "Do we need to pre-render? Should this be static?"

And I think we're starting to see people ask that question in the framework world.

You've got Redwood. You've got Remix. You've got Next. You've got Blitz.

I don't know. There's another one every week.

SvelteKit is another one that's like kind of seeing this, and they're hybridizing.

They're moving beyond just static, and they're starting to use a dynamic trusted process for server rendered as well.

And I think this is where it all evolves, but I'm not sure.

And yeah, it's a good time because we're at the bleeding edge, and it's Wild West.

Brian Douglas: Yeah.

You even see folks like Gatsby, who helped champion things like the JAMstack and the statically rendered assets and build on-time building.

But even they're experimenting with sort of you can build portions of the app.

So if you need something statically built like your landing page, that gets built, but also experimenting.

And also I think Next has kind of--

They've sort of led the charge in the JAMstack world of having that sort of hybrid model.

I think Redwood and Blitz are sort of really running with it and sort of pushing it to the boundaries of what it means.

I've seen the evolution of the JAMstack. Like JAMstack.org, it's updated.

It's more than static. You might have something that's dynamically rendered.

So yeah, that's some pretty good insight.

Brian LeRoux: It is. There's nothing in that manifesto that said it had to be pre-rendered.

Brian Douglas: No. It just happened to be a feature.

Brian LeRoux: And Netlify gets this. They added functions.

And sort of from my perspective is what happens when the function model is predominant, and there's no performance penalty, and they just run instantly, and they go away instantly and statelessly?

What does that enable, and how do we take best advantage of that?

I mean, these things are, they are so cheap.

So like one million Lambda invocations is free.

The next million is something like 10 cents.

So you could be pumping literal millions of requests to your Lambda function and still not pay a buck.

And that's a whole different ball game in every way possible.

So we can now-- Yeah sure , you can serve as static site.

You can do a workaround for your dynamic routes.

You could just put your whole site in one Lambda function and probably serve it just fine and have extremely cost effective trade-offs for that.

And that's a wildly radical idea right now, but I expect over the years that will look pretty boring.

Brian Douglas: Is Begin AWS-only?

Brian LeRoux: Yeah. We are, and that was very deliberate.

So you know my PhoneGap history. I did that whole thing.

When I started working on PhoneGap, it was all about BlackBerrys.

And iPhone was obviously going to be this big thing, and we all knew it.

But at the earliest moments, there was a still a ton of momentum and traction for Blackberry.

There was this new weird operating system called Android that looked promising.

If you were in Europe, and you didn't have a Nokia phone, you were a weirdo, so there was a whole set of operating systems for that.

And so in PhoneGaps world, I pursued it all, all simultaneously.

And I've seen other founders doing this with the cloud as well.

It was a mistake. We got lucky.

I put a lot of resources on BlackBerry for a lot of years, and I didn't have to do that.

I could've probably focused a ton of our attention just on iOS and Android, and it would've been just as successful if not more successful today, so I'm not going to make that mistake with cloud.

I know who iOS is. I don't know who BlackBerry is, so I'm just waiting to see what happens.

And these clouds will market themselves as capability equivalent, and they are not.

So, in particular, I'm very excited about Azure.

I think Azure has a shot at number two.

I don't think it is number two. I think that is to be determined.

They've got distribution with GitHub.

And they've got distribution with NPM.

They've got Visual Studio Code, so they have a lot going for them.

But on the ground for their infrastructure as code solution, they've got a thing called ARM, Azure Resource Manager.

It isn't anywhere near where CloudFormation is, so I can't create the same kind of deterministic, fast builds that I can on AWS, and that's kind of table stakes for me.

I expect them to catch up eventually.

And the other aspect to this is the way the function execution model works is different across clouds.

Amazon has a thing called FireCracker, which is as cool as it sounds.

It's like this mini virtual machine orchestrator thing.

You don't have to worry about it.

The TLDR of it is it's a stripped down operating system, and it's really, really fast.

All the other clouds use a variant of Kubernetes or something like it to boot their functions' primitives, which is a nice way of saying they're slower, and in our industry speed is everything.

Brian Douglas: Yeah.

Brian LeRoux: You can't have two or three second cold starts.

It's fine for an enterprise back office kind of app.

But for a front end facing, user facing thing, you just can't have these kind of cold starts though.

I'm anticipating eventually Azure fixes these problems, and I'll look at being portable to them.

But in the meantime, Alibaba might come up and eat their lunch.

Brian Douglas: Yeah, that's true.

Brian LeRoux: Instead of trying to like spray and pray and do all these clouds, I'd rather just be amazing on Amazon because I know they're going to be around a long time.

Brian Douglas: Yeah.

And the thing that I bank on tools like Begin and all these other interfaces between the cloud for myself is that I don't want to learn AWS Console.

Like I've learned it probably five times since I started developing.

And every time I go back a year later, I'm like, "I could probably figure this out."

Like I had to do some transcriptions.

They have a great transcription service, AWS Transcribe or something.

So if I wanted to take this podcast, transcribe it, like just go directly to the metal and get that stuff transcribed, but it's a horrible interface.

Brian LeRoux: It's unbelievable, isn't it?

And they change it too.

I have a panic attack like once every few weeks when they change that interface because I'm like, "Oh my god. Where did everything go? How do I find it again?"

Brian Douglas: And that's what I love about--

You mentioned Arc or Begin. I log in with my GitHub. Stuff works.

All I want to do is just ship my code.

I don't want to spend like a full week watching conference talks to make sure I'm up to speed.

Brian LeRoux: Yeah. And that's sort of the theory.

I think there's always going to be a need for things to move to a higher level.

And Amazon's such an interesting company.

They're not designed for a vertically integrated experience.

They are very designed around-- Like people say, "Oh, two-pizza teams," and like that's a good thing.

And it is a good thing, but it's interesting to see when that is applied at scale what happens.

Like they really do that.

And so all of these products are these little fiefdom teams that are independently organized around basically the principles of AWS's infrastructure, which is things have an interface, things have an SDK, things log, and then otherwise they might have CloudFormation support, and they might have full console support, but otherwise they just ship as fast as they can.

And in some cases, there're even teams competing with each other, like products within AWS that are very similar to each other, so it's hard to decrypt what's going on.

And people ask like, "Why are they doing that?" This is a land grab.

So the cloud is as big as any paradigm shift ever has been, and they're trying to get as much of that land as they can, so they're going wide right now instead of going super deep on a prescriptive sort of like, "Here's how you're supposed to build your app, and here's where you're going to put your data."

They're like, "Nah, here's five databases, and we have five more coming out next week. Use the one that makes sense for you."

And I imagine in the longer scope of time, Amazon's going to start addressing this.

You see this with other companies in other sectors in the past, where they go wide, and they'll go deep later.

I think that's what's going on, but cloud is very competitive.

There's Azure, Alibaba, GCP, AWS.

They're competing right now largely on these capabilities, so they're going to just keep adding more and more and get more and more complicated, which is great because then providers like us can say, "OK. Amazon's never going to tell you to not use it, EC2."

They're never going to say it. I'm going to say it right now.

You have no use case for EC2 at this point.

There is a very low probability you need to boot a VM, but you probably need to talk to node.

And if you need to do that, then a really great way of doing it is Lambda.

And if you need to do that really quickly, then Begin's a good solution for you.

Brian Douglas: Excellent. Yeah.

That's quite the concise pitch too as well.

And in my mind, if I can bump up my SimVer version and get access to the new Amazon stuff through Begin, that's the world I want to live in.

Brian LeRoux: Yeah. You want their superpowers.

You just don't want the origin story that it takes to get those superpowers.

It's like a horrible comic book villain moment where you've got to like succumb to the console.

Brian Douglas: Yeah. It's funny because I remember roughly three years ago, I was spending a lot of time learning Docker and Kubernetes and thinking that, "I have to go learn how the cloud works."

But now I'm at the point where I'm so far abstracted away from it.

Like I'm not buying Kubernetes books.

I'll go to KubeCon to find out the new providers, but I don't really need to know Kubernetes anymore.

I am banking on infra people to keep that stuff up and running.

Brian LeRoux: Yeah.

And it might not even be Kubernetes in the future for all we know.

There's just so many different ways to go about orchestrating these computer workloads that span past one computer basically.

As soon as you get to two computers, you're now scaling.

And as soon as you're scaling a distributed system, you've got all kinds of new problems.

And this is why I think this was the end game for the cloud the whole time.

Because why would I be thinking about my IP address ranges, if I'm just returning a string for a webpage.

That's a little bit over the top.

I shouldn't need to have to like deal with my ingress and egress IP rules.

It's a webpage. It's like, "Just let me serve the thing."

I think our industry goes through these vacillations of complexity and configurability.

And usually we reject it outright and move over to simpler, easier, more deterministic, higher level things.

I remember when Java was all the rage, and then this upstart, Ruby on Rails, had the audacity to ask, "What about developer happiness?"

And so many people were mad. People were literally mad.

They were like, "This Ruby thing, it'll never scale. We don't want that.

Developers, who cares if they're happy?"

And we know how that story worked out.

The developers became very happy, and they deployed tons of Rails stuff, and Ruby became a defacto for many of the dotcoms that we use every day today.

And Node was kind of an extension to that.

And the pendulums actually swinging back I think towards more rigor and more configuration and more formality.

Like we see TypeScript as a good example of that and its rise.

Brian Douglas: Yeah. And we're also seeing the pendulum-- even things like Rust now having its sort of day in the sunlight.

I mean, we have an M1 chip now thanks to Apple.

So now everybody's like, "M1," but only just this week we can now do home brew on M1 chips.

But anyway, that's besides the point.

Brian LeRoux: No, I was waiting for that too.

My hand's been hovering over the buy button for like two months now.

I'm just dying to get that.

Brian Douglas: Yeah. Thanks to GitHub, I get a new laptop in two weeks because I hit my three year anniversary, so it could not be better timing to figure out how this M1 works.

Brian LeRoux: Nice.

Are you going to go with an Air, or you going to wait for the-- because I heard they're going to do a Pro.

This is the rumor anyways.

Probably the day you order an Air, they'll come out with this amazing Pro.

That's what's going to happen.

Brian Douglas: Yeah.

I'm actually trying to hold out until the beefier version comes out, hopefully summer-ish time, because nothing's dying right now as far as machines.

With that being said, my wife's laptop literally just died.

Her six year old Touch Bar Mac just completely-

Brian LeRoux: I have never been mad about a computer, and that one did it.

That one was like-- They removed my MagSafe, which just made me so livid, but I was like, "OK, fine."

And then they ruined the keyboard, the like main interface. This is Apple.

Brian Douglas: Yeah. The amount of times that computer's fallen off the bed because the lack of MagSafe and just a toddler running through the bedroom and knocking the plug out the wall.

Brian LeRoux: Oh my god. See, that's a different kind of stress.

Brian Douglas: Yeah, the reverse of innovation.

But speaking of which, I want to ask real quick about Begin.com pricing.

How do you make money?

I think everybody's interested but want to know like, "Is this going to sustain itself?"

Brian LeRoux: Yeah, for sure.

And so the first thing to know is that we deploy Architect apps.

So anything that we deploy is deployed with CloudFormation, so you can leave at any time.

So if you build an app with us, and we aren't meeting your needs, then you can deploy directly to Amazon without me getting in the way.

So there shouldn't be any kind of fear of being locked into us and the startup runs out of funding or disappears.

We do charge. We have customers paying us real money and everything.

And it's currently gated behind a wait list. I guess I'm comfortable saying this.

We have about 1,000 apps per Amazon Org account, and we have about 1,000 of those.

And it's fine. They can't access each other.

They're all locked down with IAM.

But what can happen is you can get a noisy neighbor.

So you could have someone on the same Amazon account as you pumping a bunch of traffic, and you could get throttled as a result.

I've been calling this one internally the Wes Boss effect because Wes was on our free tier, and he was throttling it a few times, which is great.

That's what it's for, and that's why we want people out there kicking tires.

But if you manage to trigger the Wes Boss alarms, then we'll kindly invite you to join our paid tier where we'll give you your own Amazon account totally setup for you and totally isolated for you.

We're charging 25 bucks a month for that.

And then we have a wait list for this right now.

We have a pro plus tier coming where we'll deploy to anyone's Amazon account.

You just have to give us the creds, and we'll run Begin on your AWS for you.

So it's kind of like a cloud modern version of On-premises.

I'm trying to find a way to describe this.

Effectively the story is you've got existing resources in a database or something like that.

You have a reason to be on your own Amazon account, and you need to talk to that existing database or those existing resources.

So that's the use case.

And we'll deploy into your VPC if that's what you need us to do.

So it's like On-premises, but it's more like on your cloud, I guess.

We can ask the viewers to come up with a better term for this.

But yeah, this is all in the roadmap.

I hope to have us fully GAed before the summer this year.

The only reason we've got it behind a beta right now is that we've been trying to figure out how to scale it with the team size that we have.

And I think we've figured that out.

At this point, it's pretty self-serve and fairly on demand, and we're going to just completely automate that all the way.

Brian Douglas: Excellent. And how big is the team currently at Begin?

Brian LeRoux: We are five, so we are quite small.

It's myself, my co-founders, Ryan Block and Christopher Joseph.

And then we've got a couple of amazing devs, Paul Chin Jr.

And Sean Jose have been keeping the support deluge down to a reasonable amount of levels and helping us build out example apps.

Sean's been on mission lately for us-- I really appreciate it.

He's been working on trying to figure out how to write the documentation for every possible DNS registrar.

When we initially launched, we were like, "Yeah, it's great. Just use this with Route 53."

And like nobody wants to use Route 53.

Brian Douglas: No. I mean, unless you're going to build a service for it to interface between it. Yeah.

Brian LeRoux: Yeah. And I understand. And so we-- And every one of these registrars is totally different.

So we did some instructions for Cloudflare, and we did some for NameChief and DNSimple and One.com and the list is just going on and on and on, so we're-

Brian Douglas: Yeah, it's almost too big.

Brian LeRoux: Yeah.

I don't have a great answer for this because I want to automate it, but these things are very different from each other, and they all use the same terms but in different ways.

It's just an ugly, sticky documentation project.

Brian Douglas: Yeah.

It was actually one of my first features at Netlify was building-- Actually, it was my interview, basically, project was building the DNS dashboard.

So it was like my first time writing Go because I had to talk to their services, and then I built a React app to sort of deal with the handling of the form.

Brian LeRoux: That's a bit deep end for a first project.

Brian Douglas: It was. It really was, but they had a real good internal API.

I was also employee three.

There was no real structure to the interview process.

They just had people build features and contract them.

And if it worked out, it worked out.

If it didn't, at least you got to walk away with a little bit of money.

But it was a great experience.

And yeah, but also that was painful trying to-- because I used the same DNS I've been using since like I started buying domains in college, which is Hover.com by the way.

They don't sponsor this podcast, but we'll just throw them out there.

But yeah, I knew how to use that one, and that's how I tested it.

Then I found out really quickly people would just throw out a random DNS and be like, "Hey, it doesn't work with this one."

It was like, "OK."

Brian LeRoux: Yeah. It's so weird.

There are so many of these providers. They're all different.

They all use similar terms. And programming against it's very hard.

Even programming against Amazon's, which is quite stable at this point, is pretty hard.

DNS is very throw-the-dart, wait 20 minutes, see if it worked.

And then like ask a friend on the phone, "Hey, can you load this page?"

Brian Douglas: That's what I like about--

So, Netlify with Netlify Functions, one of the early prototypes for, and I know this because I was there, of their DNS panel, they built a Netlify Function to actually ping and let you know when your DNS is ready.

Brian LeRoux: See, that's a perfect use for functions. Yeah, I love that.

This is the fun thing about the whole Lambda thing is that you can give yourself permission to write an app that just does one little thing.

And you can deploy that one little thing and not worry about it, and it'll scale independently.

Yeah, that's cool. That's a good use case.

Brian Douglas: It was the C of Netlify.

It was a weekend project.

I think on a Thursday-- something like in the middle of the week, he's like, "I have this idea for a feature."

And then Monday, he's like, "OK. Can you put this in the UI?"

I was like, "OK."

Brian LeRoux: Yeah, that's awesome.

Brian Douglas: Yeah. But speaking of which, I wanted to ask one more question.

This has probably been the most organic question that answered all my questions that I had prepared.

I'm looking at the questions.

We answered pretty much everything I had prepared, except how did you get Begin.com?

Brian LeRoux: Right. Yeah. This is a fun question.

And this is a good one maybe for the users.

This was something I had to learn myself when we got this startup going.

So my co-founder, Ryan, gets full credit for running this process.

And maybe people can get some value out of this because I think a lot of people will assume you can't get a cool five-letter dotcom domain name, but anybody can do it. And it isn't all that hard, but you've got to come in with some basic rules. The first rule is you don't know what the domain will be until you find it.

So you've got to let go and put that intention out in the universe and be sort of yogic about it.

Be like, "OK, I want to get a dotcom, but I'm not going to be attached to what the actual letters of the dotcom are."

You then have to narrow your field and understand like there's a lot of words out there.

What is the word that you want for your dotcom, and how many letters does it have?

Because these things do cost more depending on how many letters there are.

The next thing you need to do after you've got your thing.

What we said was we wanted to have a positive verb that was five letters or less.

So we went to the dictionary, and we got all those words, and I think there was thousands of them.

We hired a domain broker to help us go through that list and start finding these people and contacting them and see if they wanted to do a deal that was within our budget, and we got to the letter B before we found someone.

The cost of these can be expensive.

They can go into six figures for sure, but you can do like a four or five figure deal for a dotcom that's really good.

Now, that's still a lot of money, but I will argue that it is worth it for your credibility and for the brand, and it also shows you've got some hustle and you can find that thing, so that gets you a way in the door.

When you're talking to investors later, they're going to know you're really serious about this thing.

The person we found for Begin was actually not as price sensitive as they wanted to be involved in a startup, and so we were able to negotiate a deal in equity.

And I think another startup out there listening to this right now can take these lessons and hopefully use them.

You've just got to not care what your name's going to be until you find it.

That's really the trick.

And I think this process by the way also took us I want to say like six months.

So it was not very easy.

We had to work on like a codename and stealth mode for a while before we actually got the thing like buttoned up.

And even at first I was like, "I don't know. Is this good?"

Because we'd looked at so many domains, I wasn't even sure. And then, "Yeah, it's good. It's five letters, and it's positive. It starts early in the alphabet by accident."

Brian Douglas: Yeah. I asked the question because I thought it was way more intentional than that because Begin, it feels like it fits the product so well.

Brian LeRoux: Well, I'm not a fatalist, but there is some serendipity in all this, and it did work out.

It does suit it very well.

I guess you could grab any five-letter positive verb and work your way down a list and find something, or just add "lify" at the end, and you'll be able to make that work.

I've been buying vanity domains like they're going out of style ever since we started getting these weird TLDs.

I've got like Coding.pizza or something.

Brian Douglas: Well, I will have to admit, I do have OpenSauce.pizza, so-

Brian LeRoux: Oh! See, that's a good one.

Brian Douglas: Which is my side project.

Brian LeRoux: That's a good one.

Brian Douglas: Yeah. It was completely-- And I've talked about it on the podcast quite a few times.

So folks, OpenSauce.pizza, check it out.

But it was basically a side project to learn the GraphQL API at GitHub, and I was just looking.

I think the Pizza TLD came out.

And I was like, "Oh, I need to think of something to go with pizza."

Brian LeRoux: That's exactly what I did too.

I was like, "I don't have a project, but this TLD is too good to not use." That's so funny.

Brian Douglas: Yeah. I have quite a few.

I mean, a lot of them have my name in it BDougieDev and BDougieLive.

But I do have a couple other ones like ImBreadable.club.

Brian LeRoux: But then every year, you're probably like me.

You get the renewal notice, and you're like, "This is waste of money," and then you pay it.

Brian Douglas: I actually did drop ImBreadable.

If anyone wants ImBreadable.club, I just dropped it because I'm just like--

A couple years into this, I'm like, "There's nothing happening here."

Brian LeRoux: Yeah.

There needs to be a developer tool that lets us exercise the feeling of buying a domain spontaneously but not actually spending the money on it, maybe like an escrow or something.

Brian Douglas: I need AI to basically just based on the domain name generate a website, and I'll just stand up there with a bunch of stock photos, and then I'll feel good about myself because there's something pointed at it.

Brian LeRoux: You'll probably close a seed round in like 10 minutes.

Brian Douglas: OK. I've got some work to do.

So let's go ahead and wrap up this podcast.

I appreciate you chatting about Begin.

I love the story. I love the product.

I didn't even mention, I leverage it for one of my Twitch bots.

It's called GitTwitch. Yeah, GitTwitch is basically connecting GitHub and Twitch together.

So that way whenever you start a repo while I'm live on Twitch, something happens.

Brian LeRoux: Dope. That's a great use case.

That's awesome. I love it.

Brian Douglas: Yeah. It's not in production right now because I had to clean up a bunch of the code.

And so I cleaned it up, so I need to deploy it again.

Actually, it might be deploying.

I haven't even logged into Begin since the first time I clicked it, so it could be still running.

Brian LeRoux: Any commits would have deployed.

Brian Douglas: Yeah. Turns out I'm on a club with 1,000 other folks.

Brian LeRoux: Exactly.

Brian Douglas: But moving on. Let's actually move into Jam Picks.

These are projects that we're jamming on.

It doesn't have to be projects.

It doesn't have to be code related. It could be food related.

We've definitely had the gambit of all different types of recommendations.

But as you're thinking, I'm going to mention my picks because it got mentioned in passing.

So, just last week, me and Anthony Campolo--

Anthony was on this podcast quite a few episodes ago, and he talked about RedwoodJS.

He, basically as a bootcamp student, was doing dev Rail for Redwood on his spare time for fun and then like wrote a bunch of tutorials and docs and stuff for them as a bootcamp student.

Anyway, he just got his new job and did not even graduate the bootcamp.

I'm not sure how that works, but he's working full-time now.

Brian LeRoux: That's great.

Brian Douglas: But he basically walked me through how to build a Redwood site.

So I mentioned OpenSauce.pizza.

I'm actually working on this sort of recommendation engine for contributions to projects.

Think of like Yelp but for open source, which is I like I just figured out the pitch on Twitch, which I did not mean to rap, but I just did.

But we built the site in about 30 minutes on stream live in front of people.

I went back and did another livestream, and I connected a database, which probably should have only took five minutes, but it took me a little longer as I was learning Postgres and error-driven development.

But I'm using another episode that we had with SuperBase.

SuperBase was actually-- They're in their beta right now and finished YC.

They started 2020. Beginning of 2020, the founders hung out in Singapore, and then COVID hit, so they just basically did their entire YC batch in Singapore the entire time remotely.

Brian LeRoux: That's great.

Brian Douglas: Which is an amazing story. Hats off to them.

They raised a seed round after YC. So I connected SuperBase.

I'm loving the interaction and authentication, stuff like that.

So if you want to look-- Talk about code names, it's actually in my org as OpenSauce/FlavorFlav.

That's the current code name because I haven't thought of a name yet, and I had to think of it on the fly, so FlavorFlav is the repo.

Brian LeRoux: Yeah, don't change that. That's good.

Brian Douglas: Yeah. I might even check out this whole brokerage thing.

Well, I need to actually do the AI thing first. I'll get funded on that first.

I think that's going to be a billion dollar idea.

Brian LeRoux: Oh easy.

Brian Douglas: But yeah, I'm loving that stack.

And you'd also asked off stream about Redwood.

Tom Preston-Werner, he actually started Hammer JS, and then it was like code name.

Eventually, they renamed it to Redwood.

It's basically Rails but in Node and JavaScript and React.

Brian LeRoux: Love it.

Brian Douglas: Yeah, it's a beautiful merriment of all these sort of things that I learned my entire career with all scaffolding, which is what I love thanks to like PRISMA and all this other stuff.

Brian LeRoux: The React community so badly needs to have some strong opinionated help.

And there's nothing wrong with that.

And I think it's great to see that there's more of this happening now, and we're getting a little bit further along the conventions versus the configurations.

Somebody else should write that webpack config.

Ideally, no one should have to write a webpack config, but-

Brian Douglas: Yeah. Going back--

Well, we just had a whole conversation about like I learn webpack, and I'm actually--

I spent way too much time getting very good at it, and I haven't touched a webpack config in like probably a year and a half.

Stuff just works. All these new tools, Next.js and everything like that, it's just--

You start a project, and you just sort of set it and forget it, sort of.

Brian LeRoux: Yeah, and that's really how it should be, especially for a module system.

I mean, come on. JavaScript, everybody's had modules for so long.

And in true JavaScript fashion, we now have like three of them. So it's like--

Brian Douglas: Excellent.

I did have one more pick, which I recently picked up a copper pan, which I don't know if this is like a US thing or something, but it's like the late night television infomercial type skillets where it's non-stick, but it's not Teflon based.

My in-laws had one a couple years ago, and I loved it.

But I've been hardcore stainless steel.

I use what's in the kitchen, like what's in actual kitchens, like restaurants.

I've always been really into cooking and using proper equipment.

But this copper pan, $14 at a Walmart near you, it's actually pretty legit.

Brian LeRoux: Really?

Brian Douglas: I'm actually really loving it.

Brian LeRoux: Yeah. Better heat distribution?

Brian Douglas: Yeah, whatever. Something like that.

Honestly, I didn't really watch the whole infomercial, but it's like as seen on TV.

But yeah, nothing sticks. I made like a General Tso type chicken in there, sauce and all.

It just slides right off the side of the pan, so I'm like-- I don't know.

I feel like I'm cheating a little bit, but I'm also really loving cooking with it.

So, copper, it sounds like the worst thing you could do, but I'm sold.

Brian LeRoux: Yeah, I've never tried that. I need to try that now.

My whole COVID adventure has culminated in me being able to now properly scramble eggs in a cast iron pan, which took roughly a year to get right.

Brian Douglas: It's low and slow. That's how you cook eggs.

Brian LeRoux: It is true.

Brian Douglas: And I'm a big cast iron fan as well. I don't know.

I just do a lot of, I've done a lot of cooking this year, no joke, every meal.

Brian LeRoux: Yeah, us too. I love the cooking.

I hate the dishes though, I've got to say. I'm over it.

I'm ready to go eat out again. So is it my turn? Do I get to do a pick?

Brian Douglas: Yeah. If you've got any picks, hook us up.

Brian LeRoux: I've been loving--

The audience has probably heard this a billion times already, but I'm going to be billion and one.

I've been loving Deno the last few months.

Well, I guess I kind of got on a little bit early the Deno train, but I was early to the Node thing too.

And it is becoming just a joy to work with.

So, Deno, for the people that don't know is a--

First of all, it might be pronounced Deno. It's a JavaScript runtime.

It's a play on the word node. It's from the original creators of Node, and it's kind of a do-over.

I'm sure they wouldn't like me characterizing it that way, but there's a lot of stuff that Node has that it can't get rid of because it would break millions of people's apps.

And so Deno is kind of asking the question, "Well, what if we got to start fresh? What would this look like?"

And it looks fresh, and it's very fast, and it's got just so many nice little features built in that you don't have to think about as much as you normally would.

So it comes with built-in testing, built-in linting, built in formatting.

Just added a command in Deno 1.7 that is blowing my mind where you can compile your app into a binary for any platform, and it will run just like it was compiled with like a C++ or Rust or whatever.

So you get to package things in a way that more compiled languages would.

The other thing I'm loving is it comes with built in TypeScript support, so you can write TypeScript, but you don't have to compile it.

It does all that for you, so you just get this sort of natural JavaScripty rigorous runtime that's very portable and has everything built in.

So if you haven't checked out Deno, and you're a front end dev, I highly recommend it.

I think you'll have a lot of fun.

Brian Douglas: Yeah, definitely. So I mentioned livestreaming.

That's something I picked up this year.

I actually did a little comparison test between Node/Deno, and then Myles Borins and a couple other Nodes folks created JS Time.

JS Time is definitely not-

Brian LeRoux: I saw that.

Brian Douglas: Yeah.

It's not production-ready, and there's a lot of missing features, but just doing a side by side comparison of--

I forgot what my test was. It was some trivial Node thing.

Actually, I think I did setTimeout.

I might have did setTimeout for like two milliseconds and then looked at it to see how long it took to respond.

And like with Node, it took like probably like four seconds to respond, probably longer than that.

But then with Deno it was like, take away the set Timeout, and it was like 25 milliseconds, which is kind of insane.

Brian LeRoux: Yeah. The cold start's fantastic.

And this is longterm, especially for the serverless community, is going to be a very big deal.

And Node probably can't get faster at this point.

Node's probably hit its local maximum, whereas Deno's already started from a faster place.

They've got some structural advantages, and they don't have to deal with the baggage of the past.

Brian Douglas: Is that what you were talking about earlier when you were saying it would probably get down to zero with the cold starts, if they switched runtimes?

Brian LeRoux: No.

Well, this is just the runtime's cold start.

I think at a certain point, Amazon's going to crack the nut of booting VMs, like the whole thing, not just the runtime but the thing running the runtime.

I think they're going to drop that to zero.

Right now, the overhead of booting a Firecracker container is somewhere around 40 milliseconds.

And then a Node or a Deno on a hot day, running at peak performance mode, might be able to cold start itself around the same amount of time, so you're still seeing a latency of around 80, 70 milliseconds.

I expect the Deno part to drop to zero, and I expect the operating system part from Amazon to drop to zero. It's just a matter of time.

Yeah. I don't know. You might have a use case where that matters.

I don't know who does, but like we have to get rid of that last 20 milliseconds is probably--

At massive, massive scale, huge workloads, maybe that's going to make a difference in your build.

I don't know. But we're fast approaching zero cost abstraction cloud computing.

Brian Douglas: Yeah. Well, I'm looking forward to it, being the consumer of all this win.

And also I'm looking forward to continue to consuming Begin and seeing what you all have in store as well.

Brian LeRoux: Thanks so much, Brian.

Brian Douglas: So, listeners, definitely check out Begin.com.

They put a lot of work into getting that URL, so don't forget it.

And also keep spreading the jam.