You don’t need servers, you don’t need roads, but you still need pants though, even though everybody is working from home now. You probably need roads too. Really though, serverless is the future and so today we’ll be talking about serverless architecture, what it is and why you would want to use it! Michael has been spending a lot of time developing in AWS recently and speaks about all of the cool things that can be done in Lambda. He talks about how lambdas are functions that run based on events that may happen, and how they can be used to do many cool things like automatically extract metadata from one S3 bucket to another. We get into some of the cons too, touching on best practices, costing, and cold starts. Lambdas have a limited running time which puts pressure to break tasks up into chunks and also creates a window after closing where they need time to start up again. On the plus side, you don’t get charged when you aren’t using them because they don’t have to stay on all the time. We speak about compatibility between cloud providers and also how all providers pretty much support any language – a great option for bypassing Kubernetes. Join in today as we speak about all of these and many other cool features that can be found in serverless development!
Key Points From This Episode:
Transcript for Episode 150. Serverless - Where Did it Go?
[INTRODUCTION]
[0:00:01.9] MN: Hello and welcome to The Rabbit Hole, the definitive developer’s podcast. Live, from the boogie down Bronx. I’m your host, Michael Nunez. Our co-host today.
[0:00:09.0] DA: Dave Anderson.
[0:00:10.8] MN: Today, we’ll be talking about AWS and becoming serverless. Where did the servers go Dave? Can you help me find the servers?
[0:00:19.8] DA: That’s the future, you don’t need servers.
[0:00:23.1] MN: You just don’t’ need them.
[0:00:24.1] DA: You don’t need roads, you still need pants though, you may still need pants, even though everybody’s working from home now.
[0:00:31.7] MN: Yeah, we’ll be talking about the serverless architecture and what it is and why you would want to use it. I’ve been working in the AWS lambda serverless architecture for the past couple of months and I’ve been having a fantabulous time. It’s been awesome.
I really enjoy using Lambdas to shoot these methods that need to get done for this product that I’m building at the client and it’s just a lot easier. It feels so great.
[0:01:02.4] DA: You're having a lot of fun with it?
[0:01:03.5] MN: I’m having like an illegal amount of fun right now. It’s been really cool.
[0:01:07.9] DA: Wait, you shouldn’t say that on the air. The fun police are so definitely going to get you.
[0:01:14.7] MN: Watch out to the fun police. Yeah, don’t tell the fun police you’re trying to work on the serverless architecture, that’s not cool.
[0:01:20.8] DA: Why is it so much fun? I – me hear serverless and it’s like, okay, it sounds very cryptic.
[0:01:29.5] MN: Yes,
[0:01:30.8] DA: It’s like okay, there’s definitely a server somewhere.You got to put the stuff on it with – it’s not a server, it’s like a Zen poem. It’s one hand clapping and all that.
[0:01:45.8] MN: It’s more like if you just – it’s like a server living in 4D. You don’t care where it is, you just hope that whatever API hits that server that it’s up when it’s available. I currently use Amazon as the platform of choice or the vendor of choice at the moment and the way that I see like — Lamda’s are functions that run based on events that may happen, that can be multiple events that your Lambda can be triggered by to run a script.
One example is if you have someone who uploads a file to an S3 bucket, a Lambda can be triggered to run some OCR and like extract metadata from that document and then put it somewhere else in another S3 bucket. You have access to all the metadata living in the file you uploaded is an example.
Another example is just like an HTTP request like if you decide you want to get a list of documents that exist in your S3 bucket, you can have a Lambda that will return a list of those documents given the path that you want to show the user however you design that Lambda function.
It’s a lot of fun, first and foremost, if you’re programming in something, chances are, Amazon supports that library and that language and that framework for you to build your application.
[0:03:10.2] DA: I don’t have to change like my whole life in order to try it out.
[0:03:13.8] MN: No, Amazon has like a set list that you can start up with. To my knowledge, it’s Node Python, Ruby, C#, Java, all these different environments, you don’t have to learn a new language to use lambda’s. Chances are, Amazon supports it. If you use the language that isn’t supported by Amazon via a dropdown menu where they can like, it’s very easily configurable, already configured, you can actually like, install the language to run when your Lambdas are triggered.
I’ve seen examples where people use Lambdas written in Elixir which is like something that Amazon doesn’t support but you could totally use that. I think another one is Go. I’m actually, I believe Go is another one that you can install and it’s fairly easy. Amazon supports all sorts of languages and Google does too, I don’t want to be bias but I’m going to because I’ve only used Amazon.
Google Cloud platform has all different languages and Azure as well., if you’re interested in the Microsoft stack, has different languages that you can use.
[0:04:23.0] DA: Okay, that’s going to be the option but like, when you start developing your application are you worried about getting locked in to one vendor or another by like building it to their speck or their standard.
[0:04:39.3] MN: No, that would be – there are reasons to go around being in the vendor lock. Right now, I am use – so there’s – in the Amazon world, to deploy your application, there is a CLI called AWS SAM which is the server application model. Excuse me, the server application moddule and that will – you run like these scripts that will deploy your code and that’s cool.
But then your’re vendor locked into just using AWS if you were to use that. Not to be confused with the serverless architecture, there is something called the serverless framework where you – they couldn’t come up with a better name unfortunately.
But the serverless framework allows you to setup – you can setup your application in a YAML file, usually it’s the serverless, not YAML because in the near future we’re all going to be coding in YAML. The very first line you can put is the provider and the provider could be AWS, it could be Google, it could be azure and depending on what you put in the provider, when you run serverless deploy, it will deploy to that provider. You could have your Amazon stack and then you just change the provider, you may need to change a couple of things here and there in the YAML file but the code that you had written doesn’t need to change.
[0:06:07.2] DA: You’ve already defined what the entry point is and that payload that’s given to you when that thing gets started up, will remain the same.
[0:06:17.2] MN: Yeah, if you were to use like Azure for example, you may not have the ability to trigger a Lambda via S3, right? I don’t know what the Azure equivalent is but I imagine that you would just have to change those variables to match what is up for Microsoft in the Azure architecture.
One of the really cool things about AWS in particular that I know is that it’s extremely cheap to run and have these things – there are so many zeroes bro, if I had to tell you –
[0:06:52.3] DA: Which side of the decimal place.
[0:06:52.6] MN: No, it’s the right hand side. The –
[0:06:56.2] DA: I see that AWS bill, you know, you got a glimpse at how much your company is paying you.
[0:06:59.5] MN: No, I haven’t seen mine, I could be running it up the wall, I honestly don’t know but one of the bullet points that I have here is it cost 20 cents per one million request that you have.
[0:07:11.9] DA: Okay.
[0:07:12.0] MN: That gets made to you. If you’re starting out an app, l you probably got like 14 and that’s all you and your computer and you can just run your application, and not have to worry about it. I mean, depending on what you're building, right? If you have something starting out and it’s a million requests, pump the breaks. But it’s only 20 cents. Amazon offers like one million, the first million is free mind you, per month.
It’s after your millionth request, those that costs 20 cents per 1 million request. I find it that it was like the easiest to set because you don’t have to deal with like, a build and Kubernetes and ensuring that things are starting, they’ll – ah man it’s just the dream bro, you just push it up to Amazon and –
[0:08:02.0] DA: I’m sure that setting up Kubernetes costs more than 20 cents.
[0:08:06.9] MN: I mean, it depends because like, you could have like lambdas, they get triggered based on events that may happen on EC2 instance but you can literally run like static websites – like I read articles where you can run static websites on the serverless architecture, choosing AWS and not have it cost you a dime which is like really cool.
I found it really easy to start up and to get acquainted with AWS serverless framework, there’s a lot of heavy lifting which is really cool stuff too. The other thing I did – there is all sorts of different – again, this is me talking for AWS but there’s all sorts or different like, applications that come with when you use AWS lambdas like CloudWatch is the logging platform that can log all of the events that happens within your lambda, you can do cloud search if you wanted to search for meta data that exist in an S3 bucket.
DynamoDB is not a relational database that’s used by Amazon so you could write, read, create update, delete all sorts of stuff on it, no relational database, it’s amazing. I’m talking really good about AWS but there are some cons. I mean, I’m flying high bro, this is great stuff but there are specific use cases where you shouldn’t use lambdas and one of the things that I know for a fact is like depending on the processing power of what your lambda is doing can actually cost money.
Because it’s not only the amount of requests that you have but it’s the amount of time that is spent within a lambda. I think they charge you per 100 milliseconds? I forget how many – it’s like 0.00006 cents per 100 millisecond. But if you have to do something where it takes a lot of processing time where this lambda is like, I’m not 100% sure what it could be doing on video processing, I don’t know.
If your lambda exists for a long time, then it could cost money in the end.
[0:10:11.6] DA: Yeah, I think it’s like, different shaped loads might be better suited. Like a serverless or function as a service.
[0:10:19.5] MN: Yeah.
[0:10:19.7] DA: If you have like pretty spikey loads. Most of the time you're doing nothing but sometimes you got to deal with a lot of stuff that sounds like that could be a good option.
[0:10:33.6] MN: Yeah and like I have worked at a place at a client previously where it would not have been possible to use lambdas. It would have been a great alternative because one of the benefits of using lambda is you don’t have to have a server sitting on 24 hours out today. You can have it like per requests so if you have like if your business hours are from nine to five then you know, 6 PM to 8 AM like it is not being used as often.
Then you have money spent because you know the server has to be on and that is electricity cost and what not. If your lambdas are not running then you are not paying for it and that is like the really, really close in. This isn’t even including like if you have to choose between using a EC2 instance versus using lambdas right? Like an EC2 instance, if it has to exist and stay on then you have to pay for that.
In Lambda you don’t but one of the problems would be the fact that if your Lambda is going to crunch numbers and do some craziness there are time limits. So a Lambda can only run for 15 minutes at a time. The longest that a Lambda can run is only 15 minutes so anything beyond that it just fails like it will drop and tell you, “Hey, connection ladled” timeout essentially.
[0:11:49.3] DA: So if you are trying to do something that is really intense and you have to think about how to break it down into smaller pieces.
[0:11:56.8] MN: Right, the idea is like you would have some form of asynchronous Lambda process to do that because you don’t want to hit that 15 minute limit.
[0:12:07.8] DA: Right, it feels like that would be a kind of smell of its own. It is like having a web request that lasts for that long. You want to –
[0:12:16.7] MN: Yeah, you got problems bro. You need to face that.
[0:12:22.0] DA: You wanna like background it or farm it out to a bunch of other processes like map reduce it or something like that.
[0:12:30.8] MN: Yeah and you would definitely have to figure out ways to mitigate some of that time so that your lambda just runs as fast as possible. So you are going to end up paying the least amount of money as possible. Another article I have read, there is this not theory – so let’s say you are on a particular lambda. The lambda does need time to load up and start to run this lambda. So if it’s a job is like –
[0:12:56.6] DA: Like AWS or Google Cloud or whoever your provider is, isn’t just going to keep your functions ready to go and nobody to.
[0:13:07.3] MN: Yeah, another con to using this serverless architecture is this concept called the cold start. So supposed you have a Lambda that runs and it will still be I guess like loaded or cached for about – I think the default for AWS is 10 minute so that is another –
[0:13:26.4] DA: So after 10 minutes AWS is like, “Okay you’re not using it getting rid of it.”
[0:13:31.7] MN: Yeah shut it down. Like we will rebuild it if necessary if someone else calls this lambda or hits this API endpoint. So the idea that your functions may have this delay to trigger an event is a potential issue if people aren’t really sensitive with timing and ensuring that Lambda has to be really fast or the response has to be really fast but this happens again, the default for Amazon is like 10 minutes and it depends on the language.
[0:14:04.1] DA: Interesting.
[0:14:05.6] MN: Yeah so if you are doing something in Node and you got a ton of Node modules that you need to import for this one Lambda, it may take longer than if you were to just do a hello world with just a native node library.
[0:14:19.7] DA: Oh okay yeah, I guess like that block call of the modules folder is going to hold you back a little bit with the cold start.
[0:14:27.0] MN: Yeah and I say it’s a long time but it is probably like a second maybe two but if your application of the product you are building has to have that time be really fast, then you may need to figure out a pattern to ensure that your Lambdas are loaded to be ready to go for those calls.
[0:14:47.1] DA: And you said something that’s kind of like a little bit opaque to you. It is not something that AWS is – are they pretty transparent about how that happens? It seems like people are scientifically poking at the service to figure out how it actually works under the hood.
[0:15:05.4] MN: Yeah I think it is more like people are trying to figure out what’s happening under the hood. I am not a 100% sure if Amazon has been transparent but certain languages just deal with this cold start differently. You have Ruby, Python, Node can be in pretty fast and C-sharp and Java can be a little bit on this lower end and it may have to do with the how verbose the languages are to have them up and running. I am not a 100% sure but there is a lot of people trying to find.
And dig up information about this cold start thing and I think this is probably going to be an issue in the serverless architecture for time to come.
[0:15:39.6] DA: So I am curious since we are talking about package size making a big difference in the startup time, I am wondering, how does that work with how you design your application? Are there ways like when you build and deploy, do you just deploy the one function and the minimal set of things that’s required for it or do you deploy a monolith that contains all the functions and can be used by different end points?
[0:16:11.3] MN: The way that I have been doing it has been you deploy them function by function. So in that you make your function as small as possible. So you are not importing all of the libraries if you need to run this one Lambda that does that just fetches you a list of documents in an s3 bucket for example. You would probably – like certain packages are already pre-loaded that you wouldn’t need to import your no modules in your Lambda.
Like for example, the AWS SDK, you can just call it like you’d, “Hey, I want –” you do require AWS SDK. Boom and then now you can make the S3 calls to do that. You don’t have to load up your secret key or your AWS access key because you are running it in the lambda that is going to call these things anyway. Let’s say you do deploy them function by function like you can do serverless deploy and it will deploy all of your functions if you really wanted to.
But you can actually deploy them – let’s say you built or you had to update a particular Lambda you can just run serverless deploy and then dash function and then you can give it the function name and it will just deploy that function too. I think the other issue, if you are dealing with sensitive data then you may want to house it in your own personal server. If it is sensitive data, you want to know where those servers are. You don’t want it to be serverless and it is probably something that you’d want housed on your end.
I mean imagine like Amazon definitely has, there’s all sorts of different encryptions you can have in your S3 bucket but if you are dealing with super sensitive data then that should be housed in some server where you know exactly where it is and you have security people ensuring that no one is trying to get in and all of that good stuff.
[0:17:52.9] DA: Right and I guess like with serverless, they may not be any guarantees about what other functions are running alongside your functions inside of Amazon’s server that does exist somewhere out there.
[0:18:10.3] MN: Somewhere in the ether bro. I have no idea where it is. Probably some server farm in the middle of the United States.
[0:18:16.6] DA: Yeah like West Virginia, Ohio it would be.
[0:18:19.2] MN: Oh yeah definitely but yeah I think the last thing that I had issues with is best practices. I mean the serverless framework can be really opinionated about how you do certain things but I was having a pretty difficult time trying to figure out what’s the best way to organize my repo and how do I structure my files when I do things because while you have your code up on GitHub it may look like just a list of functions that does things, which is very strange.
You would think it is not like model view controller-ish. It is just, “Hey, right now like we’re still building this app and I just have a source folder that has my eight Lambdas that does things,” and like I don’t know if I go, “Oh should I structure it based on what it’s doing and like how do I do it? Am I just going to have a pool of Lambdas just hanging on the source folder, chillin.” So that’s one of the things that I was trying to look at if anyone has any feedback, I would be more than happy to read up on it.
But serverless has been great. If you haven’t used a serverless architecture, find a vendor and get started. It is a whole lot of fun. It is pretty dope.
[0:19:30.4] DA: Nice, yeah I will have to see what I can do with it. I guess I will have to ask you about all of the best practices you are figuring out overtime. I guess serverless sounds like it helps, or the serverless framework something that helps with a lot of tooling aspects that might be very different than what I am used to like I am trying to think of what like CICD or testing looks like and I imagine there is some good answers out there.
[0:20:00.0] MN: Yeah, I mean in terms of like testing right now we are using Jest to test our node, our lambdas, something similar to how you would unit test any node application, which is great. I think right now we are using like Code Climate or to review our code and all sorts of stuff that’s hooked up on the repo right now but yeah I think I mean you can build fully fledged apps and have it cost pennies on the dollar and it is amazing.
It’s crazy. Serverless is the future, I just – you got to help me find the servers bro. I don’t know where they are.
[0:20:33.5] DA: All right, we’re doing a road trip to West Virginia.
[0:20:36.0] MN: We are going down to West Virginia, awesome.
[END OF INTERVIEW]
[0:20:40.2] MN: Follow us now on Twitter @radiofreerabbit so we can keep the conversation going. Like what you hear? Give us a five star review and help developers like you find their way into The Rabbit Hole and never miss an episode, subscribe now however you listen to your favorite podcast. On behalf of our producer extraordinaire, William Jeffries and my amazing co-host, Dave Anderson and me, your host, Michael Nunez, thanks for listening to The Rabbit Hole.
[END]
Links and Resources:
