We're talking AWS on Discord! Join us

Episode 17

Brian LeRoux: The Case for a Local Dev Experience in Serverless, Architect and Begin.com, and Making Sense of the Web Today

Brian joins Adam to discuss his belief that we shouldn't forego a local dev experience when building cloud-native apps, his experiences building frameworks and products like arc.codes and Begin.com, and an honest evaluation of where we're at with the web in 2021.

About Brian

Brian LeRoux is the cofounder and CTO of continuous delivery vehicle Begin.com and core maintainer of the serverless framework OpenJS Architect. Brian helped create the terse .arc manifest format that unlocks the power of building severlessly with primitives instead of configuration frameworks while still enjoying the determinism and interoperability of standard AWS CloudFormation.

From 2017 to present Brian spoke at many serverless community events as they sprang up all over the globe: Vancouver, Toronto, Seattle, San Francisco, Chicago, New York, Sydney, Melbourne, Brisbane, and Austin (to name a few!). Brian is also very online. You can find him blogging often at blog.begin.com and always up for the friendly fire that is twitter dot com.

Brian is an advocate for the open web and awkwardly expresses his love of JavaScript at wtfjs.com which was last updated approximately one billion years ago. He also has a non-breaking space tattoo. Brian believes the future is open source, serverless, and will be written by hackers like you.

You can find him online on Twitter, LinkedIn, and GitHub.

Transcript

Adam Elmore: Hey everyone. Welcome to AWS FM, a live audio show with guests from around the AWS community. I'm your host, Adam Elmore. And today I'm joined by Brian Leroux. Hi Brian.

Brian Leroux: Hi, It's so great to be here for the first time.

Adam Elmore: Love it so much. So thank you, Brian, for joining. For some context, we just did kind of a false start. We had to redo the intro here just because of some audio issues. So we've got that sorted out. Brian, I'm so glad you're here. I'll start this episode, just like I've started every other episode, sort of giving your story, just your background for anyone that maybe doesn't know who you are.

Brian Leroux: Yeah, sure. I'm a web developer. I've been doing this stuff for quite some time, big fan of what the web has been able to do for the world and myself and my career. I've been an advocate for standards and open web dev for a really long time. In a previous life, I used to work on embedding web views in a project that became known as PhoneGap and then later Cordova. That led me down the path for build into the cloud and the company I was at, we got acquired by Adobe a long, long time ago, and we had a cloud service and we went through the whole cloud story. We had a beer fridge full of Mac Minis, which we then moved into a data center, which we then eventually turned into virtual machines. And I didn't get the chance to migrate into Kubernetes because I would've probably not been very happy doing that.

Brian Leroux: Then around 2015, I just happened to be in an AWS summit when they announced API gateway. And for me, that was a very profound moment. I saw Lambda function get invoked over HTTP. And I was like, oh, that's how this will all work. And it completely changed my worldview. And that was in 2015. I thought I was late to the party because Amazon, Lambda had been around at that point for over a year. So it was kind of old news, but invoking it over HTTP was kind of a new thing. And I've been basically chasing that dream ever since and trying to move towards more functional web apps, apps that are composed of cloud functions as opposed to the balance seek web servers or Mac Minis and beer fridges.

Adam Elmore: Yeah. And I want to get into of your views of the web and where we're at today and all of that. But I think starting out, I want to of talk about what you're working on now. So you've got Architect and Begin. Could you just tell that whole story for us?

Brian Leroux: Yeah. So Architect is an open source deployment framework for AWS serverless services in particular, it's built on top of AWS SAM. So you know, anything you can do with SAM, you can do with Architect, Architect extends SAM in what's been accused of being opinionated direction. I don't think it's opinionated so much as it's just got good defaults and you probably would agree with most of those defaults. We talked about them objectively. One of the big defaults that tends to raise eyebrows, we believe you should have a full local development experience. When you're writing codes, you have faster feedback loops. This doesn't necessarily mean you have to use it, or you're allowed to deploy it stack and test lower if you want to, but we give you the option to do that locally and Begin.com is a hosted platform for deploying architect apps, building apps, composed, largely of cloud functions. And it's a little more opinionated and a little slicker than just dealing with raw cloud formation.

Adam Elmore: Yeah. So random question about Begin. How much was that domain Begin.com? That's a big one.

Brian Leroux: I don't know if it's important or relevant per se.

Adam Elmore: That's the curiosity of mind. It's really not.

Brian Leroux: I think the important thing to know is that it's both possible to get a five letter.com and it can be affordable. It wasn't millions of dollars. It was definitely not hundreds of dollars either. It was a process that my co-founder largely ran using domain brokers and we didn't have a strong attachment to the outcome of the domain itself. We wanted to find a five letter positive verb. So we got out the dictionary and we got to the letter B before we found one we could afford.

Adam Elmore: That's awesome.

Brian Leroux: Yeah. And that's basically the process and Stripe, took them way longer. They had to get all the way down to S.

Adam Elmore: Oh geez. So you're the co-founder of Begin and did Architect sort of come out of creating Begin? What is the timeline there?

Brian Leroux: Yeah, it's confusing and blurry. We initially created Architect because we needed to build a bot for slack. So the original version of Begin was going to be a chat bot. At that time, serverless framework was still called Jaws and it was not really tuned for what we were trying to do. We wanted to have really fast, small cloud functions over stateless. At that time, a lot of people were bundling fat Lambdas. Like they were putting express and stuff inside of a Lambda function. The cold starts...

Adam Elmore: [inaudible 00:05:26] right?

Brian Leroux: Yeah. Cold starts were brutal. You can't have a bot respond in two or three seconds, which the cold start used to be. So we ended up having to take this our own way and we basically kind of narrowed in on building tons of tiny, small stateless, single responsibility functions. That was our stick with Architect. And so we wanted to have a lot of low latency, both in deployment, but also in cold start. And that was the way to solve that. We correlated a cold start back to payload size. And so this was one of our early opinions that you want to have lots of small stateless, independent single responsibility functions that can be secured to least privilege. That's now a best practice. So I don't know if it's his necessarily an opinion as much as how you just want to do that.

Brian Leroux: So we built it to build bots and then it really didn't make sense for us to control our own a framework. We weren't trying to monetize that at that time. So we donated it to OpenJS Foundation, which is the same place as node.js is at and put it in our open governance model. And yeah, it's been open since 2017. It's been stable for many years. We really value backwards compatibility. So apps built literally four years ago, still run today and we always build a forward vibration path for our stuff, which I think is possibly unique in the deployment framework space. And it's just SAM at the end of the day. So you can eject, you don't have to use our stuff. If you don't want to, you can literally run one command and get the cloud formation out and be on your way.

Adam Elmore: So you talked about the local testing. That's definitely something I want, I wanted to dig in a little bit or local dev experience. I know every time I say this, I think I botch it and I misrepresent.

Brian Leroux: Oh, I'm sorry.

Adam Elmore: Yeah. So I, you've been on record saying if you're testing, load testing, whatever, you're doing that in the cloud, obviously, but you really lobby with Architect for this local dev experience. And I have to say, this is episode 17 of this show. I've had a lot of guests on the show that are really strongly the other way, or at least, whether they're strongly or not, they sort of lobby for test everything in the cloud. Just deploy things as you make changes.

Brian Leroux: I'm not against testing in the cloud. So it's just level set back.

Adam Elmore: Yeah. I keep saying testing, it's really about the local dev experience.

Brian Leroux: And I do hear people say you shouldn't do local dev. The people that say that don't have the capability. So that doesn't really make sense. Right. If you do have the capability, then you would use it.

Adam Elmore: What about the people who don't have, they're not lobbying on behalf of a framework. So being key was on the show and I'm not smart enough to have this debate with you. So I asked Ben, what is the counter argument, to someone like Brian, who's coming on the show. And he wanted me to pose this question, which is sort of, if cloud development could get as fast as local development, are there still benefits to that local emulation piece?

Brian Leroux: Yeah. I don't think that's an unreasonable thing to postulate. I think there's still benefits to having a local setup where Ben is correct is your local setup is not going to be identical to your deployed setup. And there's a lot of room for bugs in between those two places. I don't think you should be testing, IM compliance locally because you can't, you're not going to reinvent those semantics locally, but I do think you could test payloads, so a good example is API gateways request and response format. Those have changed once in five years. So I've got some unit tests for those. And I did have to write new ones when the new changes came, but that's like once in five years, so now I've got a consistent stable interface to run local testing games, which is really helpful for me to not have to wait for a full cloud formation deploy or even just a fast dirty deploy or I can't remember what we're calling them these days, direct or stink or something.

Adam Elmore: Hot flop.

Brian Leroux: Hot flopping. Yes. So, that's nice. And this is all about, you want to minimize feedback loop, but you also want to minimize surface area for bugs. And so if there's a Delta between your local environment and the deployed environment, then that's a huge opportunity for problems and those problems could be severe. So there's no excuse for not testing in production as it were, especially if we have these deterministic deployments where we've got the same stack as production deployed to a staging environment, then there's no reason why you can't test that. What I don't think you should do though, is test things like AWS limits and quotas. I think you can trust them to be telling you the truth there, you should be testing your workloads and make sure your workloads assumptions are correct.

Brian Leroux: And the bounds and the quotas and limits there are what you would expect. And there will be bugs. There'll be things you don't expect and things will happen that you're not ready for. We ran out of DNS records in route 53. I didn't even know you could do that, but you only get 10,000 record sets, it turns out.

Adam Elmore: Wow. Didn't know that.

Brian Leroux: Yeah. Yeah. And so this is the kind of thing you find out by testing and staging or in production, but there's a huge class of things you can test locally. And the other thing that I want to highlight here, the movement to cloud and managed services is all about re imagining, how we used to work and getting rid of all those limitations in the past. But we can't get rid of those limitations in the past by saying that a lot of those solutions didn't matter.

Brian Leroux: And so saying that local testing didn't matter, doesn't make rails serve any less valid to a rails developer. And now if I'm a rails developer and you're telling me I don't need local testing, well, you're kind of telling me I don't need the cloud. And that's the wrong way to go about this. We want to bring those rails developers over to this kind of thinking, and we're not going to do it by hand waving. And I'll add one other piece. This plays out all the time. So when mobile happened in the early days, local emulation was considered a bad practice and something you would never do. People don't think that way anymore. The emulator is pretty good. It doesn't mean you don't still test on device. You absolutely do, but you can get a great deal of work done locally in an emulator without having to own an Apple Watch and iPad and three different forward factors or whatever.

Brian Leroux: And that's what this is about. So I don't agree with the assertion that it's impossible. I think if you're a trillion dollar company, all kinds of things are possible and local stack is proven. You can emulate the whole thing and that's a tiny start. So I think it's all possible. I think AWS is a very serious cloud provider that does provide great guarantees on payloads. They don't change their APIs willy nilly. So you've got a really great surface to test against. And if you choose to use that, awesome. And if you don't want to, that's awesome too. Don't do it. It's not an either, or it's an and, also. And from a development velocity standpoint, sometimes I don't want to deploy. I'm trying to figure something out, I don't really know where all the pieces are going to fit yet and I'm still shaping the data the way I want to shape it. I need some iterations locally before I'm going to commit to that stack. And that's what that's all about.

Adam Elmore: And I guess is your position sort of, you wish Amazon would incorporate a local dev experience first class, first party or?

Brian Leroux: Well, they will, right? So there's no version of this story where Amazon stops end features or stops getting better. Every version of this story, as we move forward through time, tech is industrializing in it's nature, right? It's deflationary in it's nature. It will get better. It will get smaller, faster, cheaper, and that will eventually include local emulation as it already does. SAM has a local development experience. It's kind of crummy. So we have our own on top of that, Dynamo DB's got a local dev experience. Most Dynamo DB users use it too. So I only expect those capabilities to improve in time. And a lot of this wingeing it's just that. And we heard the same wingeing around mobile. And again, it's not that it's bad or good. Like if you don't like it, then don't do it. Just be slow.

Brian Leroux: And I'll be over here being fast. And that's totally OK. You can do that. That's your option. You could use Architect completely in the cloud all day long and you don't have to run locally. You'll probably want to because you can. And that's great. So I don't know. That's my stance on that.

Adam Elmore: Yeah. I think I'm probably not capable of tough questions, but if I have a tough question, it's as you're speaking and you're going through this whole case, I think the other side of the argument saying, we just need to make the cloud faster, make deploys faster...

Brian Leroux: That too. Yeah. I want it all.

Adam Elmore: And I guess my hard question, my tough question. If I'm, again, if I'm capable of it, I'm like a type nine Enneagram. I'm a middle child. I don't do conflict. So you'll find that out really quick. If you just like push on me a little bit, I'll just fall back down like a puppy dog.

Brian Leroux: You're running the podcast.

Adam Elmore: Yeah, yeah, yeah. Okay. So here's my tough question. I guess if things did move, you say people don't have this support for local emulation because they haven't built it, they don't have that support. They can't really be behind it. Is the inverse also true if they made cloud development instant, just like a local dev environment, is it possible that you're invested in that local dev experience with Architect and that colors your opinion? Would you change your position if there were no performance difference, if you could just have all of that in the cloud, just as fast?

Brian Leroux: Yeah. If I could always have it always on and always accessible and always fast. Sure, totally.

Adam Elmore: Oh, that's a good point. I guess the always on thing, if you don't have connectivity, you can't really do anything without local dev.

Brian Leroux: If you don't have connectivity take the day, come on. But maybe if you don't have that luxury, or you're a startup founder and you're on the road and you're trying to get something done in between hops between cities or whatever. But yeah, I think this is a very easy prediction. I think Amazon will continue to get faster and better and I will use it. And if it hits a point where I don't have to maintain that code, then I am all in. I've been lobbying Amazon to take over local dev for years. I don't want to write that code, but the good news is we're not writing it every six weeks. This isn't the React ecosystem. This is the cloud. It's very stable. Our code for emulation does not change very much.

Adam Elmore: You said React. And I kind of wanted to get into this anyway. So I think now's a good time.

Brian Leroux: I just, I can't avoid it. I have to take a shot.

Adam Elmore: Because I've seen your public stance toward where the web is today. And I'd like to hear you elaborate in a voice medium, just your thoughts on the current state of things, whether that's React and the sort of heavy JS stuff used where maybe it shouldn't be used. Just all of that. Where do you think we are today?

Brian Leroux: Yeah. Well, I think we're in the middle of a Cambrian explosion of new capabilities and new vibes and new frameworks. And I think there's also simultaneously a re-discovery going on of traditional best practice techniques around building applications. And we're not seeing that necessarily spurred by any given technology, but we know that a lot of the single page apps that are out there today are creating poor experiences. They are largely reliant on client JavaScript for business logic and that business logic doesn't necessarily always load on every device.

Brian Leroux: And this isn't really in line with the principles of the web and how we got here. The idea is that this information and knowledge is to be shared and accessible by everybody. And that necessitates taking a progressive enhancement approach, which I'm a big advocate of not just for accessibility reasons. Also because sometimes JavaScript fails that should comes no surprise to any JavaScript developer, it fails.

Brian Leroux: And what happens? You get a big white blank screen full of skeleton spinners and loaders. That's terrible, right. And not necessary. We can load a national markup and then we can progressively enhance it. And that's a good technique, I think, React and View and Svelte and all these frameworks have done a lot of good. They bring a lot of people into the party, but the thing that I want people to be aware of is that the journey doesn't stop there. I've been fighting and building websites since the nineties, and it's only gotten better and I've only continued to learn. There wasn't a moment where I was like, Ooh, good, now I know everything. And I think we've seen the themes of where all this JavaScript on the client works and where it doesn't. And I don't think there's like necessarily a perfect approach, but I also don't think that the perfect approach is to install a gigabyte of dependencies to render a hello world stream on a static webpage.

Brian Leroux: That's ridiculous. And I like to be use case driven. And if the use case calls for a heavy, complex UI, I will challenge that that is a bad business choice to start with. Not, we need to build a heavy, complex UI, like no user experience designers can be like, that's the goal. The goal is to have a simple, accessible experience to the widest body possible almost in all cases and working backwards from that customers is the thing. And yes, I love React and I know it's very popular. And so sometimes I think I get under people's skin when I'm a bit annoyed by that fact, because popular doesn't matter. It's a logical fallacy to apply popularity to an argument. Your selection criteria is going to need to be a little bit more rigorous and it's going to be use case dependent, something being popular doesn't mean anything really it's an irrelevant consideration.

Brian Leroux: What are you trying to achieve is really the question. Now, some people would argue, oh, but if it's popular, there's more resources. And sure. There's lots of good documentation out there about whatever flavor of front end framework you're choosing. And I think everyone will agree most of it's out of date or wrong. And the platform, interestingly, the web platform is very stable. One of the attributes of JavaScript is that it's backwards compatible. If it wasn't your web browser, wouldn't be able to load anything and it goes continuous to be forwards compatible. So you don't want to lose that. That stability is pretty awesome. Imagine writing code, you don't have to revisit it. And this just hasn't been the case for the front end web development world. And that's something we need to get away from because that's an easy win. We've got a backwards compatible programming environment.

Brian Leroux: Holy. We've never had that in the history of anything. And that's a wonderfully stable thing to build on. If we build right for that, then your investment compounds. You don't need to revisit that code you already wrote. You don't need to update and PM modules for God knows how long they're all in conflict with each other. You can just stay out of dependency hell and live in this forward compatible world. Is it easy? No, but neither is updating your web pack configuration every six months. And I would argue that your time is probably better spent additively compounding value than it is spinning your tires updating to the latest bundler.

Adam Elmore: Yeah. So I know I've been guilty and you've really helped me understand this better and see the other perspective and break out of some of that. I'm still an early web developer. I feel like I have a lot of experience in the cloud and doing things that don't touch web. I don't have a lot of experience as a web developer and I've gotten sucked into building out brochure, style websites, just all informational and doing it with Next JS or React or whatever. And thinking about leaving that and building out sites with just HTML or whatever, I want to get to that, whatever you should do, it's like these scary thoughts in my mind of like, oh, what will I do without... Then am I going to have to manage the web pack myself and the babel config?

Adam Elmore: And then I guess it's like, do I need those things? If it's just static information on site, I don't need it in the first place. Like I'm, I'm basically shipping React to the client to do a contact form when I could have just posted that using normal web stuff. So I guess what is the ideal for those types of sites, that use case where it's all information, it's just a static site. Is the best approach in 2021 sort of just use HTML CSS?

Brian Leroux: I mean, that's what I would do, but I don't think that's necessarily the best. If You're looking for a build step, for some reason, I'm having difficulty even convincing myself of that argument, but I'll say this, there is a great ecosystem around Eleventy, and I know that static site generator in particular has a real high for things like progressive enhancement and HTML first. The other one that's gaining some steam that I'm really excited about is called Astro. Their whole vibe is down this road of reinventing an old things with new nicknames. So instead of saying progressive enhancement, we now say partial hydration, I'm sure there's people on Twitter just blowing up now that I said that, but whatever it's good. It's positive. And I'm here for it. I personally, for my time, I don't want to chase build steps or any of that so I'll just do the savage thing of writing HTML and JavaScript that's forwards compatible for all time. But by all means opt into some dependencies that force you to upgrade constantly.

Brian Leroux: I think that's at least a step in the right direction and it doesn't have to be an all or nothing thing. We've been really experimenting lately a lot with web components and that ecosystems incredibly invasive, I couldn't recommend anything there truly. But I do see a lot of potential there right now. And we see this happen repeatedly over time where, technology is both industrializing and deflationary. And so things get faster, smaller, cheaper with time. The web is no different. Back in the day we had to include like some obscene amount of JavaScript. I think it was like almost 80 K.

Brian Leroux: It used to make me really mad, called JQuery and I'm serious. People will remember this. I used to advocate against JQuery because it was too big for mobile phones in 2008. And they, they addressed that, it's faster now and that's great, but you don't really need JQuery anymore. And that's because the platform absorbs those capabilities and you can just use a query selector all and get like 80% of the way there. So components are the same thing. We now have native modules and native components. It's just a matter of time before using a third party, framework's going to look like using JQuery.

Adam Elmore: Yeah. Because that shifted at some point, I know some people like Tomaz was a guest on the show. He jokingly tries to keep JQuery around. But I think there was that shift where it kind of became out of Vogue. And you think that's where things are headed with this, using client side frameworks really heavily for use cases. Maybe they're not ideal. That's kind of where we're headed.

Brian Leroux: Yeah, for sure. We'll always be moving down this road where the platform will subsume user land and eventually you'll ask the question, wait a minute. Why am I updating this thing that's already built in? I don't really need dependency anymore. Dependencies are a blessing and a curse. It's like adopting kids, once you've got it, you got to take care of it and it's going to always be around. And they're going to discover some new syntax and it's going to shred your couch, decided that you needed async iterators but browsers don't well support it yet. And it's just an ongoing challenge. Whereas if you keep those dependencies light, you keep those out of your hair. You can be moving in a much faster velocity because you're going to be adding unique value instead of recreating things a browser already does.

Adam Elmore: Yeah. And then when you have like a dynamic use case where a page should be dynamic, I think in Architect or maybe this is just your preference, could you explain kind of the way you handle those situations through Lambda? You're just generating the page.

Brian Leroux: We're wilding out here. We're writing HTML from a Lambda function and I've been doing it since 2015. It works great for that turns out you're totally allowed to use template strings in JavaScript and you can put markup in those and you can even interplay values from DynamoDB and send it back and you can write your progressive enhancement as web components that hydrate on the client and that activates, if it activates. If you write those web components using real forms and real links, they'll still work. Even if the JavaScript doesn't execute on the client. And that's the best of both worlds. And the code footprint is incredibly low. We add a lot of stuff just to generate HTML that doesn't really need to be there. And I don't know, temped strings are pretty good. They're not components. I will grant that, but I will also point out that your backend does not have a DOM ready event or a click event or a form submit event.

Brian Leroux: So a lot of that component life cycle, that's so important, it's actually client side anyways. And so that code has nothing to do with the server. The server or the back end is concerned with the template side of the story. And that initial payload can be a skeleton screen and a bunch of loading spinners, or maybe it could have some data. If you're using Dynamo DB, you've got single digit millisecond, late C queries, why not just give the use of the data right away and then progressively enhance the behavior on the front. And that's what we recommend. We don't force you to do that. You're totally allowed to use skeleton screens and slow loading, build steps as much as you want, but I invite people to consider that isn't necessary.

Adam Elmore: Yeah, no, you've convinced me. I think it makes perfect sense. Does it feel like people don't, the adoption rate is maybe not where you would think it would be for practices like that? I've seen you ask on Twitter, or not ask, but pose that it's hard not to become cynical over some of this stuff. Do you feel like you've become cynical? Do you feel like we should be further than we are today?

Brian Leroux: You know, I don't know is really the only way I can answer that, I think the number of people that are building for our industry is growing exponentially. And so some of these practices seem to be a little bit lost in the noise and time. None of what I'm saying is going to be controversial. Someone who's been building websites for a decade.

Adam Elmore: Right.

Brian Leroux: But if you just got out bootcamp in the last few years and you learned to better react to graph and time script, this sounds like I'm burning a sacred cow, it's a horrible statement, but really it's just like kind of how things work and how most things are built.

Brian Leroux: There's very few single page apps in the top 10 websites, probably in the top 100. So that is actually newer. And a lot of that is predicated on mobile. So when we are doing the early embed wet view, PhoneGap thing. Single page apps was kind of the only way to make that experience feel native on the mobile phone. And PWAs kind of made that whole thrust a lot less compelling. People would rather just build a progressive lab app and be done with it, not deal with all that app store gunk.

Brian Leroux: And I think it's still very valid approach for that type of thing. And the other thing to note here is a single page app is usually embedded in a multi page app. It's not the other way around. And so there's not an either, or here it's an and, also. You're going to have multiple pages if you want to have one of those pages take over the URL and, display stuff without actually re rendering with a full server round trip, then awesome, do that if it's a better experience.

Adam Elmore: So I've got a bunch of kind of quick hit questions, things I ask most, every guest. So I've got these four or five questions here that give us a better sense of Brian Leroux. One, the first one. Do you have any mentors or sort of role models that played a big part in your career?

Brian Leroux: Oh my God. So many. Yeah. I feel like I was really lucky in this regard quite early on in my career. I was lucky enough to work with a gentleman named Kevin Mallory. I'm not even sure what Kevin's up to these days. He was the gray beard at the company that I was at. And I remember I had a rote programming task. We were a .net/Java startup. This was in, I want to say 2002, maybe 2003. And I had to rename a few thousand files and move them around. I can't remember why it's like some test rake or something. And I gave an estimate in standing where I was like, I don't know, it'll take a couple hours or something, sort of snorted it out. It's like, how familiar are you with the terminal?

Brian Leroux: And I'm like, I don't know, I'm not really using the terminal. I'm a Java .net dev. I use eclipse, at that time. And he showed me the task in done in literal milliseconds, on his personal machine, in a Unix terminal. And I remember seeing him do it and I just looked at him and I'm like, can you teach me how you did that? And that started a pretty long journey into this whole Linux Unix thing where I realized that it of being snowed over by IDEs and the promise of the all in one stacks of the day. Interestingly we're kind of back to that these days, but whatever. So if I were to give one shout out, that'd be one another would be friends I met from IBM actually early in the Cordova days, Patrick Mueller, Simon McDonald.

Brian Leroux: These guys taught me a ton about working in Open-Source in the early days of Cordova when we joined Apache. And that was more, less about code and frankly, more about politics. Dealing with a large open source project inside of an open governance body like Apache is its own special hell. And it takes a different kind of patience that I did not possess much of when I was in my late twenties, early thirties.

Brian Leroux: I'm a different person these days. They were definitely really influential for me in that way. And I'm probably missing people, but this is something I hope more programmers get the benefit of, but there's really nothing more empowering than having a great mentor and having someone that you can learn from. There's a lot of wealth of experience in this industry. And it moves so fast that we do forget lessons. There's a lesson in history that we're probably doing to repeat it. And you can shortcut your career a lot by talking to people that have been around a few cycles.

Adam Elmore: Absolutely. So shifting gears from that, into totally unrelated questions, that was so good though. Do you have a favorite AWS service?

Brian Leroux: Yeah. This one might be weird, but I think it's SSM systems manager parameter store. I got that name. It's longer than that, but everyone just calls it SSM, because that's the name in the SDK. SSM lets you store arbitrary key value pairs and it gives you a ridiculously high throughput rate and reading them. And so it's a really great way to do service discovery, but the best part about SSMS is it's free service. It's built into systems managers. So finding it is a little bit of a hack but yeah, it's probably my favorite.

Adam Elmore: What about a least favorite service?

Brian Leroux: I'm sorry to the team that manages this because they know it's your baby. So I don't want to call anyone's baby ugly, but I've the reason I suffer male pattern baldness is because of Elastic Beanstalk. Entirely their fault. My least favorite service by far, I had a lot of pain dealing with that. It's probably a lot better now, but it deploys web servers and I don't care about those anymore.

Adam Elmore: No same. I definitely have a history with that service. Do you have any favorite... We'll leave it at that. I just thought the EV extensions thing. I think just the way you pushed on the boundaries of Elastic Beanstalk, just not for me, but also web servers, also not for me.

Brian Leroux: Rolling deploys that take 45 minutes to find a bug. Oh my God. Don't miss that.

Adam Elmore: What about a favorite emerging trend in tech?

Brian Leroux: That's tricky. I feel like there's a good cynical answer around Web3 and I'm not going to do it. Not going to do it. I'm trying not to do it. The thing I'm excited about right now is probably, there's two. One, I'm really excited that the word HTML first is becoming a thing that people are talking about building progressively enhanced apps. That's awesome. Yeah, that would be the big one. The other one that we're sort of bouncing around is trying to call what we do, functional web apps and putting a focus back on functions and away from load balancing web servers even if they are auto scaling. I know that a lot of people talk about a spectrum of serverless services. I think that's fine and good and very inclusive and nice. And I'm not trying to gate keep, but I think precision and specificity is also important.

Brian Leroux: And so we're trying to talk about building on demand managed services from small single responsibility functions, not web servers or microservices or whatever, load balancing, anything. It's just logic. I just want to write code and focus on my business logic and deploy it and have it auto scale and all the rest of that. So I've been calling those functional web apps lately and the best function is a function you don't have to write. So if you can abdicate to a managed service or even go so far as to just glue services together, a step function, do that and you will be much happier for it.

Adam Elmore: Do you have any hot takes?

Brian Leroux: I don't know. I don't think what I'm saying is always so controversial but then I get talked off a ledge. I have a difficult time saying that things like GWT are web development. I think that's writing Java. And if you take that to the logical extreme, I don't think if you're writing in a third party file extension, that's not standardized that you're kind of not doing web development, you're doing whatever that file extension is. You might be compiling for the web and you might be a web developer, sure. But you're not doing web development. That's a problem. And I don't know how to get around that problem.

Brian Leroux: I'm not trying to gate keep, but I do think again, specificity is important and how we approach our craft is important, because it does have huge consequences. And we want to generally build accessible inclusive experiences for the widest range of people possible. And we don't want to have to revisit our code every six weeks to recompile it because some bugs sucked in through the MPM registry. So there's a long way to go for stability for this craft and it's waiting for us. It's right there. The runtime environment is backwards compatible. So I think rediscovering that is my mission in life these days.

Adam Elmore: Yeah. And it sounds like lobbying for just improving the on ramps into this career. The fact that a lot of newcomers to development or web development are finding this path into React and SPAs and that's maybe the problem that we need to educate and better bring people into maybe more web standard practices. Is that kind of what you're saying?

Brian Leroux: Yeah, I think so without so many words and I don't think there's any problem. I think it's good. I think more programmers is always a win. I think more diverse voices at the table is good. I just don't think the story ends with that SPA or React. That's where the story starts. And there's so much more to learn and do. And really the front end's only going to make up like a small percentage of the work that you do. Once you're building larger systems you're going to need a database. You're going to need DNS. You're going to need a cloud provider. And once you need those things, you've got two choices. You can go implicit and lock yourself into a cloud provider that takes care of all that stuff for you and not be reproducible anywhere. Or you can learn how to be explicit and declarative and reproducible. And that sounds like work and it is, but you'll be able to go home at five and know that your app is scaling automatically. And if you do have a bug, you'll be able to reproduce it.

Adam Elmore: Yeah. So going back to what you said about functional web apps, I think that's refreshing to me to think of things, to think of serverless development through that lens, because I hear terms like microservices and I honestly just don't know what to think about that. I don't know if what I'm doing is microservices and at this point I'd love to just not have to learn, Is that a thing I'm doing? Is it fair? Is that safe to just ignore?

Brian Leroux: Yeah, I don't know about safe to ignore. So microservices has been an interesting one and I'm not even sure what a microservice is anymore. Sometimes people will...

Adam Elmore: That's how I feel.

Brian Leroux: ...accuse Lambdas of being them and I don't think they are. I think a microservice is a discreet deployment of single responsibility function of some kind. And you could build that out of Lambdas if you wanted to, but more often than not, you're going to build that out of a cluster of Kubernetes things or whatever. And it's normal for terminology to get polluted and change over time. And it's normal for new terms to come about, to add specificity and correctness. So staying functional and staying functions and using the cloud functions is primitive that the bedrock is built on, I think is a net positive because it shortcuts us from a lot of the noise it's in the marketplace right now. If cloud runs serverless and I don't know. Sure, great. Then deploying web servers is now serverless. People always joked that there were servers and serverless and now we're just doing it and that's fine.

Brian Leroux: Go do that. If that's what you want to do, I'm good over here. I want to abdicate all that work over to Amazon. I don't want to run my own gateway. I want that to be statically encoded information. And I want to have handler functions that deal with that, that will deterministically deploy and auto scale to zero and nothing wrong with that either. That's the approach that I prefer. And I want to be really specific about that approach. Terms like monolith and microservice and even serverless itself have become somewhat meaningless and not helpful.

Adam Elmore: Yeah. I think I assumed that the microservices thing didn't apply to me because I mostly work alone. I don't work on teams and my assumption has been, microservices is a thing that people on big teams need to manage people in building out large systems.

Brian Leroux: Yeah. It's totally a Conway's law thing. The people that have success with them tend to be these very big companies like Amazons and Ubers. Two big examples of it working at scale. And you never hear about the stories where it didn't work at scale, but there's a lot of battle scars over there. Small teams that tried to do it and quickly discovered that with every service is another point of failure. And so distributed systems can multiply your failure modes pretty fast, especially if it's a big system. And I don't know that we're doing that anymore. The cloud platform has subsumed a lot of these capabilities at such a tiny level. A Lambda function by itself, I guess could be a service. Now we're getting a little bit like semantically weird. Like I won't accept the term nano service.

Brian Leroux: And I agree, I think that's growing unhelpful at this point. It's worth examining and it is interesting. A lot of the stuff that we assumed is hard work is actually built in now. So logging is often lauded as this big hard thing. And I will see that the cloud watch is not the most pleasant place to go, but it is magical. There is so much power there and it's just built in, you just get that. We didn't used to just get that, that didn't used to be a thing that you just got for free and now you do. And now the problem is almost inverted. It's not that I can't get my logs. It said I have two God damn many of them.

Brian Leroux: I like to joke that the logs are how data gets big. And it's true. Once you've got a ton of logging, then you have a ton of logs and then you got new problem. But CloudWatch Insights, again another Amazon service is just built it. And it's magical. I query across all my logs in a few seconds, I can pull meaningful strings out and timestamps and I expect that only gets better with time and that would've been a pillar for like a microservice discussion, that would be a whole team working on lobby. Now it's just like you get that's, that's free.

Adam Elmore: Yep. It's exciting times. I know I'm as a cloud developer, whatever I am, I'm just kind of giddy about some of the stuff that we get to play with and build with in 2021.

Brian Leroux: We're spoil and we don't even have reinvents started yet. There's going to start hammering us with announcements any day now. It's just going to be all kinds of new toys.

Adam Elmore: Yeah. I've got to pull back on the number of podcast episodes so I can play with all this stuff. I realized like, I'm just mostly planning and editing podcasts at this point. And I haven't played with all the step function stuff. There's lots of stuff. That's exciting.

Brian Leroux: Yeah. That new step functions capability is mind blowing. I think that is going to be profound for years to come.

Adam Elmore: Well, I want to play a game. We've got a little bit of time here. This is going to be a new game for the show. And the idea is I'm just going to start a 30 second timer and Brian is going to spout off as many AWS services as he can think of in 30 seconds. I feel like this is a little more skill based than AWS or Amazon where, who knows which one it starts with. So the problem here is my trackpad died, which I don't have a way of checking to make sure you're not just spouting off random things I've never heard of that are fake. So then we'll maybe get a score after the show in editing. Brian, are you ready?

Brian Leroux: As ready as I will ever be.

Adam Elmore: Yeah. There's not really a way to prepare for this. All right. 30 seconds on the clock. Here we go.

Brian Leroux: Okay. If I had to start anywhere I would start with cloud formation and put that behind a cloud front distribution, which would itself have an ACM certificate manager cert, which would then talk to API gateway, which would use IM to invoke a AWS Lambda function, which might call Dynamo DB.

Adam Elmore: Wow. 30 seconds is so short.

Brian Leroux: It's so short. I could have kept going. I had more.

Adam Elmore: Yeah. Oh, you had way more serverless services I'm sure you would've gotten to. So maybe we do a minute on that one in the future I'll expand that one a little bit.

Brian Leroux: I was just trying to walk through how I would do a crud app.

Adam Elmore: Oh yeah. No, that was great. That was a good approach. Otherwise, how do you keep track of what you've already done? Yeah. So I think you got seven. So we'll just double that to 14 if we do extend it to a minute for other guests, we'll just put you at 14.

Brian Leroux: Only 250 to go.

Adam Elmore: And that's not... Yeah, three reinvent is just around the corner. So that's a moving target. Well, it's been so good, Brian, to have you on the show. It's somebody I've admired on Twitter for a long time. It's really great hear more of your thoughts outside of just 280 characters. So thank you so much for taking the time.

Brian Leroux: It was an honor to be here. Thanks for having me.

Adam Elmore: A couple of quick things on the podcast. I guess one, join the discord. If you're listening to this, I'd love to see you on the discord, helping me make this show better. That's the goal. And then two, if you listen to this show on podcast platforms like Apple or Spotify or whatever, I'd appreciate if you gave it a rating and a review, I still have never looked up what that means.

Adam Elmore: I'm assuming I've got some guesses now. Like I assume it probably improves discoverability or something, but mostly it makes me feel better when I see those reviews. So please rate and review the podcast. I appreciate that. No cynical reasons here. I have no motivations other than feeling good. Yeah, I think that's it. So we'll be back on Thursday. We've got Shawn Swicks Wang on the show and thank you again so much, Brian for being on the show.

Brian Leroux: Yeah. Thanks again.