3 ms·

I understand why this is technically right, but I don't like it. The promise of Cloud Functions is to give them code and they run it. They should be optimizing

by leros 5y ago

I understand why this is technically right, but I don't like it. The promise of Cloud Functions is to give them code and they run it. They should be optimizing how it's run and you shouldn't have to do anything different to optimize performance. I feel like this is a failure on Google's part. Does anyone disagree?

obcilion 5y ago
I believe the team responsible for functions, both for GCP, AWS and Azure, do great work in optimizing functions, far, far better work than we could have done on our own. The problem in our case is that they are architectured to only support a single request. It's not possible to serve a request faster by starting a new anything than serving it from something that is already running.
- leros 5y ago
  Don't you think it's bad design to only allow one request per function? We shouldn't have to migrate to different cloud services to be able to unlock a common pattern. Optimizing the function to allow handling multiple requests while resources are available should be something that the functions infrastructure auto-magically does.
  - obcilion 5y ago
    I think it's a decent architectural decision. It's a lot easier to develop solid code that handles a single request than code than handles multiple requests in parallel. Functions are used for a lot more than HTTP, we use them for a lot of DB event handling such as post-processing, in which case cold starts does not really matter. Maybe we'll one day get to a point where the cloud service knows the best way to run our code?
joek1301 5y ago
I agree wholeheartedly. "Best practices" suggested by AWS, GCP are to architect these services with one function per endpoint, with API gateway handling the routing. Sounds good but if you need reasonable tail-end response latencies in the event of a cold start, you need to forget all about the serverless abstraction and go back to a single container with all of your functionality. On the other hand I can see the appeal of one instance, one request. I don't know if the answer is to enable (optional) request parallelism or to optimize cold start times down further, but OP's requirements feel like they are way too modest to basically force them out of the serverless paradigm.

by leros 5y ago

obcilion 5y ago

I believe the team responsible for functions, both for GCP, AWS and Azure, do great work in optimizing functions, far, far better work than we could have done on our own. The problem in our case is that they are architectured to only support a single request. It's not possible to serve a request faster by starting a new anything than serving it from something that is already running.

leros 5y ago
Don't you think it's bad design to only allow one request per function? We shouldn't have to migrate to different cloud services to be able to unlock a common pattern. Optimizing the function to allow handling multiple requests while resources are available should be something that the functions infrastructure auto-magically does.
- obcilion 5y ago
  I think it's a decent architectural decision. It's a lot easier to develop solid code that handles a single request than code than handles multiple requests in parallel. Functions are used for a lot more than HTTP, we use them for a lot of DB event handling such as post-processing, in which case cold starts does not really matter. Maybe we'll one day get to a point where the cloud service knows the best way to run our code?

joek1301 5y ago

I agree wholeheartedly. "Best practices" suggested by AWS, GCP are to architect these services with one function per endpoint, with API gateway handling the routing. Sounds good but if you need reasonable tail-end response latencies in the event of a cold start, you need to forget all about the serverless abstraction and go back to a single container with all of your functionality. On the other hand I can see the appeal of one instance, one request. I don't know if the answer is to enable (optional) request parallelism or to optimize cold start times down further, but OP's requirements feel like they are way too modest to basically force them out of the serverless paradigm.