bcaxis

Vertical integration is a widely known and understood business strategy - running your own infrastructure will help you reclaim the cloud margins back for yourself.

You can do it as a one man band or a huge multinational.

I use hotels and other rental offerings, including the cloud. But I when it is advantageous to do so, I buy and own. Even though it comes with maintenance burdens.

  * You don't have to rotate what doesn't get out.  Limit ingress to relevant IPs reduces this surface area a lot.
  * SCP to a system built for storage.  Not really essential for many systems - system logs are fine.
  * Every VPS provider comes with a backup check box.
  * Tailscale is really simple.

When market conditions change significantly you can see massive degradation of the business somewhere.

VMware shake down could certainly affect the cloud market significantly.

If it is paid for by others, will they really value it? A lot of children just don't value what is handed to them.

But that isn't the delta I'm seeing, it's 5-10x performance delta not a 30-50% delta.

I fire up vCPU or dedicated or bare metal in the cloud, doesn't matter, I simply cannot match the equivalent compute of real hardware and it's not even close.

This matters when the DB calls a sync and it's expecting the data to be written safely to disk before it returns.

A consumer drive basically stops everything until it can report success and your IOPS falls to like 1/100th of what the drive is capable of if it's happening alot.

An enterprise drive with plp will just report success knowing it has the power to finish the pending writes. Full speed ahead.

You can "lie" to the process at the VPS level by enabling unsafe write back cache. You can do it at the OS level by launching the DB with "eatmydata". You will get the full performance of your SSD.

In the event of power loss you may well end up in an unrecoverable corrupted condition with these enabled.

I believe that if you buy all consumer parts - an enterprise drive is the best place to up spend your money profitably on an enterprise bit.

If those apps were PWAs instead, it would mean no extra browser copies are running. In my experience this only really accounts for 70-100 MB per app for the browser copy. No reason slack couldn't be a PWA, same with Spotify.

I'm not really sure how slack and others use so much RAM. I've built quite functional, complicated, and non trivial web apps. Mine typically use <50 MB with some coming in at 20-25 MB. When I'm deploying in electron I'm still in the 80-150 range.

The biggest performance questions for me are network latency vs local data and figuring out ways to mitigate network latency. The difference between 200 ms navigation and 5 ms navigation is pretty stark. Even if most people don't flinch at 200 ms.

MY IoT devices don't have garbage security.

Some vendors let you pool your egress that comes with the compute you buy. Others do not. That can impact costs quite a bit.

I've never seen HTML be smaller than json for data representation. For any kind of data. Ever.

[Snip SPAs reasons that aren't inherent to SPA]

> Most of the mobile devices you're talking aren't that powerful, so loading them down with a bunch of JS to run, makes for a really bad for UX.

Even mobile CPUs are more powerful than your average cloud vCPU. They get refreshed much more frequently if for no other reason than the batteries give out.

That doesn't even take into consideration the fact that the server is rendering x requests vs the client's one.

Any spend on server hardware to make it fast will never make up for the network latency vs a well built SPA that can avoid refetching some data again entirely.

Page one, server render is faster. Every subsequent navigation will favor a well built SPA.