Lambda support for hosting

[kcollasarundell]

Hi,

I was wondering if you would be interested in me up-streaming (via PR when ready) support for this to run on top of aws lambda in a functional url style execution?

Additionally would you like a tf module for hosting it in the lambda?

Can't give you a timeline just something i want to do for reasons and possibly useful for others.

[jamestelfer]

Hi! Sorry for the lack of response. I need to improve my Github notifications filtering so I see this stuff.

I'd be really happy for this kind of thing to make it in. Using lambda in this way was in the back of my mind in the beginning: I didn't head towards that path initially as I felt that the caching and tail latency might be better on a container than a lambda.

That said, I've had success with this kind of thing in the past where the lambda translates the API gateway requests and responses into the net/http equivalents.

If you're interested in doing something like this, I'd happily incorporate it. It would be good for you to flesh out a plan first though:

• how would we restructure the current to incorporate the lambda equivalent
• how would we ensure OTel worked well wth the Lambda environment
• of the existing middleware etc, what would be incompatible (or at least would need special handling)

Also: what's the minimal change that we could make to provide a working foundation? Something that could be the first step towards stability, rather than the entire step in one go.

[kcollasarundell]

Also: what's the minimal change that we could make to provide a working foundation? Something that could be the first step towards stability, rather than the entire step in one go.

So i think the smallest validation would be to use the aws lambda proxy and a sam template to help with local testing and somewhat useful for deploying.

The main issue around this might be the lack of optimisation for the lambda model and lack of control around the caching and secret methods. min change would be moving a bit of stuff out of main into a dedicated library package then creating an additional binary for the lambda mode. (Could likely include it in the standard main with flags controlling the operation modes)

It would be good for you to flesh out a plan first though:

I will write up a plan this weekend. (provided sufficient round tuits)

Would you like that plan in here or close this issue and open a new one with a plan?

[jamestelfer]

Would you like that plan in here

Yep, may as well. No point creating another one. Feel free to change up the description as you like or do it in the comments.

lack of optimisation for the lambda model lack of control around the caching and secret methods

Quite true -- it's mostly targeted at a standard container model. It is however lightweight, suiting a small compute size, so should run fine in a Lambda.

The caching should also be OK in a Lambda context. It's not distributed, which is OK when there are fewer instances that take the load. In a Lambda environment there are likely to be a larger number of instances under load, diminishing the usefulness of the cache.

Using something like Redis as a distributed backup for the memory cache would work, and probably not incur a drastic cost as the size of the data being cached is quite small. This is something that can be added as needed though.

Secrets, on the other hand, are a stickier topic in Lambda. There is an AWS-provided extension for secrets (over local HTTP), but this isn't a great option IMO. There is a Square extension that is pretty good (using files) but this doesn't seem that well supported.

OTOH, there is parameter-store-exec, a project my team supports. It is used in an entrypoint to request parameters from SSM and present them to the launched application as environment variables. IMO, using this and distributing a Lambda container image would be the fastest way to get the show on the road.

The underlying environment variable reading mechanism supports other ways of retrieving values too: via a map or anything you'd like to put behind the Lookuper interface. This would allow for retrieval in the app itself if necessary.

Lastly, the Lambda proxy seems like the reasonable option. I've used the github.com/apex/gateway/v2 in the past to do something similar, so I know the approach checks out.