When people aren’t talking about Docker and containers, they’re usually talking about serverless architecture — code that runs without servers. How is that possible? Well, technically, the code still runs on servers, but you’re not the one in charge of managing them. It’s kind of like the cloud, where people just accept that data goes in the cloud and comes back out just the way you requested it. Of course, we know it’s not that easy. There’s a lot that goes on behind the scene. The same holds true for “serverless” code execution… and it’s really cool.
How exactly does it work? To explain and illustrate, I’ll be talking about AWS Lambda. AWS Lambda allows you to focus on code by completely removing the need to think about servers. You write a function with a specific goal (i.e. insert a value in DynamoDB), you set the correct permissions (i.e. Lambda can write to DynamoDB), and all you have left to do is tell the function when to execute. How does it know when to run? Events. When an event occurs, it automatically triggers your function. Events can be things like user signups, user uploads, updating view counts, and more. These events can come from your applications, like mobile and web applications, or even from Amazon’s own services. Available services include Amazon S3, DynamoDB, Kinesis, SNS, Simple Email Service, Cognito, CloudWatch Logs & Events, CloudFormation, and Scheduled Events. As long as you properly configure Lambda and the appropriate service, you can have them working together automatically. That’s pretty powerful.
Let’s take a look at an example:
Say you have a user registration process, and your user uploads an image along with user information. You have multiple things going on here: First, you will want to store this information in a database so you can retrieve it at a later time. Second, you’ll want to create one or more thumbnails of the uploaded image. Why? Because mobile phone pictures can easily be multiple megabytes. That’s massive and needs to be optimized.
How do you optimize it? Well, you could configure this on your local server and use scripts to process this. Honestly, this could work just fine for you. If you get a little bit more traffic it may become an issue, but for low traffic websites, it could easily do the job. But, keep in mind you need to create the server(s) and scripts, install the correct packages (for image manipulation), store multiple different thumbnail versions, make sure you have a reference to these thumbnails stored in your database, and, finally, you need to map the upload image event to trigger your function. Oh, and the image manipulation should probably be executed asynchronously unless you want your users waiting there for a few seconds!
What if I told you that you could do all of this with AWS Lambda, and all you need to do is to write two functions and configure Lambda in just a few minutes? Well, you can. You can have one function that resizes images, and another function that stores user information in a DynamoDB table. How would you call these functions? You could trigger the image resizing function as soon as the user chooses an image from their computer by uploading it to S3. Once the image is uploaded, S3 will automatically call the function and pass in event data to that function. The Lambda function grabs that data to resize the image, and stores the new optimized image(s) in another S3 bucket. All of this is going on while your user is still filling out the username, email, and password fields.
As soon as the user presses “Complete Registration”, your code can invoke the DynamoDB function via Amazon’s API Gateway, and pass in that data. Just like with the image resizing, this function receives the user data and inserts it in the correct DynamoDB table. You could, of course, perform other operations on that data in your function logic before inserting it.
Even if you have a few hundred or thousand users doing this at the same time, you don’t need to worry about your servers slowing down or crashing. The load is offloaded to AWS.
The other important observation to make is how detached our application is from Lambda. When building applications, it can be difficult to keep backend services as attached resources. Backend services should be like lego pieces that can easily be plugged in and out of our application, without difficulty. In the example I just showed you, the only services your application ever touchs are S3 and Amazon API Gateway. This makes it easier to test your application, and also easier to move away from AWS Lambda if you ever wanted to. On top of that, it also makes it easier to re-use this for other parts of your application. If you started out with just a web app and you then decided to build mobile apps, you could just as easily plug them into this system. There would be no difference at all.
The question remains: “When should I use something like Lambda?” While certain use cases could rely entirely on a model like this, in many other cases, they can co-exist. You can use event-driven code execution to take care of certain actions, offloading work from your servers and giving your engineers more time to focus on critical tasks instead of reinventing the wheel.
Understanding how to use something like Lambda can save you a lot of time and effort. When engineers don’t have to worry about maintaining servers or fixing operational issues, we can end up with an application that requires less supervision, while still being very fast and scalable.
If that sounds like fun to you, why not check out my Lambda Deep Dive Course we recently released?