Things You Should Know About Serverless APIs

AWS, Serverless  |     |  

AWS Lambda has opened a new horizon of possibilities, most of things that you can do with Lambda Functions and be creating serverless APIs is one of them.

AWS Lambda + API Gateway combination has made it fairly easy and convenient to create APIs without having to manage any servers resources on AWS.

Possibilities of what we can do with FaaS implementations like – AWS Lambda are endless, but, we aware it’s not a silver bullet. Someone might say that you can and must make all the components of the application your team is working on serverless, but, should you?

Consider the following use case –

  • The user makes a request for any service
  • This request is received by Application Running in your data centre or Cloud
  • This request goes through a series services before a final response is returned to End-user

These services could be running as serverless functions or Server-based application services. The End-user simply does not care. It for you to decide what tools and technologies you should use.

Before going serverless, ask these questions –

  • Why serverless or FaaS?
  • Have you done overall Cost-benefit Analysis?
  • Are you Planning to Use FaaS for everything or just of the components?
  • Why not a Vendor Agnostic solution like – Docker Containers?
  • If Lambda is where you are going, what are the language(s) and framework (s) you are planning to use?

All of these are valid questions to ask, that should be asked before deciding anything. For example – Why FaaS? Most people want to use Lambda/FaaS because it’s the newest and the hottest kid on the block Or because of everyone else is using it. But, that can’t be the only reason to use Lambda, consider your use-case before deciding.

Overall Cost-Benefit Analysis

Now don’t get started with 1 Million requests are free with AWS Lambda. First, 1 million requests per month are free, but, you have to pay for Data transfer cost, cost of other AWS Services that you will be using. Lambda functions are time-boxed (it is configurable). This means you need to spend even more time orchestrating and organizing your functions so that they can work in a distributed fashion on your data, Which will add to the overall cost.

Vendor Agnostic Solutions – Docker Container

Lambda may be a good solution depending on your use case, but, Lambda or any FaaS solution will tie you with particular Cloud Provider. For Example, it is very convenient to integrate Lambda with Services like – AWS API Gateway, S3 or SNS and a lot of other services. But that means, apart from using AWS Lambda, you will be using these services that are easier to integrate.

It’s good if you or your organization wants to be on AWS or Azure or GCP, you get a very good package deal, but, what if you are just trying out different providers, or your organization does not want to be dependent on a single provider?

In such a scenario, Container Solutions like Docker might be a good alternative for you. Containers give you more control over the environment as well.

Language/Framework for Lambda Functions

This is perhaps the most important Technology question to ask. People tend to ignore this and say “We have used Java/C# a lot traditionally without and we will continue to do same with Lambda”. Well, Serverless API is not your Web Application or API, so, remember a couple of things before you start working on your serverless API –

  • AWS API Gateway has a 30-second timeout (hard limit, as of now) and there are otherHard and Soft Limits as well, consider them in your plan.
  • API Gateway – Lambda integration means you have less than 30 seconds
  • There is this thing known as “Lambda Cold Start” and it’s different for different languages, C# and Java has the highest cold start and Python and Nodejs has ridiculously very low cold start. There a very good article on AWS Lambda Cold Start.
  • Do you plan to launch your Lambda Functions inside designated Subnets in a VPC? Do remember, it adds to Cold Start
  • Are there any synchronous Calls to other Lambda or API backed by Lambda? Then think of Spiral Cold Start timings? Consider following?

Here we should consider that there will be 2 cold starts – 1st when API Gateways calls your Lambda Function, 2nd when Your Lambda Calls another Lambda or API Backed by Lambda. If there are 2 Cold Start, then 30 seconds (Gateway Timeout) may not be sufficient, and your users will see Gateway Timeout Error. Also, we are creating a Tightly Coupled Architecture. Instead, try to make a decouple architecture using SNS or SQS, something like:

What’s Next?

FaaS implementations like AWS Lambda has many advantages over traditional applications. It may not be feasible to list them all here. However, going serverless requires both in terms of architecture and application design. Tools that you or your team was using with your traditional applications, may or may not be a good fit for serverless applications. So, be flexible in your choice of tools and technologies.

Go give AWS Lambda a try to experience it’s power first hand. When you start planning your Serverless applications, consider all aspects your applications. Try to keep the architecture decoupled to keep it flexible.

Feel free to get in touch with me if want to know about – AWS Lambda, Code Pipeline, AWS Cognito, Automating your workflow on AWS or any other AWS and Serverless queries.