3 ms·

Yep we’re running our API at work in a lambda behind API gateway. It’s “interesting”

• rad_gruchalski 6y ago
  Sounds fun! Could you elaborate on the “interesting” part a bit more?
  • leetrout 6y ago
    On one hand it’s very easy to run the code locally or in lambda because we use Go along with a library from AWS that translates the gateway proxy request event to a normal http request. So the request handling is all the same in code. To prevent 404s hitting your function you have to define your routes in both your code and in api gateway. This starts to marry your code to your deployment. Observability is now harder and you need yet another thing. We’re using X-ray with datadog. To “safely” talk to Postgres you should use an rds proxy. It’s still unclear how much is different from pgbouncer or similar but in any case it’s pretty easy to knock over your db with runaway lambda invocations. I could go on about the mistake we made of using SAM and how it ends up not supporting everything you need but I guess my main point is it’s easy to get sucked in by the idea of it being easy but you are trading that for service / operational complexity with a healthy dose of platform lock-in.
    • cavisne 6y ago
      This is a pretty good example of how Cloud Run is better, as those connections to the database would be divided by 250 (lambda supports no concurrency). Lambda supports docker containers now but Cloud Run was also ahead of the curve there.
      • leetrout 6y ago
        Yep. Running adhoc containers on demand is clearly the right pattern. Still plenty of sharp edges but gives you a very clear path to lift your system admin / structure skills in to "serverless". I need to spend some more time playing with Cloud Run because I wasn't aware of the concurrency bit you are mentioning.
• 0xy 6y ago
  Oh god, when's the funeral for your bank account?