Serverless Concepts & Choices

The Serverless approach is gaining a lot of traction lately in the software industry. To explain it in simple terms, the reasoning is that you do not have to manage servers anymore, but you still need to develop the source code and deploy it in the cloud.

Essentially it removes the need to:

  • Provision and utilize servers
  • Operate and Manage those servers
  • Scale the servers as needed
  • Take care of the availability and fault tolerance of those servers

Serverless has two branches:

  1. Backend as a Service that is used to describe applications that are mainly based on third-party services.
  2. Function as a Service that is used to describe applications that are mainly based on event driven Functions that are executed in stateless containers in the Cloud.

After understanding the basics, the next step is to jump to the implementation. AWS lambda supports code written in Node.js, Python, Java, C# and Go. As a developer with main background in Java, I went with using Java.

AWS Lambda Programming model

Regardless of the runtime there are some common programming concepts when writing code:

  1. Handler: is the function that AWS Lambda invokes in order to start the execution of the function. While creating the lambda in AWS, you should specify the name of the handler. AWS Lambda will pass data and events to this handler, which will process it and execute the code needed. In Java it looks like:
public class HelloWorld implements RequestHandler<Integer, String>{
    public String myHandler(int myCount, Context context) {
        return String.valueOf(myCount);
  1. As it is shown above the AWS Lambda passes a context object to the handler, and is the main way that it interacts with the handler during the runtime.
  2. According to the runtime used there are various ways for a lambda function to terminate successfully or to communicate any errors.
  3. All lambda functions have the ability to log in CloudWatch.

Cold Starts

After implementing and running the Java Lambda function, I came across cold start. Cold Start is the first invocation of the Lambda function, when AWS Lambda needs to spin up the infrastructure, launch the runtime, and start the code. The article I’m afraid you’re thinking about AWS Lambda cold starts all wrong gives a good overview of cold starts and a Google search can provide you with even more articles.

This made me think: “Since AWS Lambda supports 5 different runtimes, what are the criteria for choosing ?”

The answer came from a presentation at the InfoQ: Serverless and Java in the Real World. If there is a requirement for long-tail, low latency synchronous operation then Java or C# is not the best choice. In all other occasions you just go with what you or the team prefers and can support.

I chose to continue with Node.js which seemed to had a good cold start performance. It was also an opportunity for me to learn something new.

What’s Next?

and of course:

References & further reading: