About this talk
Learn the one weird trick that allows Ian to save money and watch better basketball games.
Ian: [00:00] I'm going to start with an apology, which you shouldn't do in any talks but this is basically a talk about basketball, not about technology in any way, and my addiction to basketball. But people don't want to hear that usually so I have to thinly veil it in this kind of thing. [00:32] Has anybody here used serverless before? No. Good. Anybody into basketball? Excellent. This is my perfect Venn diagram. Excellent. Right, I'm Ian. I work at BuzzFeed where we do great NBA journalism and...I love this one. This is my favorite. [00:50] I've been there about five months now. As much as I do love the NBA content, I'm also super proud of some of the stuff they do. I really liked this quote recently, which was, "Whoever wins the election in America, BuzzFeed's already won because they've broken every story," which is great. [01:11] I'm saying this partially because I'm quite proud of it and mostly because we're a tech company and I'm hiring. We're hiring. If you ever want to some and work for us, let me know or talk to Sarah at the front and she will [inaudible] . [01:23] But obviously, let's get past that and get on to some basketball. I'll just start with a little story. I grew up as an NBA addict, however, the availability of NBA material in the UK is pretty poor. As a 10, 11, 12-year-old, however it was, you couldn't get NBA on TV. [01:43] But, I happened to be in Germany once skiing and there was basketball on TV and it was the Pistons versus the Spurs and I was like, "This is amazing. First time I've seen it. I will just choose the winner as my team." That's how it works, isn't it? [01:59] That's the rule. Detroit won so I became a Detroit Pistons fan and they went onto years of mediocrity whilst the Spurs went on to become maybe the best team of all time. Although I'm going to talk about serverless, take it with a pinch of salt because I historically have made quite poor decisions. [02:22] Anyway, let's talk about some serverless stuff. Serverless is essentially a way of storing your code in the cloud or in California, and invoking it in that way. I'm going to try to go through a sort of starter kit of serverless stuff and what it might be useful for. We don't use it as BuzzFeed, we have a completely different stack but we might start using it if I can get my way. [02:52] I'll talk about what it is. This is really what it isn't. Serverless doesn't mean it's no servers. Back in the day we had managed hosting. We had our own servers running around...then there's the cloud and this is... [03:10] When you're deploying serverless code, you're essentially deploying it to the cloud and usually it's through AWS and it's on a server. No doubt. The reason they say serverless is that you don't have to worry about that. You don't have to provision things, you don't have to care too much and you don't really have access to the server. [03:27] It's something that's also said a lot in its functions as a service. To me functions of service feels like, it can be this really small thing like it's going to return me a number or something, which is not that useful, but actually you can host whole applications inside serverless functions if you so wanted to. [03:45] You can host things like ImageMagick inside a serverless function if you really want to. For me, the most interesting part is this different pricing model, which I'll get onto in more detail but you basically pay for what you use rather than guessing upfront. [04:00] Serverless functions themselves are -- they have to be -- stateless. One of the great things about serverless functions is scaling is all taken care of for you. The reason that they can do that is that you have no state. You can't write something to disk and then expect it to be available [inaudible] function or whatever. [04:19] This allows them to scale them horizontally really easily and it allows them to have high availability because they push this out into all available [inaudible] . If one goes down, it doesn't matter. You can run this wherever you want. [04:31] You've got no relationship with the underlying hardware so you can't store something. You can't change the OS. You can't update the security patches. All that stuff is taken care of for you, which, as a front-end developer, I'm all for. [04:44] These functions respond to events because something has to call them. These events can be HTTP requests or they could be something changing in an S3 bucket. That can be an event or anything basically that comes from cloud watch. [04:59] That gives them a lot of power. This is where you can serverless. AWS Lambda is probably the most used one or most known about one. Google and Microsoft offer some other ones although they're in alpha and preview but I think they're stable-ish. I think people use them. Other serverless places are available. [05:18] You can serverless through two different ways and probably loads more actually but these are the two that I know about. One is Serverless Framework. It used to be called JAWS, if you ever remember that. And APEX, which is written by TJ Holowaychuk. [05:34] If you want the full TJ stack, you need to use this. Deploy your code via TJ as well as writing it via TJ. As I said before, because you have these events that you can subscribe to, like things changing in an S3 bucket or whatever, it's really good for reacting to events in your infrastructure. [05:54] Let's say, for example, you have this box that has a memory leak and you have to give it a kick every now and again to reboot it and it starts again. You can just use Lambda for that and you can make a button on a UI, which calls it. [06:05] That just has access to all your infrastructure and it can go and restart it for you. Every time something changes in an S3 bucket, you could react to that and, I don't know, make a gif out of it, whatever. We probably would do that actually, at BuzzFeed. [06:20] It's really great for sites with infrequent spiky in traffic and that is because of this different pricing model, which I'll get onto. But the fact that it just scales for you is fantastic. [06:30] Did anybody get an email recently from Glastonbury saying tickets are soon available? Anyone who has been on that site and just frustratingly pressed refresh 1,000 times, graph looks something like this in my head. [06:48] This is actually the graph of Hilary Clinton's site from the debate night the other day. This is from Fastly. I just stole it from them. Let's imagine it's Glastonbury. Over here you have all the really annoyed people who can't get to it. Probably what you would do...what I'm trying to illustrate by this green line is the amount that you assume someone is going to actually need. [07:14] You provision way in advance because how else are you going to know? You're going to have like a million people coming. Just spin up 1,000 boxes and hope for the best. You're guessing. You'll have some auto-scaling, which will help with this but you still have limits on that. That still takes a long time to spin up sometimes. [07:29] You might not get it right. The main thing for me about this kind of model is inside the green box where there isn't a spike, you're paying for stuff that isn't getting used. You have to do that but that's the pain. It doesn't even look like this box. It's probably more like a pyramid. [07:49] This is what Lambda is really great for, because the pricing model is done completely differently. It's done by the number of requests you take and there's a lot of zeros before the number here, which is great. It's done by the amount of compute time you take. [08:04] If you get the first million requests for free -- excuse me -- and you have a really fast function, you're basically running something very cheap. What I was going to say is it's actually beneficial. There's actually incentive for you to write performant code. That's the main game changer, in my opinion. [08:26] This is what a company called Parallax did up in Leeds. I was really into the idea of serverless when I heard it. I didn't really know much about it and I was hoping someone would talk about it at Front-end London but nobody did so I had to do it. [08:42] James who runs this company did the AWS summit in London and they talked about this project which is, "This One's For You," and it was the project they did for Euro 2016 and David Guetta. I hear you're probably big fans of... [08:57] I can't remember exactly. The app was something to do with, you make a song with him and it used ImageMagick to make your face go near his, I don't know. But, the main thing was that it was going to be advertised at half-time in the final. The World Cup final. You can imagine, it's just one massive spike and then everyone goes back to watching football. [09:18] They didn't really know what to do about that. They were thinking, "Right, we'll just provision loads of stuff. It's going to cost us a fortune. We can't really put all that onto the client as well because they're not going to want to pay for all this stuff but at the same time, we can't go down." [09:35] They rethought it and they used Lambda. They ended up spending more money load testing Lambda, just to be in the safe side, than they did on the actual stuff. It was a fraction of the cost. It wasn't thousands, it was hundreds or maybe low thousands. [09:49] I think this is fantastic and Glastonbury should definitely take this on board. I'm sure there's more to it in Glastonbury's stack but let's just say...So, anyway, back to basketball because we've have enough about servers. [10:02] I needed an idea or an excuse to use this technology to try out. Usually I get about an hour into new ideas and then give up and I made it all the way through this one. So that is something [inaudible] . One of the challenges of being an NBA fan in the UK is the fact that we're generally 24 hours behind. The games happen in the middle of the night. [10:24] As much as I would like to, real life gets in the way of me often staying up to do that. I spend a lot of my time trying to avoid spoilers the next day. If people mention basketball on Twitter, I have to unfollow them, which is a pain because sometimes, quite clever, nice people do that. But I can't risk it, especially around play-offs time. [10:44] One of the worst things that can happen is you've basically spent your whole day avoiding any information about basketball and then you get home and you watch the game and it's just the worst game. You spent all day being stressed out, trying to avoid anything. Someone said, "NBA," you're like, "Get away from me." [10:59] I wanted to make an app that sorted that out for me in my life, which would've been a big boon for me. Essentially, a terrible game in basketball is one that is miles apart. If it's close, it's awesome. If it's not, it's awful. Especially in the NBA. [11:17] I wanted to make this website. Wasitclose.co.uk. All it's going to do is, I'd go on there and it lists all the games and it says if they were close or not and then I know which ones to watch. Let's spin up some serverless to do that. I'm going to go through how I made this and hopefully it gives you enough information to get away and build your Wasitclose.com. [11:40] Right, so I'm going to use serverless, the framework and AWS Lambda, the provider. Other providers are available. You install it as a global and it's available as a CLI tool then and you can use this, you can write it all yourself or you can use these generators that they have built in. Here, what I'm doing is I'm just using AWS and OGS. We're giving it a path to NBA, which is just the directory. [12:10] This creates these two files for me, handler.js and serverless.yml. Handler.js is utterly boring but it does say, the point is, it returns. It works. We'll get something up and running. The more interesting part is the serverless.yml. [12:28] This declares all information we want about our serverless function, our serverless service. We say where it's going to run, you can add region and that kind of thing to the provider and then we just say, the function name is scores and we're doing to use the scores function that's exposed by the handler, the handler.js. [12:46] Not really that interesting. Then you run serverless deploy and it gives you some information. I create this. The YAML generates cloud formation, which is then uploaded to AWS and you get this function back. You essentially can't do anything with this function because there's no event that's bound to it to do it but you can invoke it via serverless itself and you'll get something brilliant back. [13:16] Already we're understanding this is literally just a function in the cloud. Let's add something more to it to make it a bit more useful. Let's add an event to it. Let's have an HTTP event. What this does is this changes the cloud formation to include API gateway in front of your Lambda. You can expose however many events you way. [13:36] You would do an S3 event in the same way here and obviously you can use post etc. Now when you run serverless deploy, you're returned an endpoint, which is far more useful. As this point, I was into it. I was like, "Right, I can use this for quite a lot of stuff. I just need a list of countries. I could just stick another Lambda function in and I've got an endpoint. This is quite useful." [14:01] Obviously, if you go to that, you get [inaudible] gunk. The next thing I want to show you is some resources. Let's say I want to have a picture of all the NBA teams on my page. Obviously, who wouldn't want that? I need somewhere to put those and so I'll define that I want an S3 bucket. This will spin up that S3 bucket for me, or if it already exists it will just say, "Good job," and return. [14:34] This is brilliant for me. It also sets up the fact that my Lambda function has access to this bucket. It has the rights it needs to sort it out. It does the same thing with APA gateway, and you can add things like DynamoDB here. Anything that's within the AWS bucket, you can do. It might get a bit more complicated the more stuff you're throwing in there. [14:57] The bucket is the simplest one I can show on here but you can do it all through this. I think this YAML to cloud formation thing, is really nice because I don't really like writing cloud formation. This is roughly my app. I put my face there because I'm the only user. No, there actually are, like, two of us. It's fine. [15:20] It goes to API gateway, it goes to my Lambda function and it's going to go to the score's API. I'll just show how that works. This is our handler.js before. Now it basically stays the same. This is kind of considered a -- I picked up one best practice -- this is kind of a best practice. That you keep these things very thin, which allows you to move between different providers and all that kind of stuff. [15:42] You keep all your logic out of this. What I'm doing is just recording the liv, which I'm going to include all my stuff in. In that liv, I have this get scores function and I grab the...this is going to be the end point of my scores by this dude who was a bit of a legend because [inaudible] without him. [16:01] [laughter] Ian: [16:01] I'm going to request that and do something else. If I get an error, I'm going to return that and by far in that callback with an error, that's going to send the 500 back to API gateway. It's also going to log all that stuff in CloudWatch for you, so you have CloudWatch logs how the box...which is nice. [16:21] And if I don't, I'm going to return and compare scores, whatever. That's going to return to .json, which looks like this. The names of the teams and whether or not it's close enough, which is all I really care about. One sec. It was quite a close game. [16:49] One issue with this in the moment is that this scores API is rate limited. When I get peak traffic on this app... [16:59] [laughter] Ian: [16:59] I have to put a cache in between it so I just stuck DynamoDB in there, which is not a cache but I just used it because I happen to know how to use it. It was simpler at the time. To do that, all I did was just put another resource in there. In the same way I did in S3. [17:14] Now what I do is I check Dynamo to see if we have it already. If not, I'll go to that Erikberg API and then if I get that back, I'll store it in Dynamo. Now I make one request per day pretty much, which is great. Erikberg. [17:26] [laughter] Ian: [17:28] I have my thing but at the moment it's just json. Who wants json for their close NBA game? You want something real so I'll stick an S3 [inaudible] in there, which, again, I hadn't done this before. I didn't know that you could just make S3 buckets into websites really easily. You just click on name a website hoster and you stick an index.host on there and you're away. [17:54] I thought this was great. The only problem with this is that we have this really crappy domain, which no one's going to go to. I'm basically going to the end of this app at the moment but I just threw in Route 53, which is the DNS provider that Amazon providers. I went and bought a domain name, which was by far the most expensive thing in this entire project. It cost me £9. [18:19] I think my fees so far are around, like 60 cents, the entire six months it's been running. With that traffic as well. That ended up with wasitclose.co.uk and it looks like this, which for me, that's exactly what I want. I get home, Portland versus Clippers was a close game, I am a happy man. Beer's out, feet up, we're on. [18:44] [laughter] Ian: [18:44] That's pretty much it. I just wanted to sum it up by saying life is tough but there are people like me out there who are trying to fix this for you. It's really easy to create your smaller, simpler services. Really easy. If you want it for anything, you can just throw some stuff in there, throw some data in there if you want to make it available for an API, and you're laughing. [19:11] By far the most important thing for me that takes it past the silliness and into something really, maybe quite game changing, is the ability to...it genuinely pays for write performant code and your only cost is how much you're actually using something rather than estimating upfront. That is it. That is the end of my thing. Thank you. [19:36] [applause]