6 ms·

Or stop chasing the latest fad(s) and build a regular old boring service. The dev experience for building/debugging/troubleshooting distributed functions/lambd

Or stop chasing the latest fad(s) and build a regular old boring service. The dev experience for building/debugging/troubleshooting distributed functions/lambdas is atrocious. Use boring tech, solve business problems and create value without adding needless complexity because devs want to play with the latest toys.

SteveNuts 3y ago
The only time I've ever seen this type of thing put to good use is for gluing things together that don't have a native integration. And even then you better have the configuration defined in code because otherwise you'll spend an entire afternoon reverse engineering how it works.
- activescott 3y ago
  "you better have the configuration defined in code" - you better do that anyway for anything that is used and will be around for a while :)
  - SteveNuts 3y ago
    100% agree, however the difference between one EC2 instance that was launched manually vs. all of the IAM role mess and configuration needed for a lambda... well let's just say I'd rather have an undocumented EC2 instance.
omneity 3y ago
I want a language/runtime that abstracts this away from me. I'll implement and debug functions the regular way, with the runtime in charge of deploying them whichever way fits. Bonus points for deducing infrastructure from statically analyzing code dependency paths. I believe there is very early stage work [0] in this direction, but obviously nothing going mainstream yet. Would love to find more examples in the wild if anyone knows any! [0]: https://egghead.io/blog/how-to-quickly-build-a-backend-with-dark-lang https://egghead.io/blog/how-to-quickly-build-a-backend-with-...
- jiggawatts 3y ago
  I love how you responded to a post advocating for simpler architectures by linking to an automagic abstraction over microservices, because microservices weren't difficult enough already. The example also mentions Stripe payments, but nowhere does it mention transactions or error recovery because they're stupidly difficult in microservices designs, so we'll just "skip right over that" and go straight to losing money any time there's a hiccup. "Sure it's incomplete and outright dangerous to our bottom line, but I can't wait to tinker with it!" is precisely the problem with the industry.
  - omneity 3y ago
    I mean, I do agree with the parent, insofar as I don't want to deal with the mess of microservices/functions firsthand. Now if a runtime could reap the benefits of this architecture automatically, sort of like a compiler would optimize code for a particular cpu, then that would be a best-of-both-worlds situation.
    - michaelmrose 3y ago
      If you can't run anything remotely like the code you are actually running how will you ever figure out why it isn't doing what you expect?
  - threeseed 3y ago
    The problem with your argument is that microservices and lambdas aren’t new. The industry has had plenty of opportunities to ditch them and go back to monolith services and yet it hasn’t happened. Is it because everyone is wrong except for you ? Or is it because they are better for certain types of use cases.
- hu3 3y ago
  Perhaps erlang/OTP might tackle some of these challenges of simpler scaling. https://www.erlang.org/doc/design_principles/des_princ https://www.erlang.org/doc/design_principles/des_princ WhatsApp famously scaled a lot with relatively few devs: > WhatsApp scaled to 1B users with only 50 engineers https://news.ycombinator.com/item?id=28985169 https://news.ycombinator.com/item?id=28985169
deleted 3y ago
[deleted]
threeseed 3y ago
If we are all giving out advice let me join in. It’s not wise to dismiss the technical decisions made by developers as “playing with the latest toys”. Because you are ignorant. You have no understanding of the business requirements, NFRs etc that have led to the decision. So I prefer to give developers the benefit of the doubt. Lambda architectures have trade-offs like every architecture and they are useful in certain situations. Building everything in one service and scaling it when the components have different scaling behaviours usually isn’t ideal.
- hinkley 3y ago
  > The dev experience for building/debugging/troubleshooting distributed functions/lambdas is atrocious. Address this part, or you’re just deflecting. Comments? Suggestions?
  - threeseed 3y ago
    Lambdas trade developer experience for operational simplicity. And they suit use cases where they are independent from each other and can be tested in isolation eg transcoding. In the early days of AWS Lambda I saw teams trying to apply older techniques to lambdas and get stuck with things like distributed transactions but industry has learnt a lot since then. So as always right tool for the right job.
    - hinkley 3y ago
      If it doesn’t work for the developers, then eventually it won’t work for anybody. Trading developer experience for just about anything does not scale - up or down. It’s a false economy.
      - threeseed 3y ago
        And if it can’t scale and run reliably in production then it won’t work at all. Writing some code and throwing it over the fence to some Ops person to manage is not workable long term. It’s why DevOps exist because developers have to take some responsibility for operating their own code. And Lambda architectures help with this.
jmspring 3y ago
What do you think are some specific gaps around distributed functions/lambdas?
jthoaawef 3y ago
I like FaaS for simple things * 0..N Scaling * Request/Invocation is unit of compute * Deploy anywhere * Don't need to bring a web server * Instant Observability (distributed tracing, metrics, logs, alerts, & dashboards) * Instant Security (AuthN/AuthZ/mTLS) * Instant Cost Monitoring How good "FaaS" is will be highly dependent on how good your ops team is.
antoniojtorres 3y ago
These types of grievance comments have really found a permanent home in certain types of HN post. Exhausting.
latchkey 3y ago
> The dev experience for building/debugging/troubleshooting distributed functions/lambdas is atrocious. From my own personal experience, Google Cloud Functions, and everything around it, is fantastic. Had 25k "worker" computers hitting GCF 24/7 (~50 rps) reporting their status. New status message went onto Cloud Tasks, which just hits GCF again, and stored into a Cloud SQL Postgres. Cost was about $200/mo. It ran perfectly with zero downtime for over a year. Super easy to develop, test, and deployments were done with github actions. Very little actual code is dependent on anything GC, so vendor lockin was minimal.

SteveNuts 3y ago

The only time I've ever seen this type of thing put to good use is for gluing things together that don't have a native integration. And even then you better have the configuration defined in code because otherwise you'll spend an entire afternoon reverse engineering how it works.

activescott 3y ago
"you better have the configuration defined in code" - you better do that anyway for anything that is used and will be around for a while :)
- SteveNuts 3y ago
  100% agree, however the difference between one EC2 instance that was launched manually vs. all of the IAM role mess and configuration needed for a lambda... well let's just say I'd rather have an undocumented EC2 instance.

omneity 3y ago

I want a language/runtime that abstracts this away from me. I'll implement and debug functions the regular way, with the runtime in charge of deploying them whichever way fits. Bonus points for deducing infrastructure from statically analyzing code dependency paths. I believe there is very early stage work [0] in this direction, but obviously nothing going mainstream yet. Would love to find more examples in the wild if anyone knows any! [0]: https://egghead.io/blog/how-to-quickly-build-a-backend-with-dark-lang https://egghead.io/blog/how-to-quickly-build-a-backend-with-...

jiggawatts 3y ago
I love how you responded to a post advocating for simpler architectures by linking to an automagic abstraction over microservices, because microservices weren't difficult enough already. The example also mentions Stripe payments, but nowhere does it mention transactions or error recovery because they're stupidly difficult in microservices designs, so we'll just "skip right over that" and go straight to losing money any time there's a hiccup. "Sure it's incomplete and outright dangerous to our bottom line, but I can't wait to tinker with it!" is precisely the problem with the industry.
- omneity 3y ago
  I mean, I do agree with the parent, insofar as I don't want to deal with the mess of microservices/functions firsthand. Now if a runtime could reap the benefits of this architecture automatically, sort of like a compiler would optimize code for a particular cpu, then that would be a best-of-both-worlds situation.
  - michaelmrose 3y ago
    If you can't run anything remotely like the code you are actually running how will you ever figure out why it isn't doing what you expect?
- threeseed 3y ago
  The problem with your argument is that microservices and lambdas aren’t new. The industry has had plenty of opportunities to ditch them and go back to monolith services and yet it hasn’t happened. Is it because everyone is wrong except for you ? Or is it because they are better for certain types of use cases.
hu3 3y ago
Perhaps erlang/OTP might tackle some of these challenges of simpler scaling. https://www.erlang.org/doc/design_principles/des_princ https://www.erlang.org/doc/design_principles/des_princ WhatsApp famously scaled a lot with relatively few devs: > WhatsApp scaled to 1B users with only 50 engineers https://news.ycombinator.com/item?id=28985169 https://news.ycombinator.com/item?id=28985169

deleted 3y ago

[deleted]

threeseed 3y ago

If we are all giving out advice let me join in. It’s not wise to dismiss the technical decisions made by developers as “playing with the latest toys”. Because you are ignorant. You have no understanding of the business requirements, NFRs etc that have led to the decision. So I prefer to give developers the benefit of the doubt. Lambda architectures have trade-offs like every architecture and they are useful in certain situations. Building everything in one service and scaling it when the components have different scaling behaviours usually isn’t ideal.

hinkley 3y ago
> The dev experience for building/debugging/troubleshooting distributed functions/lambdas is atrocious. Address this part, or you’re just deflecting. Comments? Suggestions?
- threeseed 3y ago
  Lambdas trade developer experience for operational simplicity. And they suit use cases where they are independent from each other and can be tested in isolation eg transcoding. In the early days of AWS Lambda I saw teams trying to apply older techniques to lambdas and get stuck with things like distributed transactions but industry has learnt a lot since then. So as always right tool for the right job.
  - hinkley 3y ago
    If it doesn’t work for the developers, then eventually it won’t work for anybody. Trading developer experience for just about anything does not scale - up or down. It’s a false economy.
    - threeseed 3y ago
      And if it can’t scale and run reliably in production then it won’t work at all. Writing some code and throwing it over the fence to some Ops person to manage is not workable long term. It’s why DevOps exist because developers have to take some responsibility for operating their own code. And Lambda architectures help with this.

jmspring 3y ago

What do you think are some specific gaps around distributed functions/lambdas?

jthoaawef 3y ago

I like FaaS for simple things * 0..N Scaling * Request/Invocation is unit of compute * Deploy anywhere * Don't need to bring a web server * Instant Observability (distributed tracing, metrics, logs, alerts, & dashboards) * Instant Security (AuthN/AuthZ/mTLS) * Instant Cost Monitoring How good "FaaS" is will be highly dependent on how good your ops team is.

antoniojtorres 3y ago

These types of grievance comments have really found a permanent home in certain types of HN post. Exhausting.

latchkey 3y ago

> The dev experience for building/debugging/troubleshooting distributed functions/lambdas is atrocious. From my own personal experience, Google Cloud Functions, and everything around it, is fantastic. Had 25k "worker" computers hitting GCF 24/7 (~50 rps) reporting their status. New status message went onto Cloud Tasks, which just hits GCF again, and stored into a Cloud SQL Postgres. Cost was about $200/mo. It ran perfectly with zero downtime for over a year. Super easy to develop, test, and deployments were done with github actions. Very little actual code is dependent on anything GC, so vendor lockin was minimal.