5 ms·

What I never get with these is: one has to really go out of their way to run the same code on a vm and serverless. So why even bother building the thing twice?

What I never get with these is: one has to really go out of their way to run the same code on a vm and serverless. So why even bother building the thing twice? Do people really consider putting a server app in a function?

jacques_chester 6y ago
> So why even bother building the thing twice? Time elapses. What makes sense today may not tomorrow. It's fine to adapt designs when the economics point that way. Also fine to leave things as they are when the economics point that way.
leetrout 6y ago
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?
tln 6y ago
Cloud Run uses docker containers, so the code can very easily be the same. I'd put a server app up behind a cloud run endpoint, sure, as long as it can fit in a few GBs and start in a few 100 ms. The scale-to-0 aspect is nice, and the scale up aspect is nice too.
- rad_gruchalski 6y ago
  I’ve seen ory hydra being fir in a lambda function and as awkward as it looks to be, it works reasonably well. Thanks, good to know it’s a common technique.
- eb0la 6y ago
  For me the selling point of cloud run is that is easy to develop and debug: make it run locally, test it, then ship it in a container. For GCP cloud functions, AWS lambdas, Azure cloud functions you must fight somehow against the environment (that's the reason frameworks like Zappa exist). If you want/need to use compute instances, you can use KNative in your K8s cluster and enjoy a "similar" scaling experience.
autoconfig 6y ago
This is the beauty of cloud run. There is literally no difference in how you build your application. I can run my codebase locally using docker with no changes and no dependencies on the type of external libraries you'd need for AWS lambda or cloud functions.
tlarkworthy 6y ago
Yes it's called a fat lambda

jacques_chester 6y ago

> So why even bother building the thing twice? Time elapses. What makes sense today may not tomorrow. It's fine to adapt designs when the economics point that way. Also fine to leave things as they are when the economics point that way.

leetrout 6y ago

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?

tln 6y ago

Cloud Run uses docker containers, so the code can very easily be the same. I'd put a server app up behind a cloud run endpoint, sure, as long as it can fit in a few GBs and start in a few 100 ms. The scale-to-0 aspect is nice, and the scale up aspect is nice too.

rad_gruchalski 6y ago
I’ve seen ory hydra being fir in a lambda function and as awkward as it looks to be, it works reasonably well. Thanks, good to know it’s a common technique.
eb0la 6y ago
For me the selling point of cloud run is that is easy to develop and debug: make it run locally, test it, then ship it in a container. For GCP cloud functions, AWS lambdas, Azure cloud functions you must fight somehow against the environment (that's the reason frameworks like Zappa exist). If you want/need to use compute instances, you can use KNative in your K8s cluster and enjoy a "similar" scaling experience.

autoconfig 6y ago

This is the beauty of cloud run. There is literally no difference in how you build your application. I can run my codebase locally using docker with no changes and no dependencies on the type of external libraries you'd need for AWS lambda or cloud functions.

tlarkworthy 6y ago

Yes it's called a fat lambda