3 ms·

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 hardes

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
      That's fair enough if you use something that actually does this and also keeps track of users of your event. Not saying it is unsolvable. What I've seen though is that in many cases it is unsolved for and it's very hard to reason about "if I remove this event because it's 5 versions too old already and I don't want to keep this backwards compatibility layer, will something "at the other end of our system I never even interact with" puke? Granted some orgs are so big that it makes sense to solve for these large landscapes of services with backwards compatibility ad absurdum in order to allow anything to get done (been at that bank, done that). But reason about the entire system it does not make easier. At many smaller orgs these services were also not built because of organizational issues that needed to be solved but because "everyone does this now" and there's no proper registry of properly defined interfaces and trying to find out if a change you were going to make is going to take you forever because you do need to version something or if you can just change things as needed is way harder than it's supposed to be at that size org.
      - emodendroket 3y ago
        It's freeing you to reason about only one step rather than the entire system at all times.
        tharkun__ 3y ago
        Fair enough that it's freeing overall if your org is so large that it is faster to always be 100% backwards compatible for aeons. I repeat: most orgs that go all in on this are actually so small that being so compatible is more of a drag than understanding the part of the system that is attached to the interface you are trying to change ;)
        emodendroket 3y ago
        Well that's what I mean about choosing the right events. If you are needing to keep multiple systems in your head all the time the boundaries are wrong. But it's true that evolving the interface of services is hard.

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
    That's fair enough if you use something that actually does this and also keeps track of users of your event. Not saying it is unsolvable. What I've seen though is that in many cases it is unsolved for and it's very hard to reason about "if I remove this event because it's 5 versions too old already and I don't want to keep this backwards compatibility layer, will something "at the other end of our system I never even interact with" puke? Granted some orgs are so big that it makes sense to solve for these large landscapes of services with backwards compatibility ad absurdum in order to allow anything to get done (been at that bank, done that). But reason about the entire system it does not make easier. At many smaller orgs these services were also not built because of organizational issues that needed to be solved but because "everyone does this now" and there's no proper registry of properly defined interfaces and trying to find out if a change you were going to make is going to take you forever because you do need to version something or if you can just change things as needed is way harder than it's supposed to be at that size org.
    - emodendroket 3y ago
      It's freeing you to reason about only one step rather than the entire system at all times.
      - tharkun__ 3y ago
        Fair enough that it's freeing overall if your org is so large that it is faster to always be 100% backwards compatible for aeons. I repeat: most orgs that go all in on this are actually so small that being so compatible is more of a drag than understanding the part of the system that is attached to the interface you are trying to change ;)
        emodendroket 3y ago
        Well that's what I mean about choosing the right events. If you are needing to keep multiple systems in your head all the time the boundaries are wrong. But it's true that evolving the interface of services is hard.