Ep. #12, FaaS and the Benefits of Serverless

Brian Douglas: So welcome to another installment of JAMstack Radio. Here in the room with me, we've got David Wells, once again.

David Wells: Hello.

Brian: And then on the line we've got Ryan Scott Brown. Do you want to go ahead and explain what you do, day to day and how you got involved in the Function as a Service space?

Ryan Scott Brown: Yeah, so I work at Ansible on the cloud modules. Ansible's an automation tool and now owned by Red Hat, but previously its own start-up. And the rest of the time I work on the serverless framework which as you know, is a Javascript framework for deploying Function as a Service type things. And I've been in sort of Functions as a Service since the Lambda Developer Preview, roughly, and I actually got into it via static sites.

And I thought that it was really cool that you could just upload any binary and have your own sort of hosted generator instead of having to install it on all of your machines, you could just push it up, have the generator run Lambda. That is actually my first project with Lambda, was Hugo and static site generation.

David: Cool.

Brian: Yeah, so do you use that same sort of build situation using Lambda to host all your Hugo, today?

Ryan: Yeah, it's gone through about three revisions. It started as the original projects that I made as sort of a toy. And then the open source Hugo Lambda, and then Eric Hammond from elastic.com made a much nicer static site set up that used code build and code commit, so it was hosting the git repo build, the build in Lambda and then the files on S3, and then serving through cloud for all in one template, and so I'm now on that. So it's been through a few revisions, but still basically the same set-up.

Brian: Very cool, yeah, I'm a big fan of Hugo. I made the jump from jekyll and middle man, to now do Hugo. I wouldn't say full time but I'm pretty excited about it so my new projects all start Hugo.

Ryan: Yeah, and that's what serverlesscode.com is on as well, is that same cloud formation template.

David: I'm a Phenomic man myself.

Ryan: I haven't actually heard of that one.

David: It's all react, man, it's all react.

Ryan: Is it just react, does it just pre-render the react.

David: Yeah, so it just does the service side rendering once and pushes up to your CDN of choice.

Ryan: That's actually pretty cool. I'm a front end neophyte, but I can see the value in having a react type front end where you can choose where the rendering happens, and have maybe Lambda render things and then send them out and on clients that are more powerful, you could do it the other way round.

David: Right. And then the router picks up on the client side too, so you got the react router kind of single page app feel.

Ryan: Very cool.

Brian: Yeah, just seems to be there are new players in the static site generation game. As of late, it seems like for the longest time Jekyll has kind of been like the standard static site generator of choice, and we've got some new players in the game. I recommend checking out staticgen.com. It's maintained by Netlify mostly, it's open sourced, but it basically keeps a list of all the options for you.

David: Out there, there are like over a hundred right?

Ryan: Now, what does it use?

Brian: Yeah, so Netlify uses Hugo, but staticgen.com is actually Jekyll, because it's actually made in that era. And I think Jekyll, at this point, if you check out the site, Jekyll's number one and I think Hugo's like either number three, I believe. So it's up there.

David: Jekyll's definitely the biggest, and they have so many plugins out there too.

Brian: Yeah, it's a good community. But I guess to make this less of a static site generation show. Can you explain more about functions as a service, their use case and I guess their general use cases for why would you grab Functions as a Service?

Ryan: Let me explain how I usually run things on AWS before Functions as a Service, as sort of a baseline for the kind of work that I would usually have to do.

Brian: Yeah.

Ryan: And that tends to fall into two categories: it is the async worker type work, so your video rendering farms, your back end payment processing things, your general business logic, this has to happen eventually but the user isn't waiting with the window open work. And then your synchronous web application fleet of servers in and out of scaling group, waiting for a request to come in, and then pushing responses back out over HTTP, through a load balancer.

And Functions as a Service has sort of a place in both of those with things like API Gateway, and AWS you can serve the synchronous over HTTP method, and with Lambda combined with all the different event sources that you can get inside of AWS

You can turn Function as a Service into basically the only async worker that you need.

The most common examples of imagery sizing and I'm really sick of, "Hey, our own imagery sizer" examples of Function as a Service tools. But it is a good work out, because it covers basics that you need pretty much anywhere, which is blob storage, compute, and then an output mechanism, and then a way to send notifications.

Brian: Yeah.

Ryan: Which, if you put those four things together, you're going to describe most kind of back end async type applications.

Brian: Cool, sounds like imagery sizing is the to-do MVC.

David: It's pretty interesting.

You see how the events trigger each different thing in the pipeline, whereas before if it wasn't event driven, you'd kind of have to wire up all that logic yourself, and be polling for something.

Brian: Yeah.

David: But everything just kind of happens in sequence, it's very logical to look at and kind of grok.

Ryan: Yeah, and also imagery sizing makes for a really good demo, because you have something that is an image you can physically see, yes this definitely did something, versus, "Oh yes, I'm going to demo sending PDF invoices". Not fun. Not nearly as fun.

David: That is true.

Brian: I'm just thinking of a good MVC for showing off Functions as a Service, sending PDF invoices. I think just because you've mentioned it, I'm going to go ahead and make that project a thing. But you mentioned Phenomic earlier David, but Gatsby is very similar to Phenomic so react based dark side generator.

Kyle Matthews, who started Gatsby, did a really good talk at the GraphQL Summit, about using GraphQL as rendering base C4 images, so doing that whole pre, not pre-rendering, but basically, literally pre-rendering like a base C4 image and then presenting the actual image itself, so you get that sort of anticipated loading state that's so popular on the front end.

So I don't know the actual implementation of what he's doing to use that, but I can imagine a good use case for Function as a Service.

Ryan: Yeah, because

With Lambda because API Gateway supports binary payloads, you can take an API request over HTTP and serve out an image based on that, so you can have a service that takes a resolution and then spits an image back out at the correct resolution.

Brian: Yeah, so like dynamic PNGs or SVGs.

Ryan: Yeah, it's not just resized 50 versions of this image, and then I'll get them by URL. It's, "I will take the URL and generate it on the fly and ship it back down to you".

David: A cool demo I saw that was another serverless tool, Claudia JS, it's git hub badges, so it'll based off your username, it'll generate that SVG and give you back a badge to put in your repo.

Ryan: Yeah, kind of like the Travis CI Style badges where it's got something on the other end and then it fills the SVG in with code coverage percentages and things like that?

David: Right, exactly.

Brian: So I'm just going to get down to our talking points. So using something as trivial as image resizing or whatever your user functions are, what are the cost benefits of using like Lambda as opposed to an actual server waiting for request?

Ryan: Yeah, so there's two. There is the direct, you're not paying for waiting for requests to come in. So if I've got like a smallish to mid size application, it's very likely that there's several hours of the day where you're getting five requests a minute, or zero requests a minute on average, then you still have to have a minimum of one server that a lot of people standardize on a minimum of two for fail over.

Brian: Yeah.

Ryan: And so you're paying at the smallest instance size, something like six cents an hour, I don't remember what the costs are exactly. But at the smallest size, you're still paying on a per hour basis, regardless of whether someone's actually using your thing.

And same thing for the load balancer, you're paying per hour for the load balancer to exist and be responding to requests and revving them. Whereas,

With Function as a Service with API Gateway or the equivalent with another provider, you're only paying per hundred millisecond slice of runtime on an instance.

Brian: Right.

Ryan: And you can decide what size slice you get as well, so I did a calculation, because I like the unit picodollars per megabyte second. So the way that Lambda is measured is you pay per hundred milliseconds, and then the cost per hundred milliseconds is graduated based on the amount of memory you get. So if you get 500 megabytes of memory for a hundred milliseconds, that's X dollars. And then for 200 milliseconds, it's double the 100 millisecond cost. And then if you double the RAM, that doubles the cost on the other dimension, because you're increasing the amount of memory that you have.

David: Yeah.

Brian: Is there a chart or somewhere.

Ryan: Yes, I can include a chart that will make a lot more sense than explaining this, the picodollars per megabyte second.

David: Did you make this chart, or this like the Lambda pricing page, or something?

Ryan: So they have the Lambda pricing page. I did a post separately on how you can calculate the number of picodollars per byte second.

David: Interesting. I want to see where the flip side is, where it's like, okay, when is it actually more cost effective to run you're own EC2 instance? I know there's a level that you hit.

Ryan: Yeah, there is, and it's, I think 75% utilization on an M4.medium.

David: Okay.

Ryan:

You have to be pretty good at packing work on to a server to beat Lambda pricing per megabyte.

David: And not to mention the generous free tier, so it's like a million invocations a month for free, which is, most of my weekend projects and what-have-you, would never get anywhere near that kind of utilization.

Ryan: Yeah, you are ignoring the free tier, but for the sake of argument, let's just ignore that, and say that generally, AWS, since their packing both your application that might be getting five invocations a week, and a bunch of other people, they can save on some economies of scale, and then they put on a profit margin on top of that. So they're not giving it to you at cost. But given that so many applications have such low utilization, because there's only one Facebook, one Twitter, and one Google out there.

Brian: Until I build the next one.

David: Yeah.

Brian: So I think in the room, I think we all have, collectively, mostly Lambda experience? But what are the other players in this space as far as Functions as a Service, another, there's quite a few of them out there, but I'm not sure if they're even worth looking at?

Ryan: Yeah, so the way that I'd categorize it is

You have a couple kinds of lock in when you're talking about Function as a Service, because obviously no-one but Amazon can hook into S3 events

so if all your data's in S3, and you don't want to use Lambda, but you want S3 events, you're kind of SOL.

Unless you want to hook up to SNS, and then have your own custom handler, and do all this extra stuff, and deal with data transit out of AWS, which is going to cost you money. So let's leave all that aside, but the general players is, you have, I think it's just Azure Functions.

David: Yeah, Azure Functions.

Brian: And Google Cloud functions.

Ryan: Yeah, Google Cloud functions is only alpha, which I had actually forgotten about, because I asked someone else to try and run something in their account and they're like, "I don't have this, it's just giving me an error", and I guess it's because you have to sign up for alpha, and then they have to grant it to you.

David: Right.

Ryan: So I wouldn't even consider that because it's really unlikely you're going to want to run anything on an alpha version that actually needs to run. And then there's Open Whisk, which is IBM's open source Function as a Service, and it relies pretty heavily on Docker and both you can get it as a service in Bluemix, which is IBM's kind of infrastructure and Software as a Service amalgamation.

David: And fun fact about Open Whisk, it just was added to the serverless framework. So check that out.

Ryan: Yeah, I saw that. You guys need to label that, because I don't recognize the Open Whisk logo immediately.

David: I was just thinking about that today actually, thank you for also corroborating my story.

Ryan: Yeah, because the AWS logo that's on the docks says Amazon Web Services.

David: I saw that toady, I just got back from vacation and I saw that, I didn't put that out, so I gotta go back and fix that.

Ryan: Yeah, you gotta take a page out of bat labels, label everything. So there's that, and there's also a crop of Kubernetes based function as a service, which are on Kubernetes, and then have various APIs and invocation strategies, and I feel like that's the space that's going to be really fragmented. Because there's, currently, function, fission, I saw another new one today, and I've already forgotten the name.

David: And this is all running on Kubernetes?

Ryan: All of these are running on Kubernetes, yeah.

David: It seems crazy to me, you know, you got the manager Kubernetes fleet. I don't know, it seems non-serverless to me.

Ryan: Well, it depends what part of the word "serverless" you're trying to get, because as you know, there have been companies that have started using serverless as a company name too, which kind of makes it confusing.

David: Guilty.

Ryan: Yes. And there's a lot of confusion over what people mean when they say "serverless". Do you mean, "Oh, this is Functions as a Service"? In which case, you can do basically the open stack version of that, which is run Function as a Service and provide that API, but provide it using your in-house ops team and expose it to your developers, and to them, it's the same.

David: Right.

Ryan: Because they get the same level of self-service and all that fun stuff. So in a sufficiently large company, running your own Kubernetes is serverless.

David: Right, indeed.

Ryan: In a four person company, it is not serverless, because one person probably...

David: Spents a year setting it up and then running it, yeah.

Ryan: Kubernetes is not that hard to set up.

David: I know, I've giving it a hard time. Another one that I would also through out there is webtask.io from ALT ZERO.

Ryan: Oh, I was unaware.

David: So very kind of similar set up.

Brian: Yeah, isn't that preview?

David: They don't really talk about it that much, but it's very similar to Lambda. I think it's a little bit harder to actually deploy code up there, they have a web GUI, and kind of a limited subset of the node ecosystem that you can use.

Ryan: Yeah, they don't let you customize libraries unless you use like web pack to dump everything into one Javascript file.

David: Yeah.

Ryan: Which not recommend cause they also have a size limit, which is smart, I'm not saying they need to remove that. But there are limitations there. And then pub net blocks is one that I've actually been playing around with, it's very different, because it doesn't have like the API Gateway style front end, or a lot of integrations for incoming messages, because it just leverages the pub nub messaging systems. So anything that can hook up to pub nub messaging, you can hook up to a block that'll then run.

David: Interesting. Definitely, AWS, like Lambda's the biggest player in the space.

Ryan: By a really wide margin.

David: But it's really intriguing to see like all the other players like, I think they're heavily investing in that, because they see kind of the benefits, whether it's cost savings or ...

Ryan: Yeah, also in the not actually serverless realm, Azure has a program where you can buy a giant instance and then point web task to it, so you're running web tasks, but you're also selecting the instance and so if you need to chew through a huge number of jobs, you can run web tasks on servers that you provision, so if you need like a GPU, or something. Which in Lambda, there's no real answer for. If you need more than, I forget the max ram in Lambda, I think it's 1500 megabytes. If you need more than that, you're SOL on Lambda, whereas with Azure you can just buy a bigger machine and then shove web task on it. Same thing with all these open source ones too, because you're selecting where to run it.

David: Indeed, and if you need a job longer than five minutes.

There's weird workarounds with Lambda, but it's not super straightforward to run a really long-running task.

Ryan: Yeah, the best solution I've found for that is actually to use ECS, because you can kick off a Lambda function and then if you have some kind of an evaluation method, and you can evaluate whether a job's going to take a long time or not in the Lambda, the Lambda can then kick off an ECS task to do the job, if it thinks it's going to take too long.

And so you end up with the same code that's running both in Lambda, and on ACS, and you can deploy them in tandem. It's actually pretty cool because the container registry tag, you can sync it up with the Lambda version, so version four on both of those can be the same code.

David: That is interesting, I saw, this might have been from Reinvent or something, but it was Netflix, they were talking about their video basically transcribing pipeline where they would take a video uploaded by a movie studio XYZ, break it into tiny little chunks and then basically do parallel processing and all these different Lambdas and then put it back together on the other side.

I thought that was pretty interesting, and then like another kind of use case of Lambda to basically spin out an infinite, and I'm doing bunny ears, infinite kind of number of processes to come together to do one job. So that's kind of interesting.

Ryan: Video is one of the, I'm not going to say easy, because obviously, at a sufficient scale, all easy problems are really hard. But

Video is an easier problem to break up than a lot of others because ultimately, you're sending one frame at a time.

And the smallest unit you can break down into is a unit of one frame, or I guess for some encodings, the interval between key frames is the smallest unit, it depends.

David: So you heard it hear first, Netflix, easy! There's a ton of other use cases we haven't really touched on.

Ryan: One that I wanted to talk about is, just today actually, AirBnB released a new project called Streamalert, that's basically an ingester over a couple of different service options that will do alerting rules over arbitrary data. So you can take in, Kinesa streams, SNS, S3, direct API hits, log stash, and it processes it all in Lambda, and then can send out alerts based on rules that you select to web hooks, Slack, other S3 buckets, Pager Duty, whatever.

David: Wow, that's pretty cool. They just released this today?

Ryan: Yeah.

David: Nice.

Ryan: I was reading about it while I was eating lunch earlier today.

David: Yeah, looks cool.

Brian: Sounds like there's a lot of stuff releasing in the last 24 hours.

Ryan: Yeah, there is a lot happening. Obviously, just yesterday, serverless released V1.6. There's, as I mentioned that Kubernetes function as a service that was, I was reading that yesterday. There's a lot of stuff that's more stable.

Brian: Yeah.

Ryan: But I think that

What's interesting about things like Streamalert, is since you're not running any servers or long live resources, it's just resources and AWS like event hook ups, functions, and configuration. It makes it a lot easier to distribute open source software when you've limited the runtime environment in that way.

If that makes sense. Because now you don't have to worry about, "Oh, they want to run it on Ubuntu 1404", versus, "I developed it for Red Head Enterprise Linux 7", versus, "My friend develops on a Mac", versus, "Someone else has an Ubuntu VM, that hasn't been updated in four years, and they want to run it there". It eliminates like an entire class of problems, which I think it's kind of cool.

David: Is this Streamalert, from AirBnB, is it kind of like, it's pulling everything into a centralized log, like a Kafkaesque system?

Ryan: I haven't looked at the internals. I was just looking at their rule language.

David: Gotcha.

Ryan: Primarily, so it's not pulling into a centralized log. All the data hits their Lambdas, and then if it meets rules, it will trigger alerts.

David: Right.

Ryan: And so I don't know what they're using for scratch store under the hood. It's probably Kinesis, given that their instructions don't say anything about you having to set up anything in particular.

David: Right.

Brian: So yeah, David sent me a used cases for serverless, and functions. We mentioned a couple of them. One that I always think of is form processing, like being able just to process that form data. Seems pretty straightforward. It's the one use case I've actually used Lambda for. So actually, one of two. The other one, I almost said it, but Amazon Echo. I know their back end is all Functions as a Service.

Ryan: Yeah, if you've played with Lambda at all, it's actually ridiculously easy to set up an Echo scale.

Brian: Yeah, it's that simple, and it's like a lot of boiler plates out there too as well. Just to get started like, even if you don't want to write Javascript, like you just plug and play, your different words to say.

David: Yeah. I just got an Echo like maybe two weeks ago, and I still haven't set up a skill. I'm still like amazed at how good the speaker is, and I'm paranoid to set up my own custom skill.

Brian: I can image the use case getting more broader with IOT being more of a thing, like now everybody's got a light bulb in their house. Well, not everybody but a lot of people who went down the Echo route have light bulbs that are smart, and then etc.

Ryan: I feel like for me, it's going to be really hard to improve on the light switch. I don't know, I don't often find myself sitting somewhere and thinking, "Man, if only I could turn on the lights without getting up", that very rarely happens to me.

David: Yeah.

Brian: Ah, well you can live in my house then.

David: So I saw some Alexa skills, one was asking when the next bus was. And it would go and scrape an XML document from some Lexi API.

Ryan: Yeah.

David: And a lot them were around scraping, so going, which is kind of another use case which you can run Phantom Jess, or any kind of custom binary. Any with probably any asterisks after it. But basically where they would go scrape some data from a website, and then the Echo would say it out or whatever.

Ryan: Yeah, you can do all kinds of stuff. I have a Scikit Learn running in a Lambda, which is kind of neat. You just pack up the model, and the Scikit Learn library, and you're off to the races, it's pretty cool.

David: What is that? The psychic?

Ryan: Scikit Learn, it's a Python machine learning library. And depending on how detailed your model is, and your data size, so lots of asterisks, especially because of the memory size limit, and the scratch disk size limit. The scratch disk is limited to 512 megs, and then memory is 1500 something megs. And as long as your model fits on the temp space and your data fits in RAM in that size, you can do some pretty cool machine learning stuff.

So if you train the model outside of Lambda, so using ACS or wherever else you're training things, you can then pack that model up and then react to incoming events in Lambda, so you can make use of those triggers and save on idle costs and things. And then have your full model operating in Lambda.

David: Yeah, it's a good point that using Lambda or any kind of Function as a Service, it is kind of stateless, and again I'm doing bunny ears, but as Ryan's mentioning, there is a temporary storage and Lambdas do get reused, but you can't necessarily rely on that. So just be aware of that. But there is a temporary scratch-base to store temporary data or when you're connecting to a database, like Dino DB or what-have-you, opening that connection outside of the function can be reused.

Ryan: Yeah, there is some kind of technical scoping asterisks there, definitely.

David: Yeah.

Brian: I've been bitten by, if you don't delete things out of your temp space, you can fill it up. Like if all of your functions leave a one megabyte file in temp space and no-one's deleting it, you'll eventually fill up the temp space for that container.

David: Does that error out?

Brian: When you try and write to the disk with no space, yeah it does.

David: Yeah , indeed.

Brian: It's a real pain to track down too, because if you've got like 50 warm containers all serving functions, it's sometimes hard to figure out that all of these errors that you're getting have the container they're running in common. Because cloudwatch aggregates the log streams by container, but if you are taking your cloud watch logs, and shipping them to an external system like a Kibana log stash cluster, you don't see the log stream immediately, and so you don't always connect it immediately, if you're not thinking about it.

David: Gotcha.

Brian: One of my favorite use cases at least is like just setting up a chron job, so it's so easy to schedule Lambda to run every third Thursday of the month, or whatever, depending on your chron syntax ninja skills. But yeah, it's so easy.

I prefer the simple syntax for writing chron jobs, but yeah, it's just super easy, and you don't have this machine just sitting there idly. You're paying hourly, so if you wanted to set up some really simple reminder, you don't have to pay eight dollars for this box that might be running a bunch of different chron jobs.

Ryan: Yeah, I've used that for sending out emails to users, because users can schedule emails to go out and if you use SCS and Lambda, you can construct individual emails out of a template, and then Lambda will send the individual emails, with whatever customizations for each recipient.

Brian: Yeah.

Ryan: So you can build your own kind of, I'm not going to say Mailchimp-like, because Mailchimp has way more features than that, but if you just need to send out a form email and you're handy with templates, you can make a Lambda function that does that really easily.

David: There is a company called Moon Mail. Moonmail.io, it's basically like they're trying to recreate what Mailchimp does but at a fraction of the cost, because you're only paying for use.

Ryan: Yeah, they're another one of those open source software that you can deploy based on, in their case, a cloud formation template. Streamalert is terraform I think.

David: Ah, gotcha.

Brian: So chron jobs is the one thing that I'm still embarrassed that I still do on Heroku. I rebuild the same app every year, which is basically tell me the home game, baseball game in the bay. So I can avoid the bar. I think I've talked about it on the podcast before, but it's called "Hustlin'".

And I'm going to be rebuilding it again when spring training starts up again, and I have a chron job to tell me, send a notification to my phone to let me know if there's a home game that day. So this sounds like a really good use case for a lambda function, instead of paying for Heruku.

Ryan: Yeah, that would be perfect for avoiding the bar on home games, or making sure that you go to the bar.

Brian: Hey guys, how was the sports ball today?

David: That's a good idea. Like, are you paying for the Heroku instance right now?

Brian: I'll use it for the first half of the season. I've only got two years since I've lived in the Bay. So I'll pay for the first half of the season, because usually rain delays and schedule changes will mess up my entire scraping of ESPN.com. By the way, you can get all sports data from ESPN.com. because everything's in HTML tables, so super easy to scrape, and then basically I just need to update it to make sure that if days change and stuff like that, just the chron job just checks out for me.

David: Nice.

Brian: But it sounds like I'll be doing Lambda this year, for this season.

David: We got a good example, github.com/service/examples, there's a chron example with your name on it, man.

Brian: All right, really? It says BW on there?

David: I'll change it today.

Brian: Cool, awesome. So we're actually hitting pretty close to time, so I'm actually going to, we're not going to get to the last project, that Streamalert project to talk about. But if you want to mention for us, a pick, Ryan? But as overall I guess, I'll ask both of you guys, as far as Function as a Service, I think I might know the answer, but how do you feel about Function as a Service as a future? Do you think it's going to be popular to increase, decrease, stagnant?

Ryan: I think it's going to be getting a lot more popular, but I also think that the alternatives of running things yourself and also containers are going to. I feel like this is one of those situations where all of the players are going to experience growth, because the overall market is getting so much larger. I think it's a pretty safe bet to bet on growth for all three of those categories.

David: Yeah, I'm very glad you asked that question and you asked it in that way, because I have the perfect answer. I heard this was actually from South of Argover at terraform, you gotta ask a question like that, he was like, "Do I think serverless has a future? No. I think it is the future". I was like, and it was like a mic drop, and I was like, "Oh man, that was great!"

But no, in all honesty, yeah, like Ryan said, all these spaces are growing, and I think as it gets easier and easier for developers to kind of get over this initial, it's kind of an educational gap right now, like not everyone's familiar with using AWS or IMB open with Microsoft Azure, etc. So as that kind of education gap closes, more and more developers will start building their apps in this kind of event driven way.

Ryan: I think outside of an education gap, there's also a pretty big tooling gap, and things like monitoring.

There's a lot going on in monitoring, but I think that right now, if you have something that's really complicated, you're not going to beat the existing install on your server APM tools in serverless.

David: Yeah, there is additional complexity that comes with kind of breaking your ... Even if you're using microservers as four, and now you're breaking them into smaller chunks functions, like there's a little bit of overhead, but I think with increased tooling, hopefully that will lessen. I'm bullish on all fronts.

Ryan: Yeah, no doubt.

Brian: Awesome, so with that being said, we're going to move into picks, so things that you're jamming on, things that get you going. This can be tech related, non tech related, and David, did you have picks already?

David: I'm thinking of them, I have picks right now.

Brian: All right, well while you're thinking, I'll actually go first then. I'm actually pretty excited about the term progressive web apps. It came around at the Google Chrome Web Summit. Actually, if you are a progressive web app expert, please reach out and come on the podcast. If not, we'll probably have somebody on very shortly. But I'm getting into the idea of service workers, and also just in general, just like making sure my lighthouse rating for my apps are really good.

We just went through this process of upgrading a basically static, just a lot of Javascript that's happening in the app. But we just put it up against the lighthouse and improved it using Netlify's built-in features, and it was pretty straightforward, so I am very bullish, I think you can check out the Google Chrome Summit progressive web app to get the details, what it's all about. I think I'm probably going to do a conference talk shortly, or maybe at least a meet up talk, who knows.

Whoever accepts my talks. Please accept them. And then as far as that, I do want to pick a TV show that I watched, I binge watched actually, caught up really quickly, which is Doctor Who. I never heard of it up until two years ago, and yeah, I know people are probably like, "What?" But the podcast came out about two years ago called "Catching Up With Doctor Who", where they basically watch every episode of Doctor Who and kind of explain it. They actually fell off really quickly around like the beginning of Matt Smith's, which is like I guess the more modern Doctor, I think he's like number three?

Ryan: Is he the most recent? Or is he the previous?

Brian: He's the one before the most recent.

Ryan: Okay.

Brian: So basically, I caught up in like two years of all the backlog, and now I'm up to date. As of this year, I'm up to date with whatever the latest, the Christmas episode that came out this past Christmas. So I am now up to date, and I think it's kind of corny as far as a show and sci-fi, but because of that, that's what makes the show good. So it's got like a cult following, because of that as well. So if you're into sci-fi and cheesy British comedies, I highly recommend checking out Doctor Who.

Ryan: Yeah, they have some great humor, I love Doctor Who.

Brian: Cool, Ryan, did you have any picks?

Ryan: Yeah, I have two picks. Pick one, is Serverless Conf, which is in Austin, Texas, this April.

Brian: Is Austin at Serverless going to be Serverless Conf in Austin?

David: Probably. I think I'm going too, are you going Ryan?

Ryan: Oh yeah, I'm going. That's why it's a pick. I can't pick it and not go. And then my second pick is the International Rescue Committee, which is an organization that helps refugees that need resettlement and asylum in different countries.

Brian: Cool.

Ryan: Just given kind of current political climate.

Brian: David, do you have any picks?

David: Stalled enough, I actually found it. So I'm reading a book right now, this was published back in February of 2015 by O'Reilly, but it's called Building Microservices, but it's again addressing that kind of, I think educational gap of how you would actually break down a monolithic system into tinier pieces, which plays very nicely with this whole kind of serverless mentality we've been talking about.

And then the other pick is again, Phenomic IO. I don't work for Phenomic, it's an open source project, but I'm in love with this static site generator, and since you mentioned progressive web apps, it comes like out of the box with service workers.

Brian: Oh really?

David: So I was flying back from, I went to Cabo for my birthday. I'm not going to say how old I am, it's depressing, but basically on the plane I pull up serverless.com, I don't have wi-fi though. Boom! It's working, because it's all cached via service worker. So if you're ever on a plane and you want to read the serverless docs, you can.

Ryan: Well, if you're ever on a plane and you've loaded them up before.

David:But yeah, those are my two picks.

Brian: Awesome, I need to take a serious check out of Phenomic, they have a couple of boiler plates that out there that I built some quick templates. Just a proof I'm with Netlify. But I need to check that out. Also need to check out even more service workers. I like the idea of pulling up your app with no internet on your phone, and seeing something.

Even if it's something not useful, at least seeing something. So I think at least having something as simple as that, where you visit some site. You don't need to see like a, "Google can't connect to this page", but rather, same like you had no internet. So I like that use case.

David: Yeah, I think there's a Google conference coming up, and they're all about the progressive web app.

Brian: Yeah.

David: They're pushing it hardcore. Yeah, so I'm sure that I'll talk more about it there.

Brian: Awesome, cool. Well David, thanks for coming in and filling in.

David: Thanks for having me.

Brian: And then Ryan, thanks for coming in, talking about Functions as a Service. I think we all feel very educated now.