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?

5 responses to “Serverless Architecture”

  1. Yuhwan says:

    Thanks for this great article. After reading this article, I get highly interested in the serverless architecture and the Lambda service. Now, I’m looking over the Lambda Deep Dive course 🙂

    • Christophe says:

      You’re welcome! Enjoy the Lambda course!

      • Ivana says:

        Hi there! I’ve read your blog pos. I’ve seen the recent criticism on the current serverless implementations like Lambda. People seem to be using them for projects of a much larger scope than Lambda is intended to. Do you think (similar to what happened in the JavaScript community, where people realized it isn’t suitable for larger project, thus, TypeScript was invented) something like this will happen in this field, where someone will emerge as “Lambda, for bigger projects than your hobbyist app”?

        • Christophe Limpalair says:

          Hi Ivana! This usually comes down to one thing: use the right tool for the job. It’s easy to jump at the opportunity to use a new service or tool because a lot of people are talking about it, but without necessarily understanding that the tool or service is not the best fit for requirements. With that being said, we know that AWS is actively working on improving Lambda, and they are known for continuously pushing updates. Yes, Lambda does have some major cons in my opinion (ie: functions can have a few seconds of latency if they haven’t been used for a while, and we don’t know what “a while” is exactly), and those cons should be fixed. Will those fixes “fix” the issues people are pointing out at larger scale? Maybe, maybe not. This does give the opportunity for someone else to create a different tool or service that could possibly solve those issues, sure. Keep in mind also that Google has Cloud Functions and Azure has their own version.

  2. Yonas Tsegaye says:

    So I am currently working on a dashboard that allows users to see the status of a file that is being loaded into a database. Now I want to build an emailing service that informs the user about the status of their load once it completes or fails. Do you think I can use this technology?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Get actionable training and tech advice

We'll email you our latest articles up to once per week.