3 ms·

Did I miss the message they were trying to convey? Nope, you had it in your first sentience, the article doesn't really say anything at all. I've recently sta

Did I miss the message they were trying to convey? Nope, you had it in your first sentience, the article doesn't really say anything at all. I've recently started considering TC's coverage "tech-adjacent", a poorly-formed idea that their target audience is people who work in or with tech-heavy fields, but would never be called on to design or implement systems themselves. TC can talk tech-adjacent stuff to techies, or tech to tech-adjacent, but talking tech to techies elicits a uncanny vally-ish reaction. FWIW, I think what the article inadvertently speaks to is that the apprehensiveness to strongly centralized systems I've watched grow for at least a decade is starting to resonate with even more people.

dmourati 12y ago
Agree. I liked the concept of the article if not the title. From there, I was quickly disappointed. Mainly what happens to me is I look for evidence to support (or refute) an idea I'm mulling. This piece fell short in that I couldn't easily refer others to the article and expect them to come away with any increased understanding. If anyone knows of a good treatment of centralized/distributed at the service or team levels, please do share.
existencebox 12y ago
You'll have to forgive me for tangenting this a bit, but yours and my sister posters mulling prompted some mulling of my own. While I can certainly say I've gained the apprehensiveness you speak of, I realize I've gained it for systems at scale; centralized or otherwise. In fact, for badly engineered distributed systems, where you previously had one problem (getting modules to communicate) you now have N; (getting modules to communicate over potentially unreliable channels; which may themselves have additional hidden points of failure and varying failure modes/symptoms, etc etc). I'm being a bit high-level-hand-wavy with this, but it seems to get the point across (I hope.) My takeaway being, I'm curious if there have been people who have addressed this potential conundrum (and if you even see what I stated as a problem at all.). Data to show that systems are more/less reliable due to certain failure modes under different architectures would be nice, but that seems like a MASSIVE undertaking to do if you have any desire for the data to be meaningful; if only that it may be testing the competency of the team rather than the actual underlying relative difficulty. (although if done broadly enough maybe that would still provide useful guidance? I'm rambling at this point, but some thoughts.)

dmourati 12y ago

Agree. I liked the concept of the article if not the title. From there, I was quickly disappointed. Mainly what happens to me is I look for evidence to support (or refute) an idea I'm mulling. This piece fell short in that I couldn't easily refer others to the article and expect them to come away with any increased understanding. If anyone knows of a good treatment of centralized/distributed at the service or team levels, please do share.

existencebox 12y ago

You'll have to forgive me for tangenting this a bit, but yours and my sister posters mulling prompted some mulling of my own. While I can certainly say I've gained the apprehensiveness you speak of, I realize I've gained it for systems at scale; centralized or otherwise. In fact, for badly engineered distributed systems, where you previously had one problem (getting modules to communicate) you now have N; (getting modules to communicate over potentially unreliable channels; which may themselves have additional hidden points of failure and varying failure modes/symptoms, etc etc). I'm being a bit high-level-hand-wavy with this, but it seems to get the point across (I hope.) My takeaway being, I'm curious if there have been people who have addressed this potential conundrum (and if you even see what I stated as a problem at all.). Data to show that systems are more/less reliable due to certain failure modes under different architectures would be nice, but that seems like a MASSIVE undertaking to do if you have any desire for the data to be meaningful; if only that it may be testing the competency of the team rather than the actual underlying relative difficulty. (although if done broadly enough maybe that would still provide useful guidance? I'm rambling at this point, but some thoughts.)