2 ms·

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

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.

fiedzia 3y ago
> If you can't reliably run production on localhost I don't need to run all of production, just enough of it to get the job done with no shared parts. That's usually very little.
Juliate 3y ago
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.
- salawat 3y ago
  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.

fiedzia 3y ago

> If you can't reliably run production on localhost I don't need to run all of production, just enough of it to get the job done with no shared parts. That's usually very little.

Juliate 3y ago

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.

salawat 3y ago
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.