[contingencies]

Life is but a stage, and we are all actors upon it.

It's impossible to make many useful statements regarding architecture unless there is proper context. Goals, resources, constraints, expectations. Use the right tool for the job.

[lostintangent]

Then how do any of these distributed systems tools/frameworks write a meaningful or concise landing page? Making informed trade-offs are obviously important. But in a world of saturated information, it seems like there’s even more value in being hyper clear about what the purpose of a thing is? And even better, what it’s _not_. Unfortunately, many of these tools claim to be broadly applicable, in a way that makes it hard to understand their true purpose, without also investing significant time into them. That seems kind of unfortunate.

[contingencies]

Yeah, well, the logical reaction to that is to use minimal tools and unix and actually measure a supposed fault before attempting to work on it. First get it working, then get it working well. Usually the overriding business architectural considerations are achieving functionality within reasonable time and money, using existing HR, and without creating too much technical debt. Characteristics of specific components are generally not high on the list. This can be different in high availability systems, safety related systems, long-term stability fault-recovery-required systems and other special use cases. But for 99% of enterprise, HTTP @ 10Mbps + solid tools like the filesystem or sqlite3 will do it. Scaling becomes easy because you're on 100% known interfaces, so swapping any given component out is trivial, ie. future-proofing exists by default. Interfaces before implementation. For more wisdom tidbits try https://github.com/globalcitizen/taoup ;)