1
votes

Lets say we have service that exposes an API with 5 endpoints. Is serverless architecture a good approach for splitting this service?. I know we have limitations concerning memory, run time and also cold starts, lets just assume these can be mitigated.

If the answer is yes... should each endpoint logic go to a separate lambda function? As an API grow I’m concerned this may be a bit overkill. I would like to hear your experiences

1

1 Answers

3
votes

Is serverless architecture a good approach for splitting this service?

The answer to your question is probably an annoying one, it depends. We are using AWS Lambda with API gateway for some of our APIs and the experience is mixed. The biggest problems we face are memory limitations and cold start.
Because of the above-mentioned reasons, we try to limit the usage of lambda for APIs to following use-cases.

  1. Internal APIs where latency is not supercritical.
  2. APIs which are invoked infrequently so you don't want a server running all the time.
  3. APIs which are doing a simple task of getting data from a few sources and doing some adaptation on the same.

I will not use the serverless lambda architecture for my main production load but some people are able to use it so it probably depends on the use-case you are serving.

should each endpoint logic go to a separate lambda function?

Again, it depends. If your API is serving the same data source but different endpoints are just different types of data filters, I will try to use the same Lambda and multiple API Gateways.
But be careful not to handle too many API gateways in the same lambda as you can easily end up with very complicated lambda code.

There is a great answer regarding the same. aws api gateway & lambda: multiple endpoint/functions vs single endpoint