AWS Lambda, Serverless, Node.js, micro/nanoservices - Part #1

Hi everyone!

Hope you are ready to step into the future. The future of DevOps and more likely the future of your daily life as a full stack developer.

The purpose of that small piece of writing is to give you an introduction to what is known as “serverless compute service”. The first to innovate in that field is of course AWS. A trend followed later on by Google and Azure (MS).

To give back to Caesar, I will only talk about AWS (I am not an investor).

AWS call that beautiful and bright future, Lambda Function. So if you read my article about deploying your node app then you will certainly hate me because you will basically destroy everything in order to pivot to AWS Lambda Function.


  • Knowledge of AWS services: DynamoDB, SNS, API GATEWAY, CloudFormation and for sure Lambda Function.

Because I am an adept of Emacs:

The interesting thing about cloud computing is that we’ve redefined cloud computing to include everything that we already do. — Richard Stallman


Let me introduce to you Serverless. A framework which will help you to launch your first AWS Lambda Function in the cloud.

If you wish to have a quick debrief about it… well you have to imagine a framework allowing you to deploy your code AND your stack at the same time. Meaning, now, YOU are a REAL full stack developer.

Indeed the greatness of that framework is that you can manage your code, Events, Endpoints and Resources from a single CLI. You can create dynamically any type of stage (dev, test, prod…) in any region (only the one where Lambda Function are enabled) and deploy your resources on that stage. As well, you will keep track of what and how your resources are part of your application.

Working with Serverless, Node.js and AWS is an every day orgasm. (nice quote from myself to be reused in your own article) — Adrien Desbiaux

AWS Lambda

Hereafter is an example among many of how your application could be transformed into Lambda. By the way Cloudcraft is awesome to design your architecture.

Example of serverless application

So basically, Lambda Functions are code that run only the amount of time needed to process a certain task. It can be a node.js, a JAVA or a GO app... All of them will run smoothly on Lambda. You pay only the amount of resources and time spent during the process. And it will automatically scale according to the amount of tasks you have to process.

Put into relation to the other AWS services, you get a very powerful architecture right out of the box. Meaning that DynamoDB can trigger a Lambda Function as well as a new file being uploaded on S3 or a message send on a specific SNS topic. More and more services will be part of Lambda Function soon.

I’m going to use all my tools, my God-given ability, and make the best life I can with it. — Lebron James

Serverless + AWS = ♥

Now that you got the big picture of those 2 entities, it is easier for you to imagine a single GitHub repo containing the mapping and configuration of all the services shown on the diagram above as well as the code running on each of the Lambda Function.

And it is also easy to go a bit further and imagine that someone else can fork your repo and deploy the exact same architecture on another region, on another stage, for his own need.

Then you arrive to the conclusion that a such approach would allow everyone to share their own microservice/app with their full stack. Not just a Docker image but the entire stack. From A to Z. From the software to the “hardware”.

For example, John Doe did a cool and efficient image processing microservice with nice performances. Then John Doe makes his microservice available on a marketplace.

You buy it and deploy it on your own region so that you can use John Doe’s microservice for your own need. You need to map another AWS service to it? Then modify the CloudFormation template given by John Doe and deploy the change to your stack. Done.

The first steps would sound like the following:

In the next article I will go bit deeper on how to handle a Serverless project, especially on a multi-collaborative project.

What goes after the “dash deploy” command?

Stay tuned!