7 ms·

One potential reason to advocate for serverless architecture is it is relatively stateless and event-driven and therefore modular and easy to reason about. Can

One potential reason to advocate for serverless architecture is it is relatively stateless and event-driven and therefore modular and easy to reason about. Can you be more specific about how serverless tends to turn into a ball of spaghetti? It is simply because the lack of state becomes more of a bug than a feature?

jpgvm 3y ago
State can be part of it. For example it can be way simpler to use a in-memory cache than a network attached cache and by doing so you save yourself a dependency, a potential network request that can fail, etc. Also for event processing consider the case you need to process events in order for instance. That is a ton easier with stateful consumers, batching etc which while possible in serverless is usually more difficult/off the beaten path. However by spaghetti I'm more referring to the architecture of your application being turned into networked components, i.e a distributed system. It's pretty much accepted fact now that distributed systems are by far the most challenging area of both computer science and software engineering. Serverless doesn't technically -mandate- this, you could put all your code in a giant function. However it strongly incentivises you not to. a) generally it's deployment times and cold start issues get worse with function size and b) it pushes you to adopt other "building blocks" which are themselves network attached. Essentially it leads people into a massively distributed micro-service architecture right out of the gate. For most applications this is definitely the wrong choice even if you have the folks on staff that specialise in distributed systems, usually those folk are the last to advocate for anything distributed ironically. Getting into the weeds as for why this is hard and all the problems you can run into is probably a bit much for a single HN comment but if you really are curious I suggest reading Leslie Lamport and John Ousterhout. Both have covered the problem space in depth with foundational papers, Leslies "Time, Clocks, and the Ordering of Events in a Distributed System" in particular is foundational.
- eternalban 3y ago
  (quite impressed by the sheer number of comments you have made in this thread, btw) > For example it can be way simpler to use a in-memory cache than a network attached cache and by doing so you save yourself a dependency, a potential network request that can fail, etc. Elsewhere you decided against using cloudflare's kv because it was a poor fit for "cache invalidation" -- "way simpler"? -- and then of course turns out you really don't know if it's a bad fit. > by spaghetti I'm more referring to the architecture of your application being turned into networked components, i.e a distributed system. That is a novel definition of "spagetti". It's a pejorative term in software sense. Why? > It's pretty much accepted fact now that distributed systems are by far the most challenging area of both computer science and software engineering. Ahem. So it caching and cache invalidation. But that didn't stop you, so exactly how is this line you seem to draw with such vocal authority regarding "bad hard", "good hard" informed technically?
  - _gabe_ 3y ago
    > That is a novel definition of "spagetti". It's a pejorative term in software sense. Why? I don't necessarily agree with everything OP is saying, and I certainly don't speak for them, but I completely understand what they mean by a big ball of microservice spaghetti. The spaghetti is distributed across a massive literal network of dependencies instead of being distributed off a giant graph of object dependencies, or goto statements or something. The spaghetti is real and just as messy in the microservice world as the monolith world. I should know, we inherited a massive one. But this shouldn't be too much of a revelation since there is no silver bullet in taming software architecture. Architecting software is very subjective, and more often than not we make the wrong decisions and have to untangle the mistakes further down the road.
    - eternalban 3y ago
      > I completely understand what they mean by a big ball of microservice spaghetti Sure, I understand that too, but that's not what was said. Here it is again: > by spaghetti I'm more referring to the architecture of your application being turned into networked components, i.e a distributed system.
      - Aeolun 3y ago
        How is that not what was said. Your application is going to be spaghetti anyway, networked spaghetti is orders of magnitude worse. I should know, I have a ball of networked spaghetti.
        intelVISA 3y ago
        Chef's law: spaghetti cannot be removed or added, only distributed.
  - jpgvm 3y ago
    > Elsewhere you decided against using cloudflare's kv because it was a poor fit for "cache invalidation" -- "way simpler"? -- and then of course turns out you really don't know if it's a bad fit. I evaluated it at the time. I don't have the context loaded to remember exactly why it didn't work for my use-case but I'm going to look again because CFs platform moves pretty fast and perhaps it could be simpler than what we are currently doing. > That is a novel definition of "spagetti". It's a pejorative term in software sense. Why? Elsewhere it's been coined Lambda Pinball, perhaps you find that a more pleasing description? > Ahem. So it caching and cache invalidation. But that didn't stop you, so exactly how is this line you seem to draw with such vocal authority regarding "bad hard", "good hard" informed technically? Yes, both of which are generally necessary in distributed systems. i.e not only is it a hard problem in and of itself it requires solving sub-problems which are also some of the hardest problems. I think you may have made my points for me.
- scarface74 3y ago
  > Also for event processing consider the case you need to process events in order for instance. That is a ton easier with stateful consumers, batching etc which while possible in serverless is usually more difficult/off the beaten path By off the beaten path you mean a few lines of yaml to configure a FIFO SQS queue and have it trigger a Lambda?
  - empthought 3y ago
    I notice the GP hasn't responded to this. If Lambdas couldn't be a target for SNS or SQS, I wouldn't bother with them either. But that has been a core architectural pattern since 2018. https://aws.amazon.com/blogs/aws/aws-lambda-adds-amazon-simple-queue-service-to-supported-event-sources/ https://aws.amazon.com/blogs/aws/aws-lambda-adds-amazon-simp...
ricardobeat 3y ago
Modular, maybe (though sometimes it's just introducing a network hop in between dependencies). Event-driven being easy to reason about? No way, never.
- erikpukinskis 3y ago
  Yah, I was confused by that too. Out of: 1) event-driven 2) procedural 3) functional 4) inheritance I would say event-driven is tied for last as the hardest to reason about.
  - emodendroket 3y ago
    I'd say it comes down to your choice of events. I also find these systems very easy to reason about.
    - tharkun__ 3y ago
      Instead of your IDE very easily telling you on click the callers or callees of things you'd rather have events where you have no idea who might be processing or sending a particular event in your system of hundreds of microservices? Yeah, totally easy!
      - ShroudedNight 3y ago
        I think you're conflating problems here. IDLs allow interface definitions for interactions that cross compute and administrative boundaries, and event-driven architectures do not require compute distribution (Erlang/beam). Different people have different strengths and anxieties. The suggestion that, with some regularity, the lack of (local) ambiguity of event message arrival may be of higher leverage relative to complexity than increasing the surface of an invokable interface does not seem beyond the pale. Ultimately relinquishing a total temporal ordering is going to be painful regardless of whether it's local or distributed.
        tharkun__ 3y ago
xvinci 3y ago
Statelessnes is really a prerequisite for proper horizontal scaling (with small exceptions), so best practices for e.g. spring boot web applications will lead to a stateless architecture as well. Same goes for event-driven -> amqp, mqtt (and jms for java) plug easily into most modern web-frameworks, you can be as event-driven as you want to (which in my experience is an overhead to plain http / rest which needs to be justified)
- ShroudedNight 3y ago
  > Statelessnes is really a prerequisite for proper horizontal scaling I could understand making this claim w.r.t. Idempotence. Claiming statelessnes as a requirement strikes me as non-trivial enough to require some evidence or a citation thereto.
namaria 3y ago
>stateless and event-driven and therefore modular Non-sequitur

jpgvm 3y ago

State can be part of it. For example it can be way simpler to use a in-memory cache than a network attached cache and by doing so you save yourself a dependency, a potential network request that can fail, etc. Also for event processing consider the case you need to process events in order for instance. That is a ton easier with stateful consumers, batching etc which while possible in serverless is usually more difficult/off the beaten path. However by spaghetti I'm more referring to the architecture of your application being turned into networked components, i.e a distributed system. It's pretty much accepted fact now that distributed systems are by far the most challenging area of both computer science and software engineering. Serverless doesn't technically -mandate- this, you could put all your code in a giant function. However it strongly incentivises you not to. a) generally it's deployment times and cold start issues get worse with function size and b) it pushes you to adopt other "building blocks" which are themselves network attached. Essentially it leads people into a massively distributed micro-service architecture right out of the gate. For most applications this is definitely the wrong choice even if you have the folks on staff that specialise in distributed systems, usually those folk are the last to advocate for anything distributed ironically. Getting into the weeds as for why this is hard and all the problems you can run into is probably a bit much for a single HN comment but if you really are curious I suggest reading Leslie Lamport and John Ousterhout. Both have covered the problem space in depth with foundational papers, Leslies "Time, Clocks, and the Ordering of Events in a Distributed System" in particular is foundational.

eternalban 3y ago
(quite impressed by the sheer number of comments you have made in this thread, btw) > For example it can be way simpler to use a in-memory cache than a network attached cache and by doing so you save yourself a dependency, a potential network request that can fail, etc. Elsewhere you decided against using cloudflare's kv because it was a poor fit for "cache invalidation" -- "way simpler"? -- and then of course turns out you really don't know if it's a bad fit. > by spaghetti I'm more referring to the architecture of your application being turned into networked components, i.e a distributed system. That is a novel definition of "spagetti". It's a pejorative term in software sense. Why? > It's pretty much accepted fact now that distributed systems are by far the most challenging area of both computer science and software engineering. Ahem. So it caching and cache invalidation. But that didn't stop you, so exactly how is this line you seem to draw with such vocal authority regarding "bad hard", "good hard" informed technically?
- _gabe_ 3y ago
  > That is a novel definition of "spagetti". It's a pejorative term in software sense. Why? I don't necessarily agree with everything OP is saying, and I certainly don't speak for them, but I completely understand what they mean by a big ball of microservice spaghetti. The spaghetti is distributed across a massive literal network of dependencies instead of being distributed off a giant graph of object dependencies, or goto statements or something. The spaghetti is real and just as messy in the microservice world as the monolith world. I should know, we inherited a massive one. But this shouldn't be too much of a revelation since there is no silver bullet in taming software architecture. Architecting software is very subjective, and more often than not we make the wrong decisions and have to untangle the mistakes further down the road.
  - eternalban 3y ago
    > I completely understand what they mean by a big ball of microservice spaghetti Sure, I understand that too, but that's not what was said. Here it is again: > by spaghetti I'm more referring to the architecture of your application being turned into networked components, i.e a distributed system.
    - Aeolun 3y ago
      How is that not what was said. Your application is going to be spaghetti anyway, networked spaghetti is orders of magnitude worse. I should know, I have a ball of networked spaghetti.
      - intelVISA 3y ago
        Chef's law: spaghetti cannot be removed or added, only distributed.
- jpgvm 3y ago
  > Elsewhere you decided against using cloudflare's kv because it was a poor fit for "cache invalidation" -- "way simpler"? -- and then of course turns out you really don't know if it's a bad fit. I evaluated it at the time. I don't have the context loaded to remember exactly why it didn't work for my use-case but I'm going to look again because CFs platform moves pretty fast and perhaps it could be simpler than what we are currently doing. > That is a novel definition of "spagetti". It's a pejorative term in software sense. Why? Elsewhere it's been coined Lambda Pinball, perhaps you find that a more pleasing description? > Ahem. So it caching and cache invalidation. But that didn't stop you, so exactly how is this line you seem to draw with such vocal authority regarding "bad hard", "good hard" informed technically? Yes, both of which are generally necessary in distributed systems. i.e not only is it a hard problem in and of itself it requires solving sub-problems which are also some of the hardest problems. I think you may have made my points for me.
scarface74 3y ago
> Also for event processing consider the case you need to process events in order for instance. That is a ton easier with stateful consumers, batching etc which while possible in serverless is usually more difficult/off the beaten path By off the beaten path you mean a few lines of yaml to configure a FIFO SQS queue and have it trigger a Lambda?
- empthought 3y ago
  I notice the GP hasn't responded to this. If Lambdas couldn't be a target for SNS or SQS, I wouldn't bother with them either. But that has been a core architectural pattern since 2018. https://aws.amazon.com/blogs/aws/aws-lambda-adds-amazon-simple-queue-service-to-supported-event-sources/ https://aws.amazon.com/blogs/aws/aws-lambda-adds-amazon-simp...

ricardobeat 3y ago

Modular, maybe (though sometimes it's just introducing a network hop in between dependencies). Event-driven being easy to reason about? No way, never.

erikpukinskis 3y ago
Yah, I was confused by that too. Out of: 1) event-driven 2) procedural 3) functional 4) inheritance I would say event-driven is tied for last as the hardest to reason about.
- emodendroket 3y ago
  I'd say it comes down to your choice of events. I also find these systems very easy to reason about.
  - tharkun__ 3y ago
    Instead of your IDE very easily telling you on click the callers or callees of things you'd rather have events where you have no idea who might be processing or sending a particular event in your system of hundreds of microservices? Yeah, totally easy!
    - ShroudedNight 3y ago
      I think you're conflating problems here. IDLs allow interface definitions for interactions that cross compute and administrative boundaries, and event-driven architectures do not require compute distribution (Erlang/beam). Different people have different strengths and anxieties. The suggestion that, with some regularity, the lack of (local) ambiguity of event message arrival may be of higher leverage relative to complexity than increasing the surface of an invokable interface does not seem beyond the pale. Ultimately relinquishing a total temporal ordering is going to be painful regardless of whether it's local or distributed.
      - tharkun__ 3y ago

xvinci 3y ago

Statelessnes is really a prerequisite for proper horizontal scaling (with small exceptions), so best practices for e.g. spring boot web applications will lead to a stateless architecture as well. Same goes for event-driven -> amqp, mqtt (and jms for java) plug easily into most modern web-frameworks, you can be as event-driven as you want to (which in my experience is an overhead to plain http / rest which needs to be justified)

ShroudedNight 3y ago
> Statelessnes is really a prerequisite for proper horizontal scaling I could understand making this claim w.r.t. Idempotence. Claiming statelessnes as a requirement strikes me as non-trivial enough to require some evidence or a citation thereto.

namaria 3y ago

>stateless and event-driven and therefore modular Non-sequitur