Episode #63: Building Serverless with Begin with Paul Chin, Jr.

About Paul Chin, Jr.

Paul Chin Jr. works in Developer Relations at Begin, a tool that helps everyone build apps fast with cloud native services and open source tools. He previously worked as a Cloud Solutions Architect at Cloudreach, and is passionate about open source, serverless architecture, and making technology more accessible for everyone. Paul’s a lifetime resident of Virginia Beach, VA, and has a special place in his heart for Nicolas Cage, who tends to make an appearance in his presentations and projects. Feel free to talk to him about anything related to tech, food, or business.

• Twitter: twitter.com/paulchinjr
• 757 Dev Group: meetup.com/757dev/
• Begin: begin.com
• Begin Training Resources: learn.begin.com
• Architect framework: arc.codes

Watch this episode on YouTube: https://youtu.be/L8DkEqgVEBY

Transcript

Jeremy: Hi, everyone. I'm Jeremy Daly and this is Serverless Chats. Today I'm chatting with Paul Chin Jr. Hey, Paul, thanks for joining me.

Paul: Hey, Jeremy. Thank you so much. I'm really excited.

Jeremy: So you are, or you do Developer Relations at Begin. So I'd love it if you could tell the listeners a little bit about your background and what Begin does.

Paul: Sure. Well, my name is Paul Chin Jr. At Begin, we are a service to make deploying serverless applications just super simple. Really straightforward. We give the developers everything they need from local development all the way through the CI/CD pipeline, and then we put their app onto live AWS Infra. For Developer Relations, my job is to help developers understand this technology, onboard them and get good feedback from them so we can make the service even better.

Jeremy: Now, I noticed you have a sloth hiding behind you. Is that-

Paul: Oh, yeah.

Jeremy: ... something that basically says, "This is how it used to be. And now serverless is so much faster."?

Paul: Yeah. I feel like sometimes we've got to give ourselves permission to slow down a little bit. It's a reminder that says, "It's going to be okay." And even if I step away, it's going to be okay.

Jeremy: Perfect.

Paul: Yeah.

Jeremy: Well, so I'd love to talk to you about Begin. And I want to get into a whole bunch of things with that. But maybe we can begin, I'm sorry, that was a really bad joke. But maybe we can begin by just talking about your path into technology. Because I know it's a little bit non traditional. And this is one of those themes I think, that we see a lot with serverless, is a lot of people from non traditional backgrounds go into serverless. So what was your path like and then how did that lead you into serverless?

Paul: Oh, man. This question is always great and I love sharing the story because it's a good example of just where technology has taken us now. I don't have a CS degree. And I was never doing anything remotely technical. I was just always a big business nerd. And I've had several businesses in the past. And then one day I decided, "I should learn how the software stuff works. I use the internet a lot. So I should figure out how it works. Because it's going to help me, no matter what I do."

And so I decided to undertake, like, "I'm going to learn how to program in JavaScript and make web applications and do all that stuff." And so I started that and I had a wonderful local community of developers that took me in and mentored me. And from there, I just wanted to find the fastest, quickest, easiest way to build a form or to build a CRUD app. And that always led me to cloud native services. I didn't know it at the time, but not setting up my tooling and not setting up a server, all these things that I would read about, I was like," I don't want to do any of this." And now I'd find a new service. And it would just do it for me. And I was like, "Great, I'll just use this." And they always had a free tier and they were always easy to sign up, you just give them an email or a GitHub or something.

And then that's how I continued on this path of, quote, now "cloud native development" to use all the buzzwords. And it was just a very organic thing for me to continue to learn and build and put stuff out. Because none of the infrastructure was in my way. None of the arcana of what it is to be a web developer was in my way.

Jeremy: Yeah, no, I think-

Paul: So that's how I got to it.

Jeremy: Yeah, no, I think that's a common story, this idea of, you look at everything you would need to do in order to build out a full on web application and you're just like, "Yeah, you know what? Maybe I'll take up gardening," or something like that, because it just seems like an easier path. But I agree, I mean, I don't have as traditional as a background or as traditional of background as a CS degree. And some of those things I actually did a split degree and random stuff. But I ran a web development company for years and years and years. And mostly, I taught myself how to program just by reading books and using the internet and things like that. And I went down the deep path of learning how servers work and how networking works and all that kind of stuff. Which I'm glad I did. But for somebody new it just seems like if unless you're getting specifically into that business, if you just want to learn to build applications and develop in the cloud, then that traditional experience I think, is not necessary anymore.

Paul: Yeah. And it changes so fast.

Jeremy: Right.

Paul: I got started right when the MEAN stack was a thing. Everybody wanted to build the Angular, Node, Express thing. And I recently, as part of my job at Begin is to take these example apps and make them better and make them more accessible. And so I recently just took one of the first sites I ever made. And went to the Free Code Camp resource that I had used five years ago, when I first built it. And I go, "Man, none of this is actually deploying anywhere." And I was trying to remember, "Well, how did I actually deploy this thing? I must have done it on Heroku or something." But there was no instructions for it.

Jeremy: Right.

Paul: And I remember, that was a friction point. I was like, "Okay, I've gone through this tutorial. I've built this thing. It works locally, on localhost only. Now what?" And what Begin does is say every time you push to GitHub, your stuff is live. It's just automatic. It's just a given. We think that it's just table stakes now like, while you're building and prototyping, and developing, you should be able to see it on live resources. And so I've updated the Express app. I even threw the entire Express server inside of a single Lambda, and it works just as a proof of concept. But splitting them off and doing more event architecture with it is the next level. And it's just as straightforward. Because if you're pushing to GitHub, you can push to the cloud. That's it.

Jeremy: Right. Yeah. No, that's awesome. So let's talk about Begin. Because I think that's one of those things where if you think about serverless development, and you're thinking of SAM, the serverless framework, and or the Serverless Framework. So the Serverless Application Model, the Serverless Framework, obviously Architect is the backbone of Begin, or is part of that and we'll talk about that in a minute. You've got Claudia.js, you've gotten Breath, you've got all these other things that are ways to deploy. But getting that is part of a process, is part of a CI/CD process that is always repeatable, that you're not deploying from somebody's laptop every time you want to push something to production, which was very common with those tutorials that you mentioned before.

So let's talk about what Begin actually does and what it doesn't do. Because I think that's important for people to understand where there may be limitations. Because Begin is all about being serverless. So I think that could help too, just to say, "Hey, here's what you can do with Begin. And here's where that correlates to what is possible with serverless." So at a very high level, I guess, let's start there. What can you do with Begin?

Paul: So Begin uses OpenJS Architect, which is a serverless deployment framework that can package and bundle up all of your Lambdas. All of the Begin applications are comprised of small serverless functions like that. That's it. And so what we do is we associate your project inside of GitHub with a full CI/CD pipeline straight to AWS. And every time you push to your default branch and commit there, it will kick off a build in the cloud. And it will do it as many times as you push to it, and we give you the full AWS Infrastructure, we don't actually manage any of the infrastructure personally ourselves. We just make it easier for you to launch onto AWS without an AWS account.

I think that setting up AWS with keys and IAM roles and all that stuff is necessary and we have hidden it with a really nice UI, and made it so that people can push their Lambdas without having to go through a bunch of stuff and we do that as a combination of the CI/CD platform and OpenJS Architect.

Jeremy: Right. So you're building your applications with OpenJS Architect, the Architect framework, which is a really, really terse framer. I mean, it is amazing how little you have to write to make that work, which is quite amazing. And I love that about that. I spoke with Brian LeRoux, way back I think it was Episode 17 or something like that. And we were talking about the framework and Begin was just beginning at that point. But it's really interesting that it's super simple to just configure what these applications are going to be and then drop in your business logic. And then there's a whole bunch of other things that go around that. So CI/CD is one of the main pieces. But what about developing locally?

Paul: Oh, yeah. So for local development, I was a big user of the serverless trademark framework.

Jeremy: Right.

Paul: The one that is called serverless. And local development was always invoke the regular function. But now with Architect, we've emulated a good chunk of how all the AWS services work. So you can spin up what we call Sandbox, which is a local development server. And it emulates API Gateway, Lambda functions, events, queues, and DynamoDB for folks that want to use some persistent data, which we always need to get from time to time. It's not all stateless all the time, even though I wish it were.

Jeremy: Right, right. And so the other piece that I think is really interesting, and this was funny, I had a laugh with Brian about this, where I had said that the Architect framework seemed to be very opinionated in terms of how it made some decisions in terms of how to do certain things. And he thought it wasn't, but he gets how maybe I got to that conclusion. But what I think is interesting about the way Begin works, and this is not something that is so much opinionated, more so as it's, I think, just instructive and guiding of best practices. So when you use Begin out of the box, it automatically sets up a staging and a production environment for you. You limit the size of the functions to five megabytes. What's the reasoning behind all that?

Paul: So initially, when I first came to Architect, I wasn't even working for Begin, or I was just using Architect because it had an awesome local developer experience. And it was doing things with infrastructure as code in a completely different way. And I think a lot of the opinions are there just to make it smoother. And the other thing is Architect is really focused on web application. Its main job is to make sure that you can build a REST API really quickly, or you can build a static site really quickly, and get it deployed really quickly.

And I think at that point, we want to make sure that first, default happy path is going to be good enough for production level stuff. Because if you build it for production from the beginning, then there's no upscaling of your prototype. You're going to have staging, you're going to have production. You play in staging as long as you want, and when you want to go to production, click a button or release a git tag. And it's just, that's it. It's already built in. A lot of people will try out Begin for side projects and whatnot, but always the true goal is to build something that lasts and build something that is meaningful, and it's going to need certain features that will ensure that it is repeatable and stable, and has all of the checks and balances that you want when 50 people or more are working on your project. And so that's where a lot of the opinion might come in, is because of the experience of knowing where these projects should end up and baking that into the happy path from the beginning.

Jeremy: Right. Yeah, no, I love that. And that's the thing too, where with a lot of these frameworks or even some tutorials, the direction and the best practices, I don't want to say they're not there. They are baked in, but they're not quite as explicit. So oftentimes you start asking yourself, "Well, should I do this?" Or, "How should I do that?" So I do love that Begin enforces, not so enforces, but definitely encourages you to do some of those things. So-

Paul: What's funny-

Jeremy: Oh, sorry, go ahead.

Paul: Oh, yeah, I was going to say, the things that we have opinions about are really just for production support. And the thing that we don't have opinions about are the things that everybody wants to have an opinion about. I just think that it's interesting, that we don't care what front-end framework you use. And we don't really care if you want to bring another application framework on the back-end either. The only thing that we do really emphasize is that you keep your functions small so that they can load performantly. And we do care that you want your functions separated and decoupled, so that they can have independent deployments. Stuff like that. The parts that we're trying to teach people about that are important for a serverless architecture.

Jeremy: All right. So now what about the runtimes? Because I know now we can only do Node.js and I believe Deno as well. You can write it in Deno. What about, if I want to write something in Java, I don't know why I would want to, but let's say I did, or I wanted to do something in Python or something like that. Is it possible to do that within Begin or will it be possible?

Paul: It will be possible at some point. Right now we're still working on enabling extra layers. So for folks that are not aware of what a layer is, it's a way to load external dependencies to be available for your Lambda functions. Currently it is Node and we did add Deno at the beginning of the year because it's just super exciting to try to do. So we've allowed people to build functions in TypeScript, run them on Deno on this serverless architecture. And the really cool thing about serverless is we can swap out runtimes within the same application. So not available yet through Begin, but if you use Architect, you could totally mix and match your runtimes per function. So you could have an application built out with 60% Node functions, 20% Ruby functions and 20% Python functions and it'll all work together in the same framework. We just load them either directly inside the Lambda or load it as a layer to be used.

Jeremy: Awesome. All right. So now, what can you actually build with Begin? You said it was very much focused on web applications or Architect was very much focused on web applications. So what are the standard things that we can build with Begin?

Paul: Sure. Well, anything you can build with Lambda functions. So if folks are familiar with how they use Lambda functions, then that's what they can do with Begin. What I like to build are just REST APIs. Lots of just separate endpoints. I believe that Begin is the fastest way to really just get an endpoint up and running, if you want to have, I don't know, my go-to example is just a quote machine. You want an endpoint where you can just hit and it will bring back a random quote. You want an endpoint that's going to reach and do some stuff with some data inside of DynamoDB. You want to build a full application with lots of different endpoints, that's a perfect thing for Begin.

Jeremy: Right. And you can also use it for... I mean, of course API is a or REST API is often an over encompassing, I guess description. Because with those, you can build Slack apps, and you could build-

Paul: You're right, yes.

Jeremy: ... Alexa Skills and all those kind of things as well. Right.

Paul: Yep.

Jeremy: Yeah.

Paul: Anything that has that web hooky feel. You need a service to push some data to some endpoint, you can build that. Yeah. And I think that it covers a huge amount of use cases for working developers today.

Jeremy: Yeah, it's pretty cool. All right. So what about data in sessions? Because that's another thing, I don't want to say a complaint. I mean, people who don't understand, I think how to build serverless applications often think of stateful applications, and yes, we need to rehydrate state and we need state in there. What's cool about Begin, or I guess, it's part of Begin, part of Architect or how it's mixed in there, is this idea of having sessions that actually can track people from Lambda function call to Lambda function call. And I know that it uses your back-end database, or it uses DynamoDB, or the I believe, what's it called? The Begin Data service in order to do that. But can you just explain what's Begin Data, how does this session thing work? Because it's really interesting to me.

Paul: Yeah. So early on we knew that people were going to need persistent data. And I guess, one of the things that serverless does not do so well is handle socket connections to databases. And there are ways to get around it and there are ways to make it work. But we feel that DynamoDB has got everything that serverless needs for most cases. And so we integrate that pretty heavily and we expose a DynamoDB client through another open source library called Begin Data. And what Begin Data allows is for people to use Dynamo with a simplified API. So there's just get, put, delete, batch and increment decrement. Some of the basics that you're going to need. And it's new, and it's different for people coming from even something like Mongo. It's still different enough to where, I really need to do a better job of explaining it and putting out different examples.

But for the sessions, that's a basic web concept that needs to be there. And persisting it from function to function, we have middleware that can help. And it'll write the session either to Begin Data, which is a DynamoDB table, or wrap it in a JWT and then send it back and forth and capture it inside that request object and shuffle it down through all the different requests that it may need to touch. So you can do things like authenticated login, get the session, and hold that session until they're done and they log out. And so you can pass certain session IDs back and forth between the different Lambdas and it'll be fine.

Jeremy: Yeah. No, I think that is actually, it's a great feature. Because I mean, the ability to send in a auth token with every API request and then have API Gateway authenticate that and do all that work for you, that's all possible. But what I love about Begin is it just bakes that in. And again, going back to this non traditional path into technology or even people who are in technology, maybe you're a PHP developer, and you want to move over to using serverless, with Node or something like that. This idea of having that baked in session management in there, which, by the way, is just an abstraction on top of auth tokens and things like that. So it's not like it's doing anything -it's doing things that are supported, it just abstracts that away for you. So I really like that.

And I also like the Begin Data thing, because it feels very much so like Redis. You know what I mean? Where it's, it doesn't have all the same features, obviously, because Redis is more powerful from a in memory standpoint than Dynamo is. But in terms of what it gives you, just that ability to say, hey, I just need to save this a little bit of information for this user or I need to get this or I need to increment some value and having that all be powered by a serverless back-end infrastructure is pretty cool. So the fact that it abstracts all that away, I think is, I don't know, I think it's awesome. I know, and I can't find the word for it.

Paul: Yeah. Yeah. And that's why I really want people to just give it a shot and try it out and know that it is a little different. And then a big idea at Begin is this idea of a beginner's mind. It's called Begin for a really good reason. We want people who are going to try out something new, but also see what is possible when they rethink what they can build.

Jeremy: Right.

Paul: And really bring that beginner's mindset to it.

Jeremy: Yeah. So speaking of opening your mind to things, what about Deno? So I'm not sure if people are familiar with what this is. It's been around for a little while, I think it just hit 1.0 or something like that. But what is Deno? And why is Begin looking at it?

Paul: Yeah. So Deno is a new JavaScript runtime from the creators of Node. They wanted to essentially redo Node and create another execution environment that is going to be more secure, more stable, and more web native. They wanted to build an execution environment that's really going to be like the browser. So they've built in more browser APIs like Fetch Native to Deno. They have the ability to do TypeScript if you do that kind of thing. And what we find really interesting about it is again, because it's serverless, we've built a plumbing to just say, like, "Oh, I want Deno instead of Node." You just go, great, just write Deno in the configuration. And now you're executing in Deno and not executing in Node.

Jeremy: Yeah. And what are the advantages though? I mean, because I've been looking at Deno a lot and I've seen the TypeScript execution, for example, isn't quite as fast. Type checking isn't quite as fast as some of the other things. I mean, so that's maybe some of the downsides. But what do you think are some of the upsides besides just maybe the security and stuff?

Paul: I think the biggest upside for me is how it loads modules. It's just a URL. And I get that-

Jeremy: Oh, yeah.

Paul: Yeah. Like require statements, you could technically do it to be like pointing to a GitHub. You could make it a URL from end-to-end in Node. But it's not built that way. But when you are writing in Deno, it feels like you're writing for the browser more than for Node. And I think that that is a benefit, because ultimately a lot of what we write ends up in the browser and it needs to be executed there. So if we get better at executing and writing JavaScript for browsers, and it also is the same style and APIs and data modeling that we have, on the server side runtime, then it just feels a lot nicer. Being able to write a module and say, "Import this dependency from this endpoint." Well, you can control that endpoint. I could have one Begin project that is my dependencies, and I have my own mini NPM. That's just part of it.

Jeremy: Okay.

Paul: And I get to control that from the beginning. And there are trade offs, obviously, to how much you want to control your dependency tree. But you can do it. And it's not insane. You don't need a whole lot of engineering talent to build your own repository now. And you just go ahead and you do it because the underlying infrastructure is AWS, it's already globally distributed, you can make it as fault tolerant as you'd like. And just go ahead and include it in your application workflow. And I think that is super powerful. I think that not relying on NPM for your builds, is something that is going to make a big difference in a few years, as things get faster and faster and faster and more demanding.

Jeremy: Yeah. No I think from the security standpoint too, just around your NPM packages that you're using, or any package manager you use, as things change, you get that potential security issue if something comes up and somebody injects a bug somewhere or something gets in installed incorrectly. So I think that's interesting being able to control your own destiny and your own dependencies on that side. All right. So let's go back to maybe Architect a little bit and talk about this idea of Cloud Function Based Applications or CFAs.

Now this is something that I saw on the Begin site, and I started searching around for it, there's a few mentions of it, but it seems like this is something that Begin has really embraced this term, Cloud Function Based Applications or CFAs. So what is it about those that that makes them so much better, at least in your opinion, and maybe Begin's opinion, than building something on traditional servers like VMs, and instances and things like that?

Paul: Yeah. So I think I would start by saying Begin itself, is a full serverless application. So when folks are interacting with Begin, they are 100% interacting with just Lambda functions and DynamoDB. So for folks that think it's just like Git calls, you can do a whole lot more behind the scenes because functions can also give you queues, they can also give you messaging channels, they can also give you timers, with scheduled jobs. And so this is part of the architecture and infrastructure and your code base all at the same time. And that sounds really impressive. And all it means is that if you need to build an application that has a queue, you just go ahead and write the function for it. Or if you need an application that say, just needs a series of functions, go ahead and put them in a scheduled function.

And at the end of the day you look at your application and you're able to read through what it does by the functions that are present. There's really nothing else to it. You look at what we call it as the arc file the app.arc file, it's a manifest at the root of your project that defines your routes, and defines all the functions that your application may have. And it sounds like, "Oh, man, I'm going to have thousands of functions," but you really don't. When you boil your application down, you have, I think all of Begin is under 60 or something like that. It's not too many where I can just read through, I know how the applications work.

And so I think that's a really exciting architectural point for serverless applications. And it's just less for me to deal with at the end of the day. I just know how my application works because I can look at the arc file and say like, "Oh, there's nine routes here. Good to go."

Jeremy: Right. And then of course, you have all the serverless benefits in general to that, which is you're not paying when you're not using-

Paul: Oh, right.

Jeremy: ... things. And never require a patching, those sort of things as well.

Paul: It's funny, I've been doing serverless now, for so many years I forget what's the basics. But the basics blow people's minds and I'm just like, "Oh, yeah," I don't do VMs anymore. I don't have to specify anything, I just have it available.

Jeremy: Right.

Paul: And Brian and I, when we pair program, it's hilarious, because he'll just open up a GitHub repo in the browser. And then just edit the code in the GitHub browser, and then scroll to the bottom and click the green submit button and it'll kick off a new build and we'll just go look at it on staging.

Jeremy: Yeah.

Paul: That part is super magical. The speed of iterating through your prototype is just astronomical.

Jeremy: Yeah. No you make a good point about actually the things that I think blow people's mind about serverless, those being lost on people like us that have been doing it for so long. I just take for granted not having to set up a VM now. I mean, if anybody said, "Hey, I need a web hook that does this," I'd be like, "Okay, yep, I'm just going to set up a Lambda function API Gateway." Or it's like, I need some other service or whatever, but yeah, no problems write it in the Lambda function. It is amazing that we don't necessarily think about that anymore. But there are though, some things about these idea of CFAs that are going to be a little bit limiting. I don't want to say limiting, but just things that you have to think about. What are some of those things that you are limited or need to maybe rethink the way you build your applications when you're using the Cloud Function based approach?

Paul: Sure, sure. So I feel like all of us will make trade offs in our decisions, in architecture. There's always going to be, do I really need the new shiny? Or do I just use what I know? And for that huge use case, each developer has to decide if they want to put in the time to learn a new platform. Now we have tools and examples and stuff to make that easier. But the things that Cloud Functions can't do so well are long lived things. Things like obviously, the function times out after 15 minutes, if you want it to, or at least up to 15 minutes. But a lot of these limitations are going to be chipped away at over time. And I feel like AWS is going to continue making them into more and more traditional looking execution environments.

But other things that we can't do are connect super easily to, say a relational database, something that's socket driven. We don't have a good happy path for that right away, not like we do with Begin Data. We don't have any way to build container based workflows. We just don't have them. We're not going to pull from ECS. We're not going to pull container info down. And it's less about limitations of Begin and frameworks as it is more about getting back to what is going to be the most web native, really.

Jeremy: Right.

Paul: And that means that we're going to make sure that the things that the browser and 99% of web applications can do, we want to be able to support those use cases.

Jeremy: Right. Right. Yeah. And I think also, most of what people are building now, other than maybe some component that runs in the background that does something fancy, most of what people are trying to build and trying to Architect now, are these are CRUD apps. With a little bit of queuing in there, and some web hooks and some maybe calling Amazon Comprehend and getting some sentiment analysis or things like that. But for the most part, it's a lot about compute and data. Those seem to be the two biggest things.

So this is something interesting that you just said, and you mentioned this idea about trade offs. But I think that is important because serverless is a new paradigm if we want to use that word to describe it. Well, you are certainly thinking about things differently when you build an application. And if you say, "Hey, I don't have state anymore, and I need to rehydrate that state." And there's maybe a cost to rehydrating certain amounts of state in every Lambda function. Now we're talking milliseconds in order to do that. But it's still something you have to think about. The long lived executions, I can only run my Lambda function for up to 15 minutes. If I'm doing some ETL task or something like that, I have to break it up into multiple sections.

If I want to queue something, I'm no longer just saying, "Oh, I'm going to use RabbitMQ," or something like that, "I'm going to use SQS queues." And if I want to connect my Lambda function to an SQS queue, and again, I know that Begin and Architect help abstract some of this away, but I have to think about what the concurrency is going to be. How fast do I want to be processing those things. What are the redrive policies? What do I do if something fails, and it goes into a dead letter queue, then what do I do? And what's the replay? And some of those other things?

So I am of the opinion, and I would like to think others agree with me on this, but that serverless is getting more and more complex. That we took this idea of simply saying, "Hey, here's a function responding to an event." And we created an entire ecosystem around that, that made it much more complex. I like what Architect does and I like what Begin is doing with Architect in that it tries to simplify that. I like the idea of serverless components where you try to simplify the connection between the building blocks, same thing with SAR, the Serverless Application Repository. So I'd just love to get your opinion on this, do you think serverless is becoming too complex? Are we potentially going to shut out new people and new adopters if we continue to go down this road where we get very, very granular with these building blocks and just make it harder and harder to stitch all these things together?

Paul: I think that it has no choice but to become more complex over time. That's just what's going to happen. But a whole new set of tools and services like Begin are going to come out of it in order to keep that overhead low. There will be opportunities for people to create tools and processes that push away and abstract a lot of the undifferentiated heavy lifting, over and over and over again. So as complicated as AWS has become, I always make a joke, "AWS, they've got a service for everything."

Jeremy: Right.

Paul: Including satellites. If you want a satellite, you can go to AWS. I don't need satellites. I just need an endpoint behind an HTTP server.

Jeremy: Right.

Paul: And that's what Begin does. And so we've found that somebody who's making a web application doesn't need to log in to the console, and click through nine different menus to see their logs. Yes, that's complicated, because when AWS first started off, they had less links on their page.

Jeremy: Right.

Paul: Now there's 300 links of places to go to and services you probably don't need. And AWS doesn't have a strong need to simplify. And so that's why Begin exists and we're going to simplify the parts that web developers care about, and really focus that down. And if you need something outside of the AWS services that we provide you, you can try to write your other integrations around that. But really, for most use cases, you just need the eight.

Jeremy: Right.

Paul: And so it can get as more complicated as you want. But still you just need the eight.

Jeremy: Yeah. No, and I think that's a good point. I mean, I think part of the problem is, is you go to the AWS console, and you're right, and you see 250 services, or how many services it has. And you say, "All right, I want to build the CRUD app. I don't think I need the satellite." But I mean, is it something where we keep on trying to replace one level of abstraction with another level of abstraction?

Paul: Yeah. I think that's totally valid. I would say that right now the way I'm building applications is definitely simpler. It's definitely more, I guess in step with doing a thing, seeing a thing, doing a thing, seeing a thing. And in that part, I want to keep that feedback loop tight and going as best as we can, but I just don't know if there's a great way to say, "Yep, we're too complicated now. It's time to blow it away and start over again."

Jeremy: Right.

Paul: I just think we just continue focusing on the core services that you need, and making those faster and better.

Jeremy: Yeah. I wonder too, if the variety of abstractions also adds to the complexity. So even though-

Paul: Oh, yeah.

Jeremy: ... even though one thing makes it-

Paul: Oh, yeah.

Jeremy: ... easier, now you've got AWS CDK, you've got CDK TF, you've got cdk8s, you've got your Serverless Framework. You've got all these different ways that you can provision and then you just have the complexity of Cloud Formation underneath that, that it's funny where it's well, which one do I choose? Because at the end of it all, they all do the same exact thing.

Paul: Yeah, push to CloudFormation. So even Architect pushes to CloudFormation. That's how we make it repeatable, because on the AWS side, not on any of the other cloud providers, but on the AWS side, CloudFormation is the one way to have repeatable infrastructure. And so even Architect will build down to a SAM template, and then the SAM template will build down to CloudFormation. So part of the really cool foresight that Brian had when he was building this was, if you build your application with Architect, you can still deploy directly to AWS with SAM.

Jeremy: Yeah.

Paul: Because it's a hunt like SAM is downstream of us.

Jeremy: Yeah.

Paul: And so if somebody was using Begin, and then they wanted to really expand and get that satellite, if somebody was using Begin, and they're like, "Man, I need that satellite." So great. You can take your same project, send it directly to AWS and then add your satellite.

Jeremy: Right. Right.

Paul: It's fine. We let you do that. And that's a big part of how we run.

Jeremy: Yeah. Well, and the other thing I think, too, is, especially from a serverless adoption standpoint, I mean, when you're trying to pick what framework you want to use or whatever, it's a lot easier if you're building a greenfield application. So if you say, "Hey, I'm just building some new service that does XYZ," I can really choose any one of these frameworks and I can just hit the ground running with it. Whereas if you already have 20, 30, whatever applications or hundreds or thousands of applications, if you're an enterprise, then you have to try to say, "Okay, how do I maybe fit this new paradigm into the tools that I'm already using?"

Paul: Yeah. So that's always, the migration path is where the rubber meets the road. All of the tutorials out there for serverless are greenfield, like you said. And I'm trying to create some better examples of say wrapping your existing applications with serverless components. There's a very famous architecture style, what's it? It's a strangler pattern. Are you familiar with it?

Jeremy: I'm very familiar with it. Yeah.

Paul: I like to call it... For anybody else who knows about it, I want us all to start thinking about it as the hugging pattern instead. I think strangling is just too harsh for these applications that have worked for us for so hard for so long. We don't need to strangle them. What we need to do is hug them. And so I want people to embrace the hugging pattern. And if you're watching a video, I'm like hugging myself right now. Where you take your old application and you lovingly wrap it in serverless functions. And you take that application and you give it to people who are systems engineers, and who are really going to take care of it. You're going to make sure that it's stable, and that no one else is going to mess with it and that it gets to live out its life making HTTP requests until it can't anymore. Meanwhile, you've built a support network around it to handle all of this incoming messy HTTP traffic.

And one example I did of that, was I had another one of my early websites that I had built. And it was still running a PHP LAMP Stack VM somewhere on DigitalOcean. And all it was doing was catching a single form. It was a contact form. And I didn't even know how to write PHP at the time. Okay? I just copied and pasted PHP.email, and it's like 40 lines. I cannot read it. I don't know what it is. It's a lot of brackets, and all it did was send me an email when someone filled out the form. And I was like, "Man, this has been five bucks a year for the last five years. Why am I doing this?"

Jeremy: Right, right.

Paul: And so I just rewrote it. The front-end's all the same. It's jQuery. It's really, really advanced blazing jQuery. And I threw it in an S3 bucket, I put it on Begin and I built a single function that now sends me a Slack message when someone fills it out.

Jeremy: Right.

Paul: And that's better than email. Because that email account, it's the only one email account... You can combine and bring new life and really hug your old applications to give them the life that they deserve. They're working for you, non stop without complaining. You should give them a hug, not strangle them. But anyway, that's my big point for the day. It's hug your servers man. I don't find serverless as a like, "I hate my server." I find serverless as, "I love my server." I love my server so much, I want to let it go.

Jeremy: A corollary between like sending your grandparents or your parents to a nursing home. It's like that. Give them the support they need, but eventually-

Paul: Exactly.

Jeremy: ... you need other people to take on those responsibilities.

Paul: Exactly.

Jeremy: The thing you said about moving that one server that was costing you $5 a year, whatever it was, and just to capture a form, for example, that's the kind of thing where I think if you explain it to someone like that saying, like, "Hey, I had a whole computer setup or a whole server setup, just to catch a form, because I needed to catch a form. And now all that's gone away to a point where I never have to worry if, one, the page that serves up the form itself is still there, or two, whether or not the infrastructure is still going to be running to support capturing that form on the back-end." That is something that I think, personally, is quite magical. It's a really interesting thing. And I say that because you had a presentation you gave at Serverlessconf New York, and you said that serverless developers are magic makers. So I'd love it if you would just give me a your opinion, why is serverless so magical?

Paul: So in that presentation, I did a real time demo of Serverless WebSockets.

Jeremy: Right.

Paul: And that is the most magical experience I've had in technology is when I was creating persistent connections between clients and users, without having to write or stand up a specific WebSocket server. So I didn't have to write any of that logic to handle the connections at a network level. I still handled connections in my applications. I am fully in the application level responsible for everything. But at a network level, all that has been advocated. And so what is magical is the experience that developers can create for their users. I think that is magical. I think it's magical when we get past all of the technicals. And I think it's magical when humans decide, "Oh, I'm going to make this application. And it's going to help someone find their perfect 'whatever.'" And that ability and that power, that is magical for us as developers to say, "Yeah, I can create that. I can create this next thing, and it'll make somebody's life a little easier." And that is some power. And that is the magic that we should respect, for sure.

Jeremy: Totally agree. Totally agree. So another thing that I would have to say is quite magical, and I'm sure you would agree with this is when you watch Nicolas Cage in a movie, I mean, you're just transported. You've just transported.

Paul: Yeah.

Jeremy: You have a, I would say unhealthy obsession with Nicolas Cage and maybe that's just my opinion. I mean, just you incorporate him into your presentations, which I think is great because again, it gives people something to connect on. And when you see boring presentations that are just going through the bullet point after bullet point, I know I give a lot of presentations like that, I'm like, "I can't believe people watch these." But the interest in Nicolas Cage, what's that all about?

Paul: I have been so blessed and fortunate that I can continue in this career, while also serving and worshiping Nicolas Cage. So as we mentioned earlier, I'm a self taught developer. And I also don't learn things super easy. So I have to come up with good excuses for why I need to learn something, to myself. Whenever you want to learn something, I'm sure something drives you. The thing that drives me to learn is using Nicholas Cage, honestly and truly. When I want to learn something new, I think, "Okay, how can I make this ridiculous by adding Nicolas Cage?"

And so when I'm testing out, say a static website builder and I got to build a blog, I could read through documentation. Yeah, I do that. I could do their tutorial. Yeah, I could do that. Or I could build a new Nicolas Cage blog and then spend an hour or so looking for interesting articles to put into my blog. And now all of a sudden, I've got not just a blog, I've got a blog with content and it looks really cool and I learned something about Nicolas Cage, and I built it all from scratch and well, now I've done the thing. And I do that for every single thing I've done.

My very first Nicolas Cage project was a React.Component when I was like, "Man, I need to learn React. It's probably going to be a thing." And so I made one component inside of a CodePen, where every time you clicked it, it went and got a random gif and made it bigger and bigger and bigger and bigger until it took over the whole view port, and then it shrunk down again. And then it got bigger and bigger and bigger. And it was like it just did this over and over again. I was like, "Wow, look at this. It doesn't refresh. This is just updating state on its own. It's manipulating its virtual Dom thing. This is really cool." And I never built a to-do app with it. I just built these silly things.

And Nicolas Cage is there because there's nothing else on the internet that has as much source material as Nicolas Cage. I promise you, go and find another bit of source material in popular culture media that has as much wealth of information as Nicolas Cage. And the only thing I can think of were the Simpsons, and that's about it. And that might be it. The only other longest running television show on the planet.

Jeremy: Maybe Kevin Bacon. Kevin Bacon's got a lot of stuff around also.

Paul: So Kevin Bacon, but it petered out. What was the last thing you ever heard Kevin Bacon do? I'm not sure. It's been awhile.

Jeremy: That's a good point. Right. That's a good point.

Paul: But Nicolas Cage is continuously evolving. He's continuously doing bigger and crazier and badder things.

Jeremy: Right. Well, hopefully we didn't lose too many people on the Nicolas Cage thing. But I know you're a huge fan, so just quickly, favorite Nicolas Cage movies?

Paul: There's so many good movies. The current favorite is obviously National Treasure. Can't beat National Treasure at all. It's just a wonderful, wonderful movie. For the deep cut, I like Vampire's Kiss because that's where the memes start. And that's where we get a lot of his craziness. I think Ghost Rider and-

Jeremy: Oh, yeah.

Paul: ... Con Air. And his big-

Jeremy: Oh, Con Air was a good movie.

Paul: Yeah, yeah. And The Rock. Common on.

Jeremy: Oh, yeah, The Rock. Wow.

Paul: Yeah, yeah.

Jeremy: Yeah, you know what? I've got to rethink this whole Nicolas Cage thing because there are-

Paul: That's right.

Jeremy: ... some good movies in that catalog there.

Paul: That's right. That's right. Yeah. He has 100 movies. 100.

Jeremy: That sounds like a lot.

Paul: Yeah. And part of his working philosophy is that you wouldn't ask a baseball player to play less games. So why should an actor not be in as many movies as they can.

Jeremy: That's a good point.

Paul: And I was like, "Man that is amazing." Because we always think that if an actor does too many movies, it's because they need the money. But what if they just like acting?

Jeremy: Or trying to act? I'm just kidding I'm totally kidding.

Paul: Ah, there you go. There you go. You had to get it in a little bit. But that's fine, I forgive you. As a preacher of Nicolas Cage-

Jeremy: Right. Right.

Paul: ... I have it within me to forgive you for your transgressions.

Jeremy: I appreciate that. And you know what else I appreciate, Paul? I appreciate you being here and sharing your knowledge of not only Nicolas Cage but also about Begin and just serverless in general. I love this community, I love that people like you are in it and sharing these crazy things. So if people want to get in touch with you, find out more about Begin and other things you're working on, what's the best way for them to do that?

Paul: First go get and try out Begin at begin.com. Once you sign up for an account, you can build an app in 30 seconds or less by clicking two buttons. All you need is GitHub. Seriously, go try it. Second, I'm always on Twitter, Paul Chin Jr. @paulchinjr. Please, any questions about Nicolas Cage or serverless or Begin or food. Yeah, I'm a big food person too. So just send me a message. I love talking to people. And then final shout out to 757dev. They are my local developer community here in Virginia Beach in Norfolk, in Virginia. They've been incredibly, incredibly helpful for everything that I've been able to do. So I want to give a shout out to them.

Jeremy: That's awesome. All right. And I know that there's learn.begin.com as another-

Paul: Ah, yes.

Jeremy: ... training resource.

Paul: Thank you. Thank you. Yes, learn.begin.com has tutorials for building a lot of these serverless application concepts that we've been talking about. And not only will the tutorial teach you how to do the app, it'll deploy it. It'll show you where you deploy to. So your app will actually be live and not just sitting on localhost.

Jeremy: Awesome. And check out arc.codes as well if you want to see the Architect framework. All right. We will get all that into the show notes. And I think we might have to add a new segment to the show where we ask people what their favorite Nicolas Cage movies are.

Paul: Please, please do it. I think it could be a good thing. I would love it for Cage to become a patron saint of serverless.

Jeremy: All right. Well, thanks again, Paul.

Paul: Thank you, Jeremy. I really appreciate it.

Episode source