Broken Lambdas : API’s cannot call API’s
Previously I have been asked to consult the AWS team on Lambdas and the Gateway and pointed out numerous flaws with their system such as every AWS service being a separate network call which creates latency and I/O overhead making them slower than they need to be.
Today I discovered a HUGE flaw in AWS Lambda’s : they cannot call other Lambdas.
API’s Calling API’s
The whole point behind API’s is that they are a communication network where anyone can call an endpoint & endpoints can call each other. This has been talked about repeatedly over the years with :
However, each Lambda is a centralized self contained endpoint so it is impossible for them to call each other effectively. Allow me to show you why…
The Magic of The Front Controller
In an API application, all API endpoints exist within an MVC application where routing is handled by a ‘front controller’ (called a dispatcher in Java). The IP address is associated with the application and the front controller for the application handles all routing of the request/response (including redirects):
Whereas AWS Lambdas have to be called individually and cannot call each other as they have no way of routing internally. They are so decoupled that in order to do anything even similar, they have to call a service on a separate network to talk to another Lambda:
Amazons Response
AWS lists some falsehoods that they believe to be issues (most of which ONLY apply to AWS Lambdas). I thought it would be good to go over them here:
- cost : ONLY if using like AWS Lambdas will it cost you per endpoint call. In your own API application on an EC2 instance, it is FREE; I run an API application with OAUTHon AWS free tier and only pay for IP address ($9/mn)
- error handling : every endpoint can/should throw its own error separate of every other endpoint; thus this would ONLY be true with a bad API implementation. Lambdas CANNOT throw a separate error because they do not have a centralized system managing error logging for all endpoints.
- tight coupling : This statement is a bit confusing as Lambdas are not tightly coupled. What they are referring to is the fact that when chaining them, you are tightly coupling the communication. In NORMAL API APPLICATIONS, there is no tight coupling of the communication (see above with error handling). Hence this is only true when using Lambdas. Additionally, the process cannot be blamed for people coupling long processes with short ones. This would be like blaming SQL for people writing long queries.
- scaling: AWS claims all three processes must be equal in order to scale on Lambdas. This is false in normal API applications. In fact an API call to another API call can greatly reduce latency and overhead by reducing additional request/response from client.
Their Solution(??)
In an API Application, a front controller handles this exchange automatically; you do not have to write code for this because it is handled for you within the application.
Unfortunately, the AWS team has advised that people instead use SQS and Step functions as a way to resolve this lack of foresight on their parts. By providing an external solution (that requires a network call to a separate ‘service’) to AWS Lambdas, this does several things:
- adds latency
- I/O overhead
- external point of failure
These are things that would not exist in a normal API application with a front controller handling the request/response exchange; the handoff would be internal (especially when using an internal redirect) and it does not require a network call to any external services.
In Closing
This is yet another in a LONG LIST of issues with Lambdas where services work if you want a one-off… but NOT an api application.
Always evaluate before you buy.
