- Distributed Method Call Error
- The belief that methods and functions communicating across a network is somehow better than communicating within a single process on a single machine.
Process this error by politely throwing a verbal exception, inquiring as to what, exactly, is better. And then explain how the answers you're getting back are the wrong answers.
Here are templates for the three main areas on why a distributed architecture does not make X better:
| If X is one of: | Response |
|---|---|
| Separation of Concerns, Coupling, Cohesion or similar | But X is not primarily about deployment scenarios, so distributing your deployment does not improve X. |
| Reliability, Performance, Robustness or similar | But as you'll know from the Fallacies of Distributed Computing, if not from bitter experience, distributed computing makes things harder not better. |
| Deployability, continuous deployment or integration | But deploying to multiple hosts is harder, not easier, than deploying to a single host. |
Yes, there are problems for which distributed computing appear to be part of a solution. Redundancy as a reliability tactic appears to push you to distributed computing. So does horizontal scaling as a performance or capacity tactic. But these things are done extremely well at the infrastructure level by a black box: a load balancer. Notice that load balancing does not force a decision on whether each instance of your application-or-service is deployed entirely on a single box or is distributed.
So if you think that microservices or any other form of distributed deployment address issues such as dependency management, coupling, cohesion, continuous deployment, avoiding domino failure, then may I put it to you that you have confused, not separated, your concerns. In 4+1 terms, you may be confounding your physical and process models (i.e. the runtime models) with your logical & development ('coding-time') models. As Simon Brown pithily put it, "if you can't build a structured monolith, what makes you think microservices are the answer?".
PS
Yesterday I read a blog about 'Monolithic' architecture which said – with pictures and everything – that if your problem is how to carry on coding effectively (add new features, fix bugs, resolve technical debt etc) as the size and complexity of the code base increases, then the solution is a distributed deployment architecture with synchronous calls over http using xml or json.
I could weep. You manage your codebase by managing your codebase! Not by making your runtime deployment and threading models 50 times more complicated. This is what I mean by confounding the logical & development models with the process & deployment models.
PPS
If you're not familiar with the 4+1 architecture views: The
- Logical view describes your classes' behaviour and relationships; the
- Development view describes how software is organised and subdivided into e.g. modules, components, layers, and how they are turned into deployable artefacts; the
- Process view describes what threading and processes and distributed communications you use and the
- Physical view (though I'd rather call it the Deployment view) describes what machines run what code on the running system
The '+1' is the use cases, or user stories.
When I first saw 4+1 I only really 'got' the logical view. As years passed, I realised that this reflected a lack of experience on my part. When you first do distributed or asynchronous computing, you begin to see why you'd want a process view and a physical (or deployment) view.
4+1 is quite long in the tooth and has evolved in use. There are other sets of viewpoints. Rozanski & Wood's seven viewpoints show the benefit of a decade's more experience. You may think 7 is a lot, but for a small or simple system some of them need only be a sentence or two.