n the dim, dark past, the first half-dozen time “distributed systems” was the New New Thing, people discovered (the hard way) that what runs great on the white board isn’t so wonderful up against real silicon. Over the years, new systems based on decomposition (to varying degrees of “extreme”) explored how the decomposed parts “recomposed” dynamically to provide a service application programs had come to embrace. Some emphasized fast, lightweight mechanisms optimized for fine-grained concurrency, others took the conceptual virtual machine (not instruction set interpreters) to a very high degree of sophistication, and some explored extremely novel (some might say “baroque”) techniques of considerable imagination. Time and again, however, the Gold Standard for moving between protection domains was a procedure call plus fiddling with some protection registers. All the schemes require validating arguments to some degree.
And some required what today would be catastrophic cache flushing. The reality not yet avoided is that ring-crossings are expensive compared to function calls.
Transfers between complex protection domains are painfully slow. And putting network communication in the middle of any of these needed a REALLY good reason.
I’m a huge fan of system decomposition as long as it doesn’t start to smell bad. Given that RESTful stuff was not designed as an efficient RPC mechanism,
How does one decide when and what can be packaged as a Microservice without causing more trouble down the road as the scaling heats a up?
It seems one would want to be pretty confident in the architectural partitioning of the system, or at least the ability to bob-and-weave as
Necessary to keep the wheels on the wanton while the jet engines can be changed in midair.
Cap’n Fred’s Rule #1: Always keep the water on the outside of the boat.
Cap’n Fred’s Rule #2: When you hit something, do it going as slowly as possible.
Cap’n Fred’s Rule #3: There is no speed at which a bridge piling that won’t violate Rule #1.
Love the real-world examples! Much more interesting to learn that way :)
I can relate to the api gateway problem... As we have different microservices responsible for seperate entitites, the logics to combine and process the information usually happens at the gateway, which makes it much heavier than it should be.
The alternative is to have the logic in one of the microservices, which might break the 'domain ownership' (as it'll need to know more).
Well done. Good advise without theology 😉. I
n the dim, dark past, the first half-dozen time “distributed systems” was the New New Thing, people discovered (the hard way) that what runs great on the white board isn’t so wonderful up against real silicon. Over the years, new systems based on decomposition (to varying degrees of “extreme”) explored how the decomposed parts “recomposed” dynamically to provide a service application programs had come to embrace. Some emphasized fast, lightweight mechanisms optimized for fine-grained concurrency, others took the conceptual virtual machine (not instruction set interpreters) to a very high degree of sophistication, and some explored extremely novel (some might say “baroque”) techniques of considerable imagination. Time and again, however, the Gold Standard for moving between protection domains was a procedure call plus fiddling with some protection registers. All the schemes require validating arguments to some degree.
And some required what today would be catastrophic cache flushing. The reality not yet avoided is that ring-crossings are expensive compared to function calls.
Transfers between complex protection domains are painfully slow. And putting network communication in the middle of any of these needed a REALLY good reason.
I’m a huge fan of system decomposition as long as it doesn’t start to smell bad. Given that RESTful stuff was not designed as an efficient RPC mechanism,
How does one decide when and what can be packaged as a Microservice without causing more trouble down the road as the scaling heats a up?
It seems one would want to be pretty confident in the architectural partitioning of the system, or at least the ability to bob-and-weave as
Necessary to keep the wheels on the wanton while the jet engines can be changed in midair.
Cap’n Fred’s Rule #1: Always keep the water on the outside of the boat.
Cap’n Fred’s Rule #2: When you hit something, do it going as slowly as possible.
Cap’n Fred’s Rule #3: There is no speed at which a bridge piling that won’t violate Rule #1.
Stay dry!
-mo
Love the real-world examples! Much more interesting to learn that way :)
I can relate to the api gateway problem... As we have different microservices responsible for seperate entitites, the logics to combine and process the information usually happens at the gateway, which makes it much heavier than it should be.
The alternative is to have the logic in one of the microservices, which might break the 'domain ownership' (as it'll need to know more).
Haven't found a satisfying guideline for that.
thanks, Anton