Sessions is temporarily moving to YouTube, check out all our new videos here.

Serverless and You

Marcel Cutts speaking at London Node User Group in February, 2017
520Views
 
Great talks, fired to your inbox 👌
No junk, no spam, just great talks. Unsubscribe any time.

About this talk

Cloud computing services such as AWS, Azure and Google Compute have rapidly changed how we think and feel about our infrastructure. DevOps deployment is no longer copy-pasting a zip folder full of code onto a physical machine's network drive - and nothing is pushing the engine of change more than Serverless. Serverless allows us to create event driven node micro-services with absolute ease, perfectly fitting into continuous integration / continuous deployment workflows. It boasts a wide range of plugins, and more importantly, allows us to effortlessly scale any number of stages to the nth degree. Is Serverless for you? Quite probably! Lets find out.


Transcript


Yeah. Hello, everyone. Hope you've all got beer. Hope you're all settled in. We're going to go on a crazy-train ride of Serverless, the framework and the architecture. Hooray. Okay. So most of you have probably seen the term, Serverless, scattered around the web somewhere. You've seen it in some hacker news thread, or you've seen it tweeted by some guy in a beanie, riding a fixie. You're like, "Oh, what the fuck is this? I have no idea." Wait. Can I swear here? Too late now. So you sit around, and it mills around the back of your mind, the importance of Google Trends. You go, "Oh, no. It's got a hype curve. Soon, people will want to have it on their CVs, and I need to get involved because I like being employed." So you have questions, like, "What is a Serverless? How do I get one? And is this one of those things that we all think is a good idea now, but deeply regret later, like OOP?" Answers to this, and more, coming up. All right. First, a bit of disambiguation. Right? So there is Serverless, the framework, and Serverless, the archicture style. Serverless, the framework, helps you make applications, using the Serverless architecture style. But to understand what Serverless, the framework, offers, you first have to talk about Serverless, the architecture style. With me? Great. Bit of history about DevOps. So in the olden days, if you wanted to make an application, you'd write a code. You'd feel proud of yourself. You'd want to share with the world, and then you think about where you're going to put it. So in the olden days, it was a physical machine. Maybe it's under your desk, or maybe it's in the cloud, which is just someone else's desk. You would SSH in, maybe. Set up the operating system. Put in all the bits and pieces to run your application, which is fine, and you patch all the things you need to, and you set it all up, and you set up the SSL certificates. You're like, "Okay. Okay. That's fine." Then you find, to your amazement, your application is quite successful. You get a second server, and you do it all again, and then you start to think, "All right. I might have to write a script next time I do this." The third time comes around, and you go, "Okay. Right. I've written a script." But even then, you still have trouble. You still have to update your box. You still have to make sure all your security patches are applied. Your Apache config breaks for no reason sometimes. Oh, god. The database is on fire because it's run out of disk space again. If you keep going, and your herd of computers keeps enlarging, you end up being a person who only ever has SSH terminals open on their screen, trying desperately to keep all your children from exploding, which is very sad. If you do it for too long, the madness will grip you, and you'll find you only ever DevOps from some dark basement somewhere, while gripping a bottle of whiskey, like this loser. So let's not do that. Let's do better. So at first, we thought, "Let's try virtual machines." They're good. Right? Because you can kind of get a snapshot of an OS in a certain state, before your applications are pre-set-up. You just fling those out into the universe like, "Yeah, great." Although, not that great, because you still have to put them on a machine somewhere. I guess you can have multi-tenancy. That's cool. But you still have to update the virtual machines as well because they, too, need to be updated with patches for security exploits and whatever. So okay. Let's try one better. So containers. Containers are rad. Containers, you can, like, spring up and spring down really quickly you can have quick deploys. They're much easier to test against them because they're much, much easier to destroy and spin up. So okay. Containers are pretty cool, but containers are still a bit tricky. You still have to host them somewhere, and they can be quite fidgety to put together and to put together right. I mean, anyone who's tried to set up a docker swarm will know what I mean. It's not a zero-friction process. So wouldn't it be great if you could just chuck your code, just the application bits you really need, into the void, have someone run it for you, with no need to think about exactly where it runs, how it runs, how to scale it? Wouldn't that be fantastic? Wouldn't it be even better if you could only...if you only ever had to write the bits to the application you actually care about? You don't have to write a registration system. You don't have to write a stupid data layer. Well, with Serverless and back-end as a service, this could be true. So how on Earth does that work? Well, here's kind of a traditional application. Let's say you open a pet store. I stole this diagram from Martin Fowler [SP], by the way. So no one tell him. He's going to be mad. So this is a [inaudible]. You have your monolith in the center. You have a client. It could just be some browser or some JavaScript or thicker thing, and some database where you store everything, your orders, your user registration details, your login details, as well as everything else you could possibly have. Right? It's fine. How does this look in a "Serverless" world? Something a bit like this. You might think, "Marcel, you idiot. This is much more complicated." But I assure you it's not. So for example, the only place we actually talk about... The only bits we write are these two, the purchase function and the search function. That's the only thing that's unique about our application. We can get this up very quickly. We use an authentication service that exists ,something like off zero or AWS Incognito. Because how many times have we written or installed a gem or something to have a user be able to put in an email address and a password, get registered, and then log in and have their email sent to them if they forgot blah, blah, blah. There's no value in this unless we are the back-end authentication service that we're providing to other people. There's no reason we should have to do this over and over again. That's not the value in our application. If you're building a pet shop, no one cares that your registration works. That's just something you have to do because it's important. Right? Things like API Gateway. We can use that and still have to do our own routine, which is a pain in the ass and something you have to maintain. Once you start to get legacy stuff, your route can get really esoteric and [inaudible] like. So let's not do that either. Let's just focus on these two things: the purchase function and the search function. We wrote those, and they are just functions that exist in the ether. When someone calls it, they appear. They run, and they give something back to the client, and then they disappear. If lots of people call it, many appear and then disappear. You only ever pay for the actual run time. When no one's using them, they're not there, which is fantastic because now we can focus on the part of the application we actually care about, rather than doing another crud app with a lot of setup. And it scales infinitely. You won't be working overnight. It just lets you write code in a very granular, non-monolithic style that lets you compose parts of your application very, very easily. More on that later. So service architecture. You can focus on the bits that matter. You can go straight to market, because there is a continuing war on speed in development. We want features faster. We want stability and quality faster too. In the olden days, deploying was just something you had to do. It was a week-long process. It could go wrong. One thing was hard. But yeah, let's just do it like this because then we can be quicker. We don't have to worry about stuff. We don't have to worry about maintaining it or applying patches because it's just a small piece of logic that we put in a function, and you get insane pitch to cred, which is what we really care about. Okay. So you might think like, "Wait a second. Isn't this just platform-as-a-service?" The answer is, "Not quite." So if you use something like Roku, they offer the ability for you to have your application hosted for you. So just chuck your Jango app or whatever at them, and they'll be fine. But it's not quite the same because it has a monolithic deployment. The great thing about Serverless function is UD...level of logic is the same unit as the... The unit of abstraction is the same as the unit of deployment. Whereas with Dino and that sort of thing, it encourages you to continue having this monolithic approach. So if you want to update something, you're updating it, but you're also pushing all the rest of the stuff again as well. So it's less granular, and you have less control about how this really works, and you're kind of steered of all your technical decisions because with landers and other functional... or other Serverless approaches, you can easily just use any polyglot languages, and it's great. Cool. And yeah, if you have any powers that can just appear and disappear in under 20 microseconds, just call it Serverless. So you're infused, and you go to the internet, and you're like, "Great. I know about this lander interface and AWS, and there's like a text box I can paste my code into. Right?" But then you start to think about it, and go like, "Okay. But how... My application is more than just one file. How do I bundle it? And what about configuration? And I need to monitor it and make sure it's not doing anything weird, and logging would be great. When I'm developing, I'm able to de-bug it, and we need to test it somehow because all these nice little pieces of functionality that are separate functions that can be deployed seem really test-able, which is great. But how do I test them?" Well, that's where Serverless comes in. It's kind of a package that wraps all those concerns and makes it very, very easy to have your infrastructure and your code set up, so you can launch products very, very quickly, or just experiment or run infinite staging servers or whatever you want, really. So let's launch something into the void. Right. Okay. Nice. Can you all see that, by the way? Is that big enough? Bigger? Smaller? No? Wrong color. All right. Well, I changed my editor to white background, black text, in anticipation, but I didn't do the same for my terminal. Sorry, people. Next time. Cool. All right. So let's make a thing. All right. So here we go. We're going to use Serverless, and we're going to create a node instance, a lander from a template, and we're going to call [inaudible] demo, and it's going to be great. Yeah, that's right. Got that console up. Yeah. So this is it. You can see that we have loads of cool things in here, like, "Invoke locally, deploy, deploy to function, logs, metrics." All that stuff you're concerned about, it kind of takes away. So let's deploy it. While it's doing that, we'll have a look at some of the code I actually made, because it hasn't made very much. Oh. Oh, yeah. Of course, restart a computer means... Sorry. Got to set my AWS profile to something else. Great. So now, it's up there, doing all these things. While it's doing that, let's have a quick look at [inaudible] demo. Right? Okay So you can see, actually, I only made a handful of files. So [inaudible] JS is just your lander function, which says, "Okay. Well, when I'm invoked, I'm going to give you a response that says, "Hooray. You know, everything's great. I work. I heard you." The really clever part is this Serverless yml which is the infrastructure part of your code. So you have... Each Serverless entity is like a component that has both the infrastructure and the code as a combined unit, which makes it extremely powerful and self-contained. So just to run you through it very quickly. You have this name for service. You have what provider you want, and there's loads and loads of helpful text here because it's one of the beginner templates. You want to use AWS. You want to use node. You want to have a function called "Hello," which is inside handler here, as seen. Yeah. When we invoke it, we just... When we get to it, we just want to invoke it. Nothing complex, whatsoever. Let's see how our deploy is doing. Hey, it's done. So what it's done here, it's zipped up the code. It's zipped up the cloud formation template it needs to make all the different parts of the infrastructure. It's put into an S3 bucket. It's executed. It set up all the AIM permissions for your user as well. So your lander can now touch all the bits of AWS that it needs to, in a very controlled way, and it's ready to go. So if you wanted to invoke it, we can just call the function and get like... Hello. Back from the internet. There you go. We have a lander function. It's live. It is infinitely scaleable. We can all go there forever. Okay. But you want to change it. Right? The whole thing about this is like it's supposed to be this amazing thing you can just change all the time. It's so continuously deploy-able. It's unreal. So let's do, "Hello." We just want to deploy the functions. We can do it individually, like this, which is a bit quicker because it doesn't do all the stuff like in S3 buckets and whatever because that's already been done. You're embarrassing me, Serverless. I am doing this from my phone. Right? The internet doesn't work. So be a little bit patient. Okay. Well, while that's doing its thing... Have fun. Cool. Right. So that's basically a very, very basic idea of then how Serverless could work, but it's not very interesting. I guess it's just an end point to get some data back at the moment. It's blah. The really cool thing is that, like, we are updating it. Whenever the docs will finish, it'll have been updated on the internet for everyone. So it's the... There you go. So now, if you were to go to the same URL, you get a, "Hello," [inaudible]. But you can see how this make... Stuff like this will make continuous delivery, continuous deployment, completely trivial. You don't have to patch into a container. You don't have some awful Jenkins pipeline. You just push, and your function is updated. It's amazing. Right? You can just make ones with different paths, with different API gateway configurations. So you can have testing and production, exactly same but with different URLs. It's really, really flexible and really, really compose-able and very, very powerful. So let's see something a bit more serious. By very, very serious is we're going to make an application. This is a lot of business value, that finds people's faces and replaces them with emojis. So we're going to take a picture like this. Here, you can see two of today's speakers in this photo. Johnny Arnold has a better costume, but that's quite all right. We'll let him off this time. We want this to happen. We want to read people's faces, get their emotions, and apply the right emoji to it. Now, you might think that seems like it could be a lot of work. No, it will do it very quickly. So this is going to be our architecture. Right? We're going to have an event in an S3 bucket, which is... Oh, we're going to have landing. This is an S3 bucket. When an S3 bucket gets a new picture, it's going to pick it up. Then it's going to shove it towards AWS Recognition, which is this new image service that AWS provides and do things like finding faces, reading emotions. It can also recognize stuff in pictures, which is really cool. Then we're going to come back to that. Based on that information, we're going to replace people's faces, because we have the position now on whether they're happy or not, with emojis. It's going to be great. I can... Can I just say, for a second, though, like, AWS Recognition is magic. Holy shit. Like, this joke is from 2014, about how it's impossible to tell the pictures of birds if you're a computer. And 2017 now. So AWS is ahead of schedule. Pretty amazing. Now, as an example, I gave it this picture of a Sparrow, and it was 97% sure that it was a bird, but it was also 97% sure it was a Sparrow. If that doesn't impress you, I don't know what will. This thing can tell species of birds much better than I can. Right? Yeah. Okay. So let's do some emoji face swapping. All right. So I'm going to take a photo of the crowd because I need some faces. That's right. We're going hard in the live demos here. All right. Everyone pull a face. Have different emotions if you like. Perfect. You're beautiful. Oh, it's still uploading. Come on. All right. While that's doing that, let's have a quick walk through about how we actually did that. So actually it's very, very simple. So you have a little handler JS as... Oh, a face-swap JS, which is just the same as before. This was actually very boring code. It's just a bit of crud where we get the image from the event here, S3 bucket being filled up. We detect the faces in the image. We process the image. We use image magic to just put the emoji on. It's actually like... You know, it's 200 lines, and most of it is boiler-plate, like, "Get the thing. Download the thing. Put the thing." Right? It's very, very trivial. The interesting part is how Serverless strings all this stuff together. But we have got the same thing as before. So you have AWS. We have Node 4.3, but we have a bit more now. So we have all these, "I am," rule statements, which lets you have stuff like, you know, "Okay. For this lander function, I want it to have the authority to use recognition and the detect-faces feature. Fine. And I want it to be able to go to this bucket name and put objects and get objects, because it takes the new photos out and put the processed ones in." Right? We can have a bit of help here. So we can use dynamic naming, just for sake. As before, we've declared the functions that we want this particular Serverless to have. Obviously each different function is a different lander. So we have a handler. We want it to wait at least 30 seconds because this can take a little longer to detect all the faces and do all the processing. We want it to have a bucket name and its environment variables, which extensions allowed, where the processed photos goes. Here's the event trigger. So events can be things like, "Hey. Go to this URL, and this fires." But it can also have other kind of events, as pictured here. So here, we wanted to look for objects being created in an uploads folder, in this S3 bucket. And when that happens, the face-swap function gets fired. Right? Great. How we doing? All right. We may have to call short on that demo, unfortunately. It's really cool as well. Like that was... I worked on that hard. It's pièce de résistance. Okay. So what we saw there, or what you would have seen, is you actually made something at back-end where you can put in a photo and use these back-end services to replace the faces of someone with emoji, based on their emotions, which, like, three years ago in the app store, would have been a number one seller. Right? That's there now. It can scale to whatever many people you want. You can update it whenever you want, very, very easily. You can hook that up to some native application. You'd be making quids in. So I will say that I did steal this emoji-face-swapping from a lovely man called John McKim. I'm not that creative. So give him some love. He's a very nice guy. He tweets really cool stuff. So the question is, like, with Serverless... It sounds great, but is it for you? The honest answer is there are some drawbacks. So you do have vendor lock-in. Right? Although, Serverless works with a number of services, like Open Whisk and AWS, and there's loads and loads of plug-ins. There's a really huge list of plugins that you can use to extend and give Serverless even more functionality. It does like... You will end up somewhere. Right? If you're basing it on services like recognition, obviously, you will have some lock-in. To be honest, the other online services aren't nearly as competitive as AWS. Like, Azure is garbage. I have stories about this, many, many stories. Yeah. So landers. They do expire because they appear, and then they run the thing, and they disappear. They are... The payment for them is based on how long they run. So obviously if you have a really long-running process, probably not for you. You do have an overhead increase because, obviously, lots of little services have to talk to each other, rather than have like one monolithic block with lots of local calls. One that used to be a big thing is called start time. So landers aren't always, like, primed, because that would be really unfeasible. So sometimes they have to start from called, and they could have longer response time as a result. But Amazon in particular is really really really good at starting them quick, to the point that unless you need sub-20-millisecond responses don't worry about it. If you do, you're, you know, a special case. I think for most of us, at least. So I will admit that me and my drinking buddies over at Red Badger have been using Serverless since its alpha, in production, for a fairly major client, and we... I was super, super hesitant about it because you have to kind of, like, ply control from me, using a crowbar. I still wanted to be able to SSH into something and really fix it if I need to. But it was amazing. Like, even though there's loads of API changes and lots of syntax changes. It made development so fast, and the client was so happy. We didn't just, like, end up just kicking them some containers and be like, "Here. You figure it out." You know? It was a very bespoke, very compose-able, very understandable, very granular project. You could easily push to anywhere you...easily update, easily control, easily monitor, without having to ever really have someone employed just to look after it, because that's AWS' job. So the trick to figuring out whether you're on the Serverless hype train is: do you have an event-driven application? It doesn't matter what the event is, as long as it's event-driven. Do you have a short-running task? Which is most of us, because most of us do websites that, you know, go somewhere, come back, usually in less than a second. Do you have your man bun-slash-fixie-bike to join the hipster crowd? If yes, you can join the Serverless hype train. All right. So that was a bit of ramshackle. Sorry. But thank you very much. Any questions? My friend in the front. - Yes. Fox. - Fox. - In bringing those, sort of classical architecture, and you had one database, products and purchases. On Serverless, you have two databases. I wonder why this distinction [inaudible]. - Oh, right. Well, I mean, the reason we have singular database is often for ease in traditional application, if we have to maintain them ourselves. But with each... So search function would be its own Serverless function. Right? And it will define that it needs like a Dynamo DB instance or something like that. So they each have their own personal database, and this is like a self-contained set. So they don't need to share. In fact, sharing is pointless. It just needs a small chance for stuff to leak between the abstractions, right? So yeah, this is [inaudible]. I think we would have separate databases too, in traditional applications, if it wasn't like a pain in the ass to keep spitting up more and more databases and having the communication work between them. - But if you have to make query on both then it's more complicated. - Oh, no. Then you just have another lander. It's landers all the way down man. I hope that helps you, my friend. - Just Serverless framework. - Yeah. - How does it deal with external dependencies? - Okay. So when you run lander inside AWS, it comes up to AWS STK standard but there are loads and loads of MPM modules you want to come bring with you, right? To have loads of those. You can have them tied to a node and express applications inside as a lander. Right? For a single thing. That's completely fine, and that can be very long. You can do stuff like web pack and whatever, and it will just bundle that stuff up for you. Serverless is part like... Part of its charm is there's application bundling, and it'll just shove it up as a single entity to the void with all your dependencies. - Sorry, not so much called dependencies, I guess, infrastructure dependencies. In your example of the face-swapping, you were using recognition. You were using and S3 bucket How did you build one? - No. They come... They're part of Serverless yml. You define the bits you need and give the permissions upon them, and they get made. That's the real beauty. Right? It's like your infrastructure and your code are together. So you don't have to ever go to the AWS console or do a drop down or whatever. Right? So in the case of here, for example, here we say it has like an S3 event, and we say we have like... This is the resource that exists. Right? So someone's got to make that resource. Serverless will take care of creating that resource for you, to make sure you have the S3 bucket available. - How do you provide the S3 bundle? - So you can, like... You can apply it separately. Or here, you basically just say the default is... You say like, "No configuration required." It's just an empty bucket with, like, one folder inside. But you can provide that separately. Yeah. So you can extend and compose your Serverless yml's as well to have more and more detail. This is like a very basic version. - You say that AWS lander competition is not high quality. So do you also mean over cloud functions? And if yes, why? - So Go Cloud is fine. It just offers a fewer array of products, I think. Whereas AWS has a very broad range. It can take care of nearly all your business needs at once. Sorry. I took a cheap jab because it's been winding me up recently. No worries. Thank you very much. If you need me, I'll be in the pub.