6 ms·

Whether to use pub/sub or rest is entirely domain dependent. So, who cares? Its an implementation detail. Just do whatever makes sense. The most sane systems I

by lugg 7y ago

Whether to use pub/sub or rest is entirely domain dependent. So, who cares? Its an implementation detail. Just do whatever makes sense. The most sane systems I've seen make use of both. > In an architecture driven by a message bus it allows more ubiquitous access to data. Please stop mistaking design details for architecture. Lots of things allow more ubiquitous access to data. Talking about this stuff in this way is just going to wind up with you replacing MySQL with Kafka and never actually solving any real problems with your contexts/domains.

rubyn00bie 7y ago
Totally agreeing with you. <rant> A message bus is to do things like fan-out, fucking messages, not act-as-a-fucking-data-store. Situations that need a message bus are so fucking few and far between I can't believe they posted this article. Message bus is the fastest way to distribute your monolith... I don't know why people are always trying to get rid of REST like it's the problem (it's not; your code/infrastructure is)... </rant>
closeparen 7y ago
What does architecture mean to you? The set of components and how they’ll interact is what it seems to mean in my world.
- lugg 7y ago
  I'm not sure I have a clear definition. What I do know is that I avoid confusing tools, frameworks, languages, libraries, or really anything you could call "software" with architecture. They're all just tools that enable me to draw boundaries around contexts. To attempt to define it, I would say architecture has far more to do with _where_ I draw bounded context lines than how or what tools I use to do so. I saved this talk[1] in my favorites because he manages to distill ways to induce the right boundaries out of business needs. (surprisingly not an uncle bob talk!) For a more concrete example I separate a CQRS/ES architecture philosophy from the implementation detail of a message bus in this comment I wrote further down in the thread [2]. [1] https://www.youtube.com/watch?v=ez9GWESKG4I https://www.youtube.com/watch?v=ez9GWESKG4I [2] https://news.ycombinator.com/item?id=19905016 https://news.ycombinator.com/item?id=19905016
  - geezerjay 7y ago
    > To attempt to define it, I would say architecture has far more to do with _where_ I draw bounded context lines than how or what tools I use to do so. Your definition makes no sense at all. There is no distinction. Architecture specifies which components comprise the system, their interfaces, their responsibilities, and how components are expected to interact with each other. You pick certain tools because they are expected to handle certain responsibilities, because they implement certain interfaces, and because they support or enable certain types of interactions. There is no distinction.
    - lugg 7y ago
      Well I did say I'm not sure I had a clear definition.. Distinction wise, didn't you just lay out the same distinction? And please don't get me wrong, you can have a pub/sub, rest, or event driven architecture. I would just posit that you're basing your architecture on fundamentally the wrong thing. Those sorts of things are design choices, maybe big choices but choices that are much better off being driven by the needs of the problem at hand which in any complex system is many and diverse. Your systems framework should be flexible enough to cater to whatever makes sense with the problem set. Pushing every single problem into the same rest api, rpc, or pub/sub event system is going to end the same way. The next time you see someone talking about some kind of architecture driven by some kind of tool replace the tool's name with "Database" and see just how stupid it sounds to even be discussing it. > Using a database will allow for the same communications, but it’s a little more simple. Single query/result, connection pool, and transactional models are supported out of the box. Service discovery is a matter of just querying the right tables. There is an operational cost of maintaining the database, and possibly having a piece of infrastructure that impacts all services. But, all the production grade databases support clustering, but still things can go wrong and it can lock the whole system up (looking at you MyISAM). > The primary benefit of a database driven architecture is that data is freely available. Services just provide data and don’t mandate how it is used. You still have the necessary coordination in developing a system; part a generates rows like this and part b will modify it like that. But now you can have any new service start non-destructively consuming those tables. This free flow of data allows for rapid prototyping, simple services crosscutting, intuitive monitoring and easier development.
hinkley 7y ago
I've been burned by both but I think I still lean away from event based systems. REST is more likely to result in a partially ordered sequence of actions from one actor. User does action A which causes thing B and C to happen. In event driven systems, C may happen before B, or when the user does multiple things, B2 is now more likely to happen before C1. IME, fanout problems are much easier to diagnose in sequential (eg, REST-based) systems. If only because event systems historically didn't come with cause-effect auditing facilities or back pressure baked in.
- zmmmmm 7y ago
  Isn't sequentiality just an implementation detail too? We use Apache Camel to orchestrate messages and you just declaratively state where you want sequential vs multicast / parallel behavior.
  - hinkley 7y ago
    I don’t mean sequentiality of events I mean sequential steps in the process. All of the side effects of my button press happening in order. If you’re trying to say that’s an implementation detail instead of design elements then I’ll counter that by that yard stick, the difference between email and Slack are just implementation details.
    - zmmmmm 7y ago
      I mean that is orthogonal to whether you are using messaging or not. With API calls you default to doing them in order but you can certainly multithread the calls and lose the deterministic order if you want. With messaging you default to sending them off in parallel and not knowing which are received / processed / completed before the others, but the non-default is available there too. You have a message router that knows what has to be ordered and what doesn't and manages the flow. In both cases the non-default requires a bit more work but in both cases it's available and it just depends what your most critical needs are. One thing though is that as systems scale up and get more complex, you want less and less to have blocking API calls anywhere that you don't need them, as those quickly become your bottle necks and hard failure points.

by lugg 7y ago

rubyn00bie 7y ago

Totally agreeing with you. <rant> A message bus is to do things like fan-out, fucking messages, not act-as-a-fucking-data-store. Situations that need a message bus are so fucking few and far between I can't believe they posted this article. Message bus is the fastest way to distribute your monolith... I don't know why people are always trying to get rid of REST like it's the problem (it's not; your code/infrastructure is)... </rant>

closeparen 7y ago

What does architecture mean to you? The set of components and how they’ll interact is what it seems to mean in my world.

lugg 7y ago
I'm not sure I have a clear definition. What I do know is that I avoid confusing tools, frameworks, languages, libraries, or really anything you could call "software" with architecture. They're all just tools that enable me to draw boundaries around contexts. To attempt to define it, I would say architecture has far more to do with _where_ I draw bounded context lines than how or what tools I use to do so. I saved this talk[1] in my favorites because he manages to distill ways to induce the right boundaries out of business needs. (surprisingly not an uncle bob talk!) For a more concrete example I separate a CQRS/ES architecture philosophy from the implementation detail of a message bus in this comment I wrote further down in the thread [2]. [1] https://www.youtube.com/watch?v=ez9GWESKG4I https://www.youtube.com/watch?v=ez9GWESKG4I [2] https://news.ycombinator.com/item?id=19905016 https://news.ycombinator.com/item?id=19905016
- geezerjay 7y ago
  > To attempt to define it, I would say architecture has far more to do with _where_ I draw bounded context lines than how or what tools I use to do so. Your definition makes no sense at all. There is no distinction. Architecture specifies which components comprise the system, their interfaces, their responsibilities, and how components are expected to interact with each other. You pick certain tools because they are expected to handle certain responsibilities, because they implement certain interfaces, and because they support or enable certain types of interactions. There is no distinction.
  - lugg 7y ago
    Well I did say I'm not sure I had a clear definition.. Distinction wise, didn't you just lay out the same distinction? And please don't get me wrong, you can have a pub/sub, rest, or event driven architecture. I would just posit that you're basing your architecture on fundamentally the wrong thing. Those sorts of things are design choices, maybe big choices but choices that are much better off being driven by the needs of the problem at hand which in any complex system is many and diverse. Your systems framework should be flexible enough to cater to whatever makes sense with the problem set. Pushing every single problem into the same rest api, rpc, or pub/sub event system is going to end the same way. The next time you see someone talking about some kind of architecture driven by some kind of tool replace the tool's name with "Database" and see just how stupid it sounds to even be discussing it. > Using a database will allow for the same communications, but it’s a little more simple. Single query/result, connection pool, and transactional models are supported out of the box. Service discovery is a matter of just querying the right tables. There is an operational cost of maintaining the database, and possibly having a piece of infrastructure that impacts all services. But, all the production grade databases support clustering, but still things can go wrong and it can lock the whole system up (looking at you MyISAM). > The primary benefit of a database driven architecture is that data is freely available. Services just provide data and don’t mandate how it is used. You still have the necessary coordination in developing a system; part a generates rows like this and part b will modify it like that. But now you can have any new service start non-destructively consuming those tables. This free flow of data allows for rapid prototyping, simple services crosscutting, intuitive monitoring and easier development.

hinkley 7y ago

I've been burned by both but I think I still lean away from event based systems. REST is more likely to result in a partially ordered sequence of actions from one actor. User does action A which causes thing B and C to happen. In event driven systems, C may happen before B, or when the user does multiple things, B2 is now more likely to happen before C1. IME, fanout problems are much easier to diagnose in sequential (eg, REST-based) systems. If only because event systems historically didn't come with cause-effect auditing facilities or back pressure baked in.

zmmmmm 7y ago
Isn't sequentiality just an implementation detail too? We use Apache Camel to orchestrate messages and you just declaratively state where you want sequential vs multicast / parallel behavior.
- hinkley 7y ago
  I don’t mean sequentiality of events I mean sequential steps in the process. All of the side effects of my button press happening in order. If you’re trying to say that’s an implementation detail instead of design elements then I’ll counter that by that yard stick, the difference between email and Slack are just implementation details.
  - zmmmmm 7y ago
    I mean that is orthogonal to whether you are using messaging or not. With API calls you default to doing them in order but you can certainly multithread the calls and lose the deterministic order if you want. With messaging you default to sending them off in parallel and not knowing which are received / processed / completed before the others, but the non-default is available there too. You have a message router that knows what has to be ordered and what doesn't and manages the flow. In both cases the non-default requires a bit more work but in both cases it's available and it just depends what your most critical needs are. One thing though is that as systems scale up and get more complex, you want less and less to have blocking API calls anywhere that you don't need them, as those quickly become your bottle necks and hard failure points.