(no title)
gazzini | 5 years ago
I’m surprised to hear how many separate lambda functions each service in your example had. I understand the need to deploy each service independently... but to have +10 deployments within each service seems crazy to me. Is there a reason each service needs so many lambdas (vs deploying the service code as a single lambda function with different branches)?
Fwiw, I found it possible to get quite far with a single monolithic lambda function that defined multiple “routes” within it, similar to how an Express server would define routes & middleware.
Anyways, thanks for writing that PDF, and good luck with Seed!
erikerikson|5 years ago
Obviously this can expand the blast radius of any vulnerability and tends to encourage rougher grained privilege grants.
f6v|5 years ago
jayair|5 years ago
On the Lambdas per service front, the express server inside a Lambda function does work. A lot of our customers (and Seed itself) have APIs that need to have lower response times. And individually packaging them using Webpack or esbuild ends being the best way to do it. So you'll split each endpoint into a Lambda.
I just think the build systems shouldn't limit the architectural choices.
anfrank|5 years ago