4 ms·

And my reply: I agree that there are complexities (as you state, “certain realities”) inherent in distributed systems. If there is one thing I believe we could

And my reply: I agree that there are complexities (as you state, “certain realities”) inherent in distributed systems. If there is one thing I believe we could both agree upon is that distributed systems increase the surface area of complexity exponentially when compared to the relatively simpler stack of clients communicating with one system. Failures in a distributed environment must be expected. Embraced even, since treating them as “an exception” is tantamount to the proverbial ostrich poking its head into the sand. However, failure in a distributed system does not necessitate “Frontend and UX folks” having to address failures which are not directly a result of client communication with the next tier. For example, should the UX be prepared to handle when the primary provider of a service is down and fail over to a secondary system? If the service is the one which the client is directly interacting with, then likely that makes sense. But what of the case when the primary system has issues interacting with its collaborators? Such as its persistent store. Or a strategic partner providing required functionality for the workflow. Is it your position that this type of failure be handled by the UX? Why wouldn’t a server maintain separation of concerns and only communicate to a client when its options have been exhausted? IOW, why assume what “the other side of the connection” is going to do in order to satisfy a request placed on it? In summary, my position is that when the collaborators in a distributed system have a well defined software contracts (protocol, expectations, etc.) and all parties adhere to them (without assumptions in implementation), then this allows the system(s) involved to provide resilience in depth. However, the fashionable trend of replicating a PowerBuilder environment does not lend itself to these separation of concerns. Foisting complexity to either end of the spectrum is where truly nasty problems are bred.

huslage 11y ago
In a distributed system, there is no "primary" system. All systems are distributed and decoupled. The UX sends a request and waits for a response that itself be composed of other requests and responses from multiple other systems. The failures have to be assumed and mitigated for at the UX level, not at some back-end level.
- AnEngineer 11y ago
  By "primary system", I meant the initial system(s) interacted with in a distributed environment. Assuming a connection based distributed model (e.g. TCP/IP), there is a system on the other end of the connection to which a client is communicating. Even for connectionless models, in my mind the "primary system" would be defined as the set of systems which could possibly respond to a client's request. Perhaps the term "primary" is not the best fit for this role. It just seemed less verbose than saying something like "the set of systems for which a client is directly aware and may interact with."

huslage 11y ago

In a distributed system, there is no "primary" system. All systems are distributed and decoupled. The UX sends a request and waits for a response that itself be composed of other requests and responses from multiple other systems. The failures have to be assumed and mitigated for at the UX level, not at some back-end level.

AnEngineer 11y ago
By "primary system", I meant the initial system(s) interacted with in a distributed environment. Assuming a connection based distributed model (e.g. TCP/IP), there is a system on the other end of the connection to which a client is communicating. Even for connectionless models, in my mind the "primary system" would be defined as the set of systems which could possibly respond to a client's request. Perhaps the term "primary" is not the best fit for this role. It just seemed less verbose than saying something like "the set of systems for which a client is directly aware and may interact with."