#50: Making serverless more accessible for frontend engineers with Swizec Teller

You can find Swizec on Twitter as @Swizec.

Check out his new book Serverless Handbook here and his blog at swizec.com.

For more stories about real-world use of serverless technologies, please follow us on Twitter as @RealWorldSls and subscribe to this podcast.

To learn how to build production-ready serverless applications, check out my upcoming workshops.

Opening theme song:
Cheery Monday by Kevin MacLeod
Link: https://incompetech.filmmusic.io/song/3495-cheery-monday
License: http://creativecommons.org/licenses/by/4.0

Transcript

Yan Cui: 00:12  

Hi, welcome back to another episode of Real World Serverless, a podcast where I speak with real world practitioners and get their stories from the trenches. Today, I'm joined by Swizec Teller. Hey man, welcome to the show.

Swizec Teller: 00:24  

Hey, thanks for having me.

Yan Cui: 00:26  

So, it's been a while since we met each other at which conference was that? Full Stack, Full Stack Fest?

Swizec Teller: 00:31  

I think it was a Full Stack Fest in Spain September 2019.

Yan Cui: 00:38  

Yeah, something like that. I remember we had a really nice dinner in that little restaurant. And with Ben and those guys and the food was amazing.

Swizec Teller: 00:45  

Oh yes. Yeah the food was amazing. And I learned never to order crab when you're doing a video interview.

Yan Cui: 00:52  

Yeah, you're busy just with that crab the whole time. That was funny.  

Swizec Teller: 00:56  

Yeah, that was ridiculous. Lesson learned, right?

Yan Cui: 00:58  

But hopefully it was good.

Swizec Teller: 01:02  

Oh, it was amazing.

Yan Cui: 01:04  

So I actually went back to the restaurant afterwards for lunch the very next day. But how have you been since then?

Swizec Teller: 01:11  

Yeah, I've been great, you know. I've been keeping busy. I changed jobs back then. I was working at a small startup. Now I'm working at a slightly less small startup, changed industries as well, went from doing edtech to doing health tech. And on the side, I've been keeping busy with producing courses and books and newsletters about the future of web technologies. So you know, been super fun.

Yan Cui: 01:36  

So speaking about keeping updated with future technologies, you are publishing a new book the Serverless Handbook, we're gonna get to that in a minute, but for now can you just maybe tell us a bit about yourself and your journey to Serverless and what you have been doing these days?

Swizec Teller: 01:52  

Yeah. So that's kind of crazy. I was just looking at writing a bio for my new book the other day, and I realized I've been programming for 24 years, which at 33 is a lot. Um, so I've I've kind of seen, I've kind of seen the whole gamut of Web technologies. I started back when PHP and LAMP was the future and the hot new technology. And I remember being confused, trying to learn JavaScript and front end development when half the Internet was telling me to use tables and half the Internet was yelling at me to abandon tables and use this newfangled thing called CSS. And everything should be a <div>. That was very confusing back then. Yeah. So I've kind of been on the forefront of those technologies. I, I remember learning JavaScript and this was just around when JQuery hadn't quite reached my side of the world yet because I'm originally from Europe, so we were a little behind. And I was like wrapping everything in a bunch of ifs to to deal with the five different dimensions that were around back then. So if you weren't around when JQuery was new, consider yourself lucky because you missed out on a lot of very painful headaches and to go forward, that's kind of how I feel about Serverlessnow. Back then, setting up a server, getting it to run on the Internet was a pain in the ass. I actually started running my first ever startup in college on my computer, in my in my bedroom. I begged my ISP to give me a static IP, which I still have memorized. So my mom is still using it, which is why I'm not going to repeat the IP in public. The apartment I grew up in has a static IP, so I am one of those naughty people who has contributed to the downfall of IPV4 and why we ran out of addresses. And yeah, just like keeping that thing alive and running was very fun. Like, you know, your mom goes and cleans your bedroom, accidentally unplugged your computer and your startup goes down and you're in college and you have to run back home to get the computer back up. And that kind of cloud computing fixed a lot of that. But it was still very difficult to work with, at least in my experience. I never enjoyed the DevOps side of things. I, I can kind of understand it and I can talk with people who are sysadmins. But when they start talking about Kubernetes and Docker and like, the other day, we started talking about Btrfs and debugging file systems and my eyes kind of just glazed over and I was like, No, man, I just want to build my business logic and focus on the application and on the important stuff like. I don't care about the plumbing, just make it, just make the water run, that's kind of where I think we've gotten with services that these back end technologies, especially the sysadmin side of back end technologies, has gotten to the point where I can just write a JavaScript function, put it up, and the technology gives me a URL where I can call that function and it just runs and works and it's cheap to maintain, cheap to keep going. I just love it.

Yan Cui: 05:20  

Yeah, it's funny you say that, because I've basically spent most of my career doing a lot of the sysadmin type of things. I always wondered why I’mdoing the same thing a hundred times. Every new project, every new API I've built, I've got to go through the same process of updating the machine image first, and then you got to think about, OK, what do I have to install on this machine. And then you've got to go through the whole capacity planning and then setting up load-balancers, setting up of auto-scaling groups and all of that stuff is just, none of it really matters to all. My customer wants to just have a, like a shopping cart. They can click and then put something into their shopping cart. That’s it. It's three lines of code, but it takes a couple of days just to set up the infrastructure so I can ship and the run that three lines of code is just silly. And yeah. So when I started working with serverless, very much feel exactly what you feel, that this is great. This is just letting me focus on the stuff that actually adds value, maybe not as exciting and interesting like technically, but it gets the job done. And that's all I care about.

Swizec Teller: 06:19  

Yeah. It's like I, I read this really cool book recently called Hackers, which is about the early, the early age of computers and the computer revolution. And serverless compared to twenty years ago or even ten years ago, feels like our computers now compared to like the 70s. For those of you who don't know the first personal computer, it was called the personal computer. You got it. And it didn't have any input devices. It didn't have any operating system. It just had eight bits and it took, once you got good at it, and once you stopped making mistakes with flipping those bits, you were able to start writing software after about 45 minutes to an hour of writing a tiny OS from scratch in binary code. So imagine if you try to start a new web app and every time you want it to open your VS code, you first had to get a computer from storage, install the operating system, install all of your dependencies, install node, install VS code and then you could start writing your project. That's kind of what old school servers feel like, right?

Yan Cui: 07:34  

Yep, absolutely. And I'm so glad that I don't have to do that nowadays. It takes me a couple of minutes to get a new API up and running and do what I need and then I can go and have my cup of tea and have dinner. 

Swizec Teller: 07:45  

Yeah, exactly. 

Yan Cui: 07:46  

Let's go to what we've been building with severless. You said you started a new... you are working at a new company now. What are you guys doing and how serverless fits into that picture.

Swizec Teller: 07:56  

Yeah. So I've been using serverless a lot for side projects because I think it's a great fit for side projects because usually you don't have Facebook level traffic right away and you have like ten requests per day or sometimes you have a thousand requests, you get on hacker news, you have thirty thousand requests, and then the next day you go back to zero. Serverless is a great fit for those kinds of projects because you're not paying when there's no traffic and you're not killing over and dying when you're on the front page of hacker news. Um, and I was, I was just checking the other day my entire AWS bill is about twelve dollars for all of my side projects and my entire side business, which is pretty cool when you think about it because... Yeah, like I think that's pretty cool. At the day job, we've been kind of transitioning towards serverless. It's a fast growing health tech company. We're building a, I like to call it like the vertically integrated health health care for targeted specifically at women. So we have in-person clinics and we have the actual technology running those clinics and then a lot of web UIs and virtual health stuff. And I'm kind of working on the Web stuff because, you know, I'm not a doctor. What we've done there has been really interesting because we transitioned from EC2 and some other stuff to being fully serverless. But because that transition is not trivial, like you can't just rewrite your entire app in AWS Lambda when you're growing at, when I joined in January, there were 30 of us, last I checked, there were over 100 employees, so that's like 130 percent, 140 percent growth in seven to eight months. As you can imagine, having time to rewrite our entire app in AWS Lambda and fancy-pants technologies was not really something we can do, but we we kind of took the middle ground of going to Fargate, which is still serverless, but lets us, let some of our more sysadmin oriented people deal with Docker and stuff, put it up on Fargate and then from then on it behaves as if it's serverless like you, it scales to zero, it automatically scales. And we don't have to, we never have to deal with the Kubernetes level of crap. But we still get the benefit of being able to package an entire Express.js application without any modifications and put it on serverless.

Yan Cui: 10:39  

Yeah, I guess with Fargate and containers you still have to worry about patching the OS and installing the latest security patches and things like that. But at least it takes care of a lot of the underlying infrastructure in terms of the EC2 cluster or the auto-scaling around that. So it does make it a lot easier compared to just running ECS because of the Vanilla ECS on your own cluster.

Swizec Teller: 11:01  

Yeah, and one of the biggest benefits with using Fargate has been that it also forced us to go to infrastructure as code. So we now have all of our infrastructure defined in config files and we haven't gotten there yet. But we're soon going to be able to have CI/CD pipelines that make new deploys and copies of environments for every PR and every branch, which is going to make it a lot easier to collaborate because the team is growing.

Yan Cui: 11:28  

Just speaking about health tech I am also working with a client of mine who's also in the health care space in the US. HIPAA is quite a big concern in terms of regulations and all the additional things we have to worry about. Are there anything specific that you guys have to worry about in terms of OK, because HIPAA compliance, we have to, we can't use certain technologies. For example, one that hit us was that we can't use Algolia. We had to use Elasticsearch, which has a lot more effort involved because Algolia to get the HIPAA compliance version, you have to pay, well, they were quoting us seventy five thousand dollars a year or something like that, which we just thought, Well, no thanks. Is there anything hitting you guys in terms of the actual complexity you need to take on because of HIPAA?

Swizec Teller: 12:16  

Yeah. So we, I'm not super involved on the HIPAA compliance side because I've been focusing more on on our front end technology because the whole migration happened a little bit. It was just wrapping up when I joined, but. I know that there are certain AWS services that we simply can't use because they haven't taken a checkmark that they're HIPAA compliant or they don't want to sign a contract with us. But it's mostly... the main complexity has been around like logging and monitoring, because we have to be really careful what falls onto the console, like you can’t just print an error because the error message might contain personal identifying information. And if that gets into your logs than storing it and sharing it and you are not HIPAA compliant anymore. So that kind of stuff has been fun. Well, in terms of actual hosting, we haven't run into too many problems. It's mostly been just, Hey, you can’t use that particular AWS service. You have to use that other one that is almost the same, but not exactly the same.

Yan Cui: 13:22  

And what about things like auditing? Every request and every response you send has to be audited so that later on you're able to find out if the data was sent back to the wrong people, the wrong people were able to see data, things like that. Is that something you guys also spend much time on tackling?

Swizec Teller: 13:43  

Yeah, we have certain things. So that almost sounds a lot like GDPR that nobody follows in the US. But yeah, we've had, we have a lot of stuff in our code base where for certain database changes, we keep a complete log of how that stuff has changed and who was changing it. In general, I think we're still working on a lot of the details of our compliance stuff. I probably shouldn't say too much there because I don't know the exact things, but I know that we hired a head of security and he audited all of our software. And the list of things we have to fix is about forever long.

Yan Cui: 14:23  

Sounds that fun. So I guess let’s circle back to your book, I guess. What's your inspiration for writing this book and what do you hope to deliver in terms of value and lessons to readers with this book?

Swizec Teller: 14:35  

Yes. So at my previous job, one of the projects I built was a data processing pipeline for logs. And the main thing I learned there is you should never, ever build your own distributed logging system unless that is your core business. It was fun to build and I learned a lot as an engineer. I would not recommend you spending time on that unless you have a really, really good reason. Just like any of the off-the-shelf tools. They're all amazing. But basically we built this logging system and it started swamping our rails and our postgres database. At some point, I think the distributed logging was about 60 to 70 percent of our API traffic. So not only was it that much of our API traffic, it also represented most of our database and we can get into why we stored logs in the database later. It was actually a good idea, I promise you, but it was like we had this table that was growing at one to two million rows per day where everything else was growing at about a thousand rows per day or ten thousand rows per day, so we decided to use serverless to take that, to extract that out of our, out of our Rails app and put it on serverless so that it scales better and we have more control over it. And we can also do provisioning better because like you mentioned earlier, demand forecasting is difficult with traditional servers. And when the problem with logs specifically is that they usually scale exponentially with your traffic. So if you get 10 times more traffic, you're getting 100 times more logging traffic from all of the engineers doing debugging using traces and stuff like that. So we wanted to put that on serverless and I. It was a project that ended up taking a huge amount of my time. I think I worked on it as like a day job side project for almost a year. We got it done in the end, but it was just a huge headache, not because serverless technologies are bad, but more because the Internet is bad at explaining them so far, like I, I spent a lot of time Googling and everyone was basically assuming that you've been a back end engineer for the last 20 years and that you know everything about sysadmin. And I, I got to the point where I was literally debugging my stuff and trying to figure out what's going on using GitHub comments on old PRs and bug reports. And I was like, this is ridiculous, like serverless is such a great technology. It's, we've definitely come to the time when anyone who can write JavaScript can write back end code, good quality, scalable back end code. But the serverless technology is still too inaccessible for most people. So I decided to write a Serverless Handbook which is kind of a combination of the why book, mindset book and a how book. So there's a couple of tutorials in there and how recipes for building specific things. But I didn't want this to be one of those things where you're like, great, I read a tutorial and now I know how to, I don't know, make pasta carbonara. But I don't know how to make pasta alfredo, because I learned nothing about cooking pasta. I just learned how to make the specific recipe. So the Serverless Handbook is designed to teach you more about the principles of serverless, of serverless computing, of how to think about back end, what kind of issues you might run into with working on the back end. And just it's more of the in general here's how to think about back end code, how to think about scalability, how to think about distributed systems. Specifically, I focused more on the Serverless Framework and AWS as the cornerstone and as a hook for helping you learn something practical as well. The goal of the book is that you get enough to get started, but you also understand what you're doing and have a broader perspective on how you can work with any sort of back end.

Yan Cui: 18:58  

And I guess you're focusing on the front end engineer so that, you are, I guess, your audience is, like you said, people who maybe haven't been an back end engineer for 20 years and an sysadmin for many, many years, but are someone who, given the fact that serverless is much more accessible, anyone who can write JavaScript can now write business logic and ship them in Lambda functions and they get scalability, they get security and redundancy and all of that out of the box, for people that can take advantage of that having maybe not been a full time engineer for a long time. So coming into serverless from the front end focus world, I guess besides some of the articles and education pieces, what are some of the more challenging aspects of learning serverless? How to use it? Maybe problems of Serverless Framework or other tools like that?

Swizec Teller: 19:46  

Um, the Serverless Framework itself is i think one of the, one of the coolest pieces of technology here because AWS is native tools are very confusing and they're getting better. They're working on it really well. But it is very hard to approach if you're not in the AWS world if you're not one of those hardcore sysadmins. Can be kind of daunting because there's a lot of weird configuration to write and Serverless Framework does a great job of abstracting a lot of that away and making the, I like to say that it makes the simple things simple, and the hard things possible. So it's a nice mix of being able to get get started really quickly. But then when you need more power, you can drop down a level and start writing native AWS configuration in the same files. What I think is, among the more challenging aspects of jumping into serverless, is when it gets into systems thinking and distributed systems, in particular, like, as front end engineers, we have some experience with async. And we are used to writing JavaScript, which is great, because JavaScript is a great fit. I think it's a fantastic fit for back end code, or specifically for serverless code, because it has fast startup times and relatively slim runtime. But when you're working in the browser, everything is very tractable. Like you can console log, you can immediately see what happened, you can go and you can see what's going on in in the browser. And it can be challenging to debug but everything is right there. Whereas once you go into the back end, you very quickly get into a situation where you just can't see what you're doing. And it kind of feels like you're doing everything with, you're touching everything with a 10-foot pole. To do a thing, you you try to debug with console logs. And then you have to go to your logging app and wait five minutes for the logs to actually populate. And then you're like, Oh shit, there's that errands. Like, it's very hard, it's harder to directly see what's going on. And when I was getting started, it was even more confusing, because the local debugging environment wasn't quite there yet. And I like that now the tooling has improved like you can, if you're writing simple AWS Lambdas, you can just run them locally like a normal function. And because it's just a function, it's less complex to debug, because you can put it in unit tests and mark the inputs and outputs. You can call them locally as if it's on a live environment. And the other thing that's nice is that because you have this infrastructure as code, you can deploy to production and just test in quasi production, which with traditional serverless is very hard. It’s kind of just finding all of those tips and tricks and finding somebody who will be like, Hey, here's how you do bug, here's how you do this, can be very challenging, because seems like everyone on the internet already assumes you know that. And then if you don't know it, they assume that you at least understand what you're trying to do. And coming from a front end or a beginner perspective, that can be kind of challenging, because you're like, I'm not even really sure what I should be looking for or where I should be, like, Where do I look to do this thing?

Yan Cui: 23:09  

Yeah, I think, knowing what you what you need to search on Google, for example, is a great skill. But then the if you don't even know what to search, how do you find the answer to the questions that you have, right? So I guess in that case, how do you go about figuring out things? Was there any particular resources that you find very useful for figuring out how to do it? Or do you just trial and error and found something that works for you?

Swizec Teller: 23:34  

So there was a lot of trial and error for me, especially once I got into into more of the reliability issues, because with distributed systems where you often run into things kind of just failing randomly. And that's why chaos engineering is such a fun term to Google, because everything is always failing. And we're not really used to that on the front end as much. In terms of resources, I got, like, I got a lot of help from just following you on Twitter and talking to you and just and like, following a bunch of people, Twitter people in the serverless space to kind of see what they're talking about. And kind of get a feel for the what are the different technologies that exist. I read a lot of random blogs and articles that I found online, I probably should have read a book or two, but I was always in that mode, you know, I'm just like, I'm gonna get it in the next five minutes. And then three hours later, I still didn't get it, but it still felt like I'm going to get it in the next five minutes. And when you're in that mode, it's sometimes difficult to realise, Hey, I should just stop and go read the book for three days, and then everything's going to be a lot easier. I know the Serverless Framework also has a really good, they have a really good development community and they have, they've put out a lot of beginner friendly articles, but they're not they don't really go in a cohesive pace. It's like you know, when you're learning something from Google searches and from articles online, it can often feel like you're looking at a bunch of random trees or fractions of trees, and then trying to extrapolate the forest out of that. Whereas with a book, you usually get the forest first. So you have a framework, and then you can dig into the specific details of different areas.

Yan Cui: 25:21  

Yeah, but I guess that's a challenge before reading a book or completing a video course or something like that, it's just that it's quite a lot of upfront investment you have to put in, I think it pays off long term, I do still like to very much like to read books, because there is some topics that books go into a lot more details and more and more, I guess, the insights that you can find in the couple of hundreds words blog post, but they do take a lot more investment in terms of time and energy as well.

Swizec Teller: 25:50  

And the nice thing about books is that they are more structured like they usually, books and courses, they usually guide you from a starting point to a finishing point, with maybe a couple of distractions in between. Whereas when you're learning on your own, especially when you're doing it online, you're kind of going breadth first, you're kind of just like going in a bunch of random directions, and then you're assembling it later.

Yan Cui: 26:15  

Yeah, and I think that's more I guess, more useful once you've got the basics. So once you understand the basics, and you just need to touch up on on specific topics, or go a bit deeper than the books, or courses that you've taken have gone into on very specific cases, or I guess edge cases, and blog posts are great for those. But in terms of the, I think you mentioned the Serverless Framework. And I think it's got really good documentation as well. And that was also one of the things that I found Serverless Framework have done a really good job. It's just whenever I need to look up how I can do this specific thing with a Serverless Framework we can always go back to the docs and the docs are, you know, they're quite concise. They're quite short, but it covers everything you need to know to get what you need to do done. There is not a lot, you know, 100 pages long of documentation just so that you find one line that explains what you need to do.

Swizec Teller: 27:05  

Yeah, they're basically the opposite of AWS documentation. 

Yan Cui: 27:09  

Oh, Yeah. Yeah. The amount of times I spent hours and hours reading documentation, only to find that there's one small paragraph that explains the specific problem I'm seeing. But it's it's literally a needle in a haystack that unless I read that and pay attention to that line, I would have skipped it. I just missed it. Yeah. Tell me about that. It is funny, one of the things that almost everybody that comes on this podcast complained about in terms of what they found difficult about AWS, documentation is always pretty high on the list.

Swizec Teller: 27:39  

Yeah, I was gonna say that AWS documentation always feels like it was written for people who already understand AWS and just need a API spec. So it tells you a lot about which functions there are, but it doesn't tell you a lot about how they fit together. 

Yan Cui: 27:56  

Yep, yep. And in that case, talking about AWS, and are there any other things that, you know, you would love for AWS to fix? That's a very popular hashtag on Twitter #awswishlist. What are your top three items for that? 

Swizec Teller: 28:13  

#awswishlist, I need to follow that hashtag. But the main one for me with AWS is that it often feels like they're kind of just throwing ideas at the wall. And they have, I don't even know how many services they have now. But it's like, everyone uses pretty much like the 10, maybe 20 different services. One of the crazy things is when you deploy with the Serverless Framework, and you like I built one function, it's 200 bytes, it creates 12 different things for you on AWS, because it's so fragmented. And so it's like, if you, if you ever start nerding out on Linux, you have a bunch of tiny utilities to do every small, little thing. And there's a different utility for each one. And each one has a different API and different arguments to use. And you have to combine them together to make it actually work. I think AWS needs a little, a few more of those higher level things that already combine all of the little, little details, because it's hard to do it yourself every time.

Yan Cui: 29:17  

Funny you said that because I saw a Twitter thread earlier. Someone was asking about as a front end engineer, what are some of the things that you found challenging about AWS, and that is one thing that comes up quite a few times that it feels that you always feels like you need to know five or six different things to get to do one thing from your perspective, like building an API, but that requires five or six different things to work together and it always feels like, Okay, instead of learning one thing and being to do and be proficient you have to learn five or six different things then you have to be quite careful in terms of how you configure them. And I guess, some of the tools and frameworks helps with that configuration because they have some sane defaults that you may not know about, if you do yourself. I guess it's that mental burden, the cognitive burden that you have to always know quite a few different things and how they connect to each other to be able to do one thing from the end user perspective.

Swizec Teller: 30:12  

Yes, like there's a lot of mental overhead with just keeping track of everything. They've gone really hard on the whole microservices approach, which is great. But in their case, they're almost like nano services. Everything is crazy fragmented. And it makes, it's a hard line to play with. Because it makes sense that every service would do a very specific thing, because you know, you need to do one thing and do it well. That's the Unix philosophy. But when you start combining all of those things, you get a lot of systems complexity and systems complexity, at least for my brain is much harder to deal with than having one function that's a little bit too fat, or is doing too many things. So with AWS, you got a lot of that system complexity, and it would be nice if they had more higher level tools.

Yan Cui: 30:59  

So what about in that case things like Amplify? Have you spent much time playing around with Amplify, because it feels almost like that's the kind of tool they are pushing right now for front end engineers who may be not familiar with all the different services, but they can just run one command to say, I want to add authentication to my application. And then it takes care of a lot of the underlying provisioning of and configuring of Cognito user pools and also gives, you know, view components that you can just use in your application.

Swizec Teller: 31:30  

Yeah, I, I've heard of Amplify, I've been following the conversations about it on Twitter, and it sounds like a really good idea. I haven't had the chance to play with it yet myself. It kind of seems like it's Amazon's answer to the growth and rise of Netlify and Vercel, which are basically that higher level service built on top of AWS.

Yan Cui: 31:51  

Yeah, Yeah, I agree. I think in terms of the implementation, there's quite a lot of difference in that Amplify, sorry Netlify and Vercel, they, they're completely abstracted away the fact that it probably runs Lambda, runs certain things under the hood for you. But I think with Amplify, you have got this kind of middle ground where you've got tooling that gives you nice abstractions to create resources, but under the hood is still using CloudFormation. So it's still bound by the same limitations and constraints that CloudFormation has, and there is some things, when you want to drill down and get more control, it becomes quite difficult. Because you don't know this whole layer of abstraction, like you said, with a Serverless Framework where you need to have more control, you can always drop down to the CloudFormation level, which is possible with Amplify. But oftentimes, I think people struggle to do that. Or is maybe the case that when you want to drop down, it becomes quite hard to change some of the preset, I guess, some of the decisions that Amplify already made for you. But some of that is the limitation on a part of the API service like Cognito. Or maybe it's probably for CloudFormation, as opposed to Amplify itself. But I do find that people still struggle to get out of or evolve away from Amplify once they get to a certain point where they start hitting some of the walls and limitations that Amplify has.

Swizec Teller: 33:18  

Yeah, that's the biggest problem with these higher level services. Like with both Vercel and Netlify, like you said, You, once you outgrow them, there's basically nowhere for you to go. I think Vercel doesn't even give you the public. Neither of them give you the AWS names for the functions and stuff that they deploy for you. So you can't actually access the rest of the ecosystem, pretty much at all. I haven't tried Amplify. But it's it's been a problem with generally a lot of these frameworks with every abstraction framework that I've used is that once you outgrow it, you end up being kind of stuck. And that's the one that's kind of similar to Amplify that I've used in the past I think is Firebase or Google. I don't know what they call it these days. They keep changing the name.

Yan Cui: 34:07  

Yeah, it's still Firebase. And then they've got the Firebase functions and other things around and Firebase authentication and messaging, and this whole set of services that have sprung up around Firebase.

Swizec Teller: 34:19  

Right. Yeah. So Firebase is great for getting started. It's almost like back end as a service, which is amazing. Until you want to do something that's a little bit different than what they predicted. And then you're just out of luck.

Yan Cui: 34:36  

Yeah, I guess that's, that's the price you pay for some of these high level abstractions. I've asked all the questions I had. Is there anything else that you wanted to tell the audience about? Things that you're doing? Any upcoming training or workshops?

Swizec Teller: 34:51  

Yeah, so I have the Serverless Handbook is coming out on March 31st. I'm not sure when this podcast is going to get published. So maybe it's already out by when you're hearing this. Yeah. So the Serverless Handbook i'm going to be probably running more workshops when the conferences get started again or just as everything opens up workshops are gonna become more fun again. I've tried doing them remotely and it's kind of just not the same. It's still fun and great that people can join remotely from wherever but it's more fun to be in a room with people and be able to discuss and nerd out about things.

Yan Cui: 35:26  

And I guess for the Serverless Handbook, where can people go and get it?

Swizec Teller: 35:30  

Yes, so Serverless Handbook, go to serverlesshandbook.dev. It's going to be available on Amazon and basically my publisher said it's going to be wherever books are sold which is just cool. I've never been able to sell that to say that before.

Yan Cui: 35:47  

I guess that's mostly Amazon then.

Swizec Teller: 35:50  

Yeah, I guess it's mostly Amazon. We are going to try to have physical distribution as well but so if you know of a bookstore that focuses on technical books please reach out to me on Twitter. I'm @Swizec or you can go to swizec.com to read my blog and musings, sign up for my newsletter, that kind of thing.

Yan Cui: 36:10  

Cool. I'll make sure those links are available in the show notes so that anyone can go and find you easily and find the Serverless Handbook as well. Again, thank you very much Swizec for joining me today and sharing your story.  

Swizec Teller: 36:22  

Yeah, thanks for having me.

Yan Cui: 36:23  

Yeah, hope to catch you in person soon.

Swizec Teller: 36:25  

Yeah me too

Yan Cui: 36:26  

Take care. Okay. Bye bye.

Swizec Teller: 36:27  

Bye. 

Yan Cui: 36:41  

So that's it for another episode of Real World Serverless. To access the show notes, please go to realworldserverless.com. If you want to learn how to build production ready Serverless Applications, please check out my upcoming courses at productionreadyserverless.com. And I'll see you guys next time.