> As that happens, there will be a point of no return in which engineers can’t run the whole system on their machines anymore — at least not in a reliable way.
Definitely yes.
However, experiments, proof of concept, shy little prototypes always start on a sheet of paper and then on localhost. Before going somewhere else.
In 20 years, the only satisfying places for work, in design, software dev and engineering, were where we could run internal experiments from localhost or even from a shared, always on system on which we could deploy and share our own internal pages and blogs.
Because of the fragile, imperfect, shared, impermanent nature of that infrastructure (co-owned within the product team), expectations and care, both in building and in critique, had a profound impact on the teams.
That's a bit fatalist ain't it? In fact, it reminds me thtough opposition of the whole "Your Data Will Fit in RAM" thing.
If you can't reliably run production on localhost, it's not because there is something fundamentally wrong with localhost. You're just not running your workload on a beefy enough localhost to remain local.
Think about it. All those cloud hosted workloads? All of them exist in a relative localhost.
I hold that in reality, localhost is the ideal, and any network hosts are the compromise you make because you just can't afford "dat localhost you actually need". The detail orientation and willingness to lay out things sufficiently on localhost by a singular developer simply exhausts.
You have 65535 ports. You can with the right hardware/architecture have truly ridiculous amounts of addressable RAM. Processors? Same deal.
The weak point of course, is your funding, and your willingness to get everything lined up. Which requires attention. Which is finite.
When dealing with teams of developers, there is the additional challenge of handling individual idiosyncracies, which is another issue that network partitioning naturally lends itself to spackling over, but even then, localhost is still theoretically capable of accommodating it.
I didn't mean that production "has to" be able to run on localhost.
I meant that enabling/promoting localhost (or assumed shared, small, inconsequential dev/demo environments)-based development for sorting/trying/demoing out things, sometimes ludicrous ones, is a must when you want to favour innovation in your org.
It goes totally against IT security and silo'd orgs (especially in large ones), so it does not happen without a clear understanding/enablement of the benefits of this from very high up in the chain of management.
Totally with you on that, and in fact, I'm a massive practitioner thereof to the point I was regularly pushing an i7 2021Mac flat out to the point the kernel was just giving up handling any USB input in a remotely reasonable fashion from running several frameworks, servers, DB's VM's, and containers all at the same time.
I was basically pressing Ctrl in that one guys workflow with my project at the time. Fun as all hell. Love a thoroughly tasked computer.
Definitely yes.
However, experiments, proof of concept, shy little prototypes always start on a sheet of paper and then on localhost. Before going somewhere else.
In 20 years, the only satisfying places for work, in design, software dev and engineering, were where we could run internal experiments from localhost or even from a shared, always on system on which we could deploy and share our own internal pages and blogs.
Because of the fragile, imperfect, shared, impermanent nature of that infrastructure (co-owned within the product team), expectations and care, both in building and in critique, had a profound impact on the teams.