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
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
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
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
Yan Cui: 18:58
Swizec Teller: 19:46
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
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.