4 ms·

I don't really agree with the critiques. E.g. GCP will run a Docker container in a serverless fashion, so you can run any language you like using that. The big

I don't really agree with the critiques. E.g. GCP will run a Docker container in a serverless fashion, so you can run any language you like using that. The big issue, from my point of view, is that the programming model takes all the problems of microservices and adds more. Microservices make even trivial features into a distributed system, bringing all the difficulties of reasoning about code that distributed systems entail. Then add an opaque runtime and almost certainly a number of vendor specific services to handle state and other features the serverless model cannot address directly, and you have a recipe for slow development and frustrating debugging.

CuriouslyC 3y ago
I don't see serverless as having failed at all. FAAS is a great model, you can run a functional monolith and easily break pieces off or integrate stuff in different languages without changing patterns. Doing it with cloud services like lambda can be expensive but if you have kube setup it has the best of all worlds.
- noelwelsh 3y ago
  I don't think it's failed, but I do think the "make everything serverless" hype is overcooked.
baridbelmedar 3y ago
Same here! We're fans of Cloud Run at my company, but it'd be great if they made it easier to pull messages from Pub/Sub using Cloud Run. Sometimes you just don't want push.
- mrbadguy 3y ago
  That’s interesting to hear. What problems did you have with push? Having used this setup before, I found it pretty easy and the only time I found myself reaching for pull (on a service deployed to K8s rather than cloud run) was to achieve greater throughput. Was it the same story for you?
  - baridbelmedar 3y ago
    Maybe I'm doing something wrong here, but one issue I've faced when integrating third-party external systems with Pub/Sub and Cloud Run is the lack of an easy way to throttle the data flow when the external system falls behind. It would be really helpful if the Cloud Run service could easier support pull from Pub/Sub instead, allowing it to consume messages at a pace the external system can handle. I could of course do flow control myself in the Cloud Run service, but it'd be nice if I could just switch to pull.

CuriouslyC 3y ago

I don't see serverless as having failed at all. FAAS is a great model, you can run a functional monolith and easily break pieces off or integrate stuff in different languages without changing patterns. Doing it with cloud services like lambda can be expensive but if you have kube setup it has the best of all worlds.

noelwelsh 3y ago
I don't think it's failed, but I do think the "make everything serverless" hype is overcooked.

baridbelmedar 3y ago

Same here! We're fans of Cloud Run at my company, but it'd be great if they made it easier to pull messages from Pub/Sub using Cloud Run. Sometimes you just don't want push.

mrbadguy 3y ago
That’s interesting to hear. What problems did you have with push? Having used this setup before, I found it pretty easy and the only time I found myself reaching for pull (on a service deployed to K8s rather than cloud run) was to achieve greater throughput. Was it the same story for you?
- baridbelmedar 3y ago
  Maybe I'm doing something wrong here, but one issue I've faced when integrating third-party external systems with Pub/Sub and Cloud Run is the lack of an easy way to throttle the data flow when the external system falls behind. It would be really helpful if the Cloud Run service could easier support pull from Pub/Sub instead, allowing it to consume messages at a pace the external system can handle. I could of course do flow control myself in the Cloud Run service, but it'd be nice if I could just switch to pull.