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â)âŠ
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.
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