16

If I have an API that has the following routes

POST /slack
POST /slack/hook
POST /slack/another-hook
POST /slack/hook/nested

Is it better to have 4 separate Lambda functions and 4 routes in the API Gateway? Or to have 1 Lambda for the root route and have the Lambda handle the routing from there?

example 1

POST /slack --> lambda1
POST /slack/hook --> lambda2
POST /slack/another-hook --> lambda3
POST /slack/hook/nested --> lambda4

example 2

POST /slack --> lambda1
POST /slack/hook --> lambda1
POST /slack/another-hook --> lambda1
POST /slack/hook/nested --> lambda1

Is there a best practice for this? If so why?

johndoe
  • 4,387
  • 2
  • 25
  • 40
9er
  • 1,604
  • 3
  • 20
  • 37
  • Does this answer your question? [aws api gateway & lambda: multiple endpoint/functions vs single endpoint](https://stackoverflow.com/questions/41425511/aws-api-gateway-lambda-multiple-endpoint-functions-vs-single-endpoint) – Eyal Roth Jan 13 '22 at 03:45

3 Answers3

15

This blog post here explains the pros and cons of various serverless patterns. Following are some things to keep in mind:

One Lambda per route aka microservice pattern:

Pros

  • Easier to debug since each lambda has a very specific function and cloudwatch logs are well separated.
  • Easier to test since each lambda handles a separate event.
  • Deployments are more fine grained. Updating a function can only affect a specific functionality so you have a separation of concerns.

Cons

  • Possibly more cold starts for lambdas since some of them might not be frequently accessed.

  • You might end up with a lot of lambda functions to manage.

  • Slower deployments as there are multiple functions to deploy.
  • You might run into the cloudformation resource limit for a single stack(which is 200 resources) pretty soon. I have run into this personally.

One Lambda with multiple routes aka service/monolith pattern depending how routes are grouped:

Pros

  • Fewer cold starts/better performance since the lambda would be invoked frequently and stay warm.
  • Fewer lambda functions to manage.
  • Faster deployments as there are fewer functions to deploy.

Cons

  • Harder to debug and analyse cloudwatch logs, function handles multiple types of events.
  • You need to write and maintain a router.
  • Bigger function size so you could hit the deployment size limit.
  • Updating a function might cause regression and break some other functionality.

As you can see, there are pros and cons to each approach and there is no single right way to do things. Also as the other answer suggests, you need to consider things like CICD, project and time constraints as well.

user818510
  • 3,414
  • 26
  • 17
  • I request a bit more information, as multiple lambda, there should be multiple runtime, and that will incur additional cost...if this is correct statement? Or both will cost the same? Please suggest – aniruddha May 03 '21 at 16:53
  • What about cost? each additional lambda consumes more GB seconds and adds to the total monthly cost. – Yaron Levi Sep 07 '21 at 08:09
  • 1
    I strongly disagree with "lambda per route is easier to debug". I find it vastly harder to debug/monitor issues of a single (micro) service when its routes are split among multiple log files (groups) and multiple queues. Sophisticated and expensive tooling such as ServiceLens/Lumigo become a must. It's already a micro service (assuming "Services Pattern" from the blog post), so why would I want to split the logs per route? They are all strongly connected. It's obviously even harder to debug cross-function problems this way (say, RDS proxy connectivity issues). – Eyal Roth Jan 13 '22 at 03:29
  • 1
    I also disagree with "You need to write and maintain a router" being a con. It's equivalent to writing and maintaining API gateway configuration. – Eyal Roth Jan 13 '22 at 03:32
  • 2
    Lastly, "Deployments are more fine grained" is a bit of a fad IMHO. Again, assuming the "Services pattern" from the blog post (not "Monolithic"), multiple endpoints of a single service SHOULD be deployed together. After all, they share the same code and are strongly connected; that's the entire idea behind the concept of a "service". And if the service is not fine-grained enough for a team to be able to work on it "autonomously", then it may need to be split into multiple other services. – Eyal Roth Jan 13 '22 at 03:43
6

I will be surprised if anyone says that there is a right and wrong answer.

I've done both in different projects, I guess it comes down to the CICD preferences, architecture, time constraints.

Having one lambda theoretically simplifies your architecture but effectively you're building a monolithic app with all the downsides applicable to that architecture, however, if you're single dev it significantly minimises building, testing and deployment process, so you don't have to worry about dependencies between lambdas and have a single deployable artifact.

On the other hand, multiple lambda functions offer you the flexibility similar to microservices, but it would require you to have individual pipelines and the whole CICD ecosystem becomes more complex and time-consuming.

On more thing to be mindful when having all code in one lambda function, is the size limit and potential dependency hell, depending on your language.

Not knowing your organisation/project and time constraints, I would probably start with a single lambda and split it into multiple lambda functions later if needed...

b.b3rn4rd
  • 8,494
  • 2
  • 45
  • 57
  • 1
    "would probably start with a single lambda..." that is a very sane way to start such a move to lambdas (-: – Yaron Levi Sep 07 '21 at 08:19
1

I have been debating this and opted for separate git repositories per service, for example person, account etc and each with its own lamba functions.

This allows me to treat each repo/serverless project as its own microservice and I use the MVC pattern of a controller with services and a DAO per microservice.

My pipelines build and test single repos, deploy and then run system integration tests on single repos.

What I didn't like about the router pattern were:

  • Logging of functions, single log stream

  • Single point of failure

  • Regression with every change

  • I prefer discrete separation of concerns

  • Testability

  • You now need to cater for your hungriest lambda, e.g it requires 1024mb ram, a simple GET could suffice with 128mb or now you need to start breaking your pattern and refactoring as you need to move functions around

  • I read a few articles which demonstrate that the return you get on cold start is really only applicable when you have under utilised endpoints

I used a serverless plugin to warm lambdas as the only real benefit (imo) of the router pattern is less cold starts.

berimbolo
  • 3,319
  • 8
  • 43
  • 78