Regardless, the switch shows they pay attention and are willing to change.

It doesn't have to be so emotional.

Htmx can be helpful to keep all your state in one place, it's simpler to reason about and make changes. Lower cognitive load for the system is better for smaller teams and particularly lone developers.

You can accomplish the same thing by going full front end and minimize backend code with a similar small library that takes care of most to all of it for you.

Living in the front end, with all app state in the front end, has distinct advantages. Lower latency for interaction. Lower server costs. Offline capable. It has some cons like slower initial render. If you don't like JavaScript, JavaScript.

I've seen similarly unstable cloud systems. It's generally not the tool's fault, it's the skill of the wielder.

Lets ignore the loaded, cherry picked situation of no redundancy, no spares, and no warranty service. Because this is all magically hard since cloud providers appeared even though many of us did this, and have done this for years....

There is nothing stopping an on-prem user from renting a replacement from a cloud provider while waiting for hardware to show up. That's a good logical use case for the cloud we can all agree upon.

Next, your cost comparison isn't very accurate. One is isolated dedicated hardware, the other is shared. Junk fees such as egress, IPs, charges for access metal instances, IOPS provisioning for a database, etc will infest the AWS side. The performance of SAN vs local SSD is night and day for a database.

Finally, I can acquire that level of performance hardware much cheaper if I wanted to, order of magnitude is plausible and depends more on where it's located, colo costs, etc.

Depends on the problem. But I don't find a lot of companies that are all marketing and a bare cupboard of an engineering department. They exist, but they are not a universal.Also, most companies that are in this state today have shifted to it from one where product development with the engineering, was actually at least competent.

If you find marketing the hardest part, and most here probably will, you are likely an engineer foremost.

You need a good enough product, and you need it in front of the right buyers. Both aspects can be a significant obstacle to create a business.

If you turn on a .metal instance, your account will be billed (at least) $2/hr for the privilege for every region in which you do so. A fact I didn't know until I had racked up more charges than expected. So many junk fees hiding behind every checkbox on the platform.

Sigh. This old trope from ancient history in internet time.

> Yes, you can probably buy a server for less than the yearly rent on the equivalent EC2 instance.

Or a monthly bill... I can oft times buy a higher performing server for the cost of a rental for a single month.

> But then you've got to put that server somewhere, with reliable power and probably redundant Internet connections

Power:

The power problem is a lot lower with modern systems because they can use a lot less of it per unit of compute/memory/disk performance. Idle power has improved a lot too. You don't need 700 watts of server power anymore for a 2 socket 8 core monster that is outclassed by a modern $400 mini-pc that maxes out at 45 watts.

You can buy server rack batteries now in a modern chemistry that'll go 20 years with zero maintenance. 4U sized 5kwh cost 1000-1500. EVs have pushed battery cost down a LOT. How much do you really need? Do you even need a generator if your battery just carries the day? Even if your power reliability totally sucks?

Network:

Never been easier to buy network transfer. Fiber is available in many places, even cable speeds are well beyond the past, and there's starlink if you want to be fully resistant to local power issues. Sure, get two vendors for redundancy. Then you can hit cloud-style uptimes out of your closet.

Overlay networks like tailscale make the networking issues within the reach of almost anyone.

> Yeah, you can skip a lot of that if your goal is to get a server online as cheaply as possible, reliability be damned

Google cut it's teeth with cheap consumer class white box computers when "best practice" of the day was to buy expensive server class hardware. It's a tried and true method of bootstrapping.

> You have to maintain an inventory of spares, and pay someone to swap it out if it breaks. You have to pay to put its backups somewhere.

Have you seen the size of M.2 sticks? Memory sticks? They aren't very big... I happened to like opening up systems and actually touching the hardware I use.

But yeah, if you just can't make it work or be bothered in the modern era of computing. Then stick with the cloud and the 10-100x premium they charge for their services.

> I've worn the sysadmin hat. If AWS burned down, I'd be ready and willing to recreate the important parts locally so that my company could stay in business. But wow, would they ever be in for some sticker shock.

Nice. But I don't think it cost as much as you think. If you run apps on the stuff you rent and then compare it to your own hardware, it's night and day.

HDD was 10ms, which was noticeable for cached network request that needs to go back out on the wire. This was also bottle necked by IOPS, after 100-150 IOPS you were done. You could do a bit better with raid, but not the 2-3 orders of magnitude you really needed to be an effective cache. So it just couldn't work as a serious cache, the next step up was RAM. This is the operational environment which redis and such memory caches evolved.

40 us latency is fine for caching. Even the high load 500-600us latency is fine for the network request cache purpose. You can buy individual drives with > 1 million read IOPS. Plenty for a good cache. HDD couldn't fit the bill for the above reasons. RAM is faster, no question, but the lower latency of the RAM over the SSD isn't really helping performance here as the network latency is dominating.

Rails conference 2023 has a talk that mentions this. They moved from a memory based cache system to an SSD based cache system. The Redis RAM based system latency was 0.8ms and the SSD based system was 1.2ms for some known system. Which is fine. It saves you a couple of orders of magnitude on cost and you can do much much larger and more aggressive caching with the extra space.

Often times these RAM caching servers are a network hop away anyway, or at least a loopback TCP request. Making the question of comparing SSD latency to RAM totally irrelevant.

That's a lot of room to work with for some inconvenience.

You probably aren't paying a "cloud engineer" just to fiddle with cloud config full time with <$100k/yr spend. Why would you suddenly need a full time sysop to do the same capability level of on-prem? If you do 10 hours of "cloud engineering" a month to support an application, the same capability level of on-prem work is probably in the same ballpark. 5-30 hours. Yes, it can be lower than cloud. No, it's NOT suddenly 160 hours every month. Yes, it does mean you need someone who can wear the extra hat, cloud engineering skills are literally no different in this regard.

Internet sites ran on basement and closet servers for years, actual server rooms for larger stuff. The jokes were tripping over power cords and backhoes digging up internet lines were the causes of most outages. It's never been easier to run on-prem than today. It cost a fraction of even budget VPS providers like Hetzner.

For certain classes of applications, it's awesome. It's not everyone's cup of tea I'll grant. But if you are inclined to play with hardware or have someone in the org who does, and an extra 2-4 hours of downtime a year isn't that big of a deal (depending on general utility and network available at your chosen site). You can save tons of money.

As a lieutenant, I don't get to just go do whatever. I advise, I provide options, I make calls that don't to up to the CEO level.

I pick tech stacks, I pick how to do the things we decide to do. But the final call on what we are doing is the captain's. Especially about the fundamental direction like how to acquire users, markets we target, and how to acquire revenue.

At what cost? Innocent until proven guilty means that we don't treat people like criminals until you have a reasonable suspicion at a minimum.

You don't get to load spyware on everyone's computer because someone, somewhere, committed a crime on a computer. You don't get to remove all end to end cryptography so you can snoop. No, just no. Our society is flirting with these ideas, and they are BAD ideas.

On balance, the abuse happening in homeschooling household is microscopic compared to the abuse happening in current public schools. Both the every day kind and the dramatic makes the news murders and suicides. Put them on even scales rather than putting the specs of dust on the other side under a microscope.

I agree. And they are among the best of teachers. But the ability of such a person to meet the love needs of a wanting child in the setting of schooling is near zero.

Lack of love is a problem. School is quite clearly not a solution to that.

The pandemic and subsequent politics of education has put a magnifying glass on the problems there and many parents are choosing to hit the eject button. There is a concerted effort to remove that button as it's starting to seriously pinch budgets anywhere a student can leave and take their funding money with them.

Currently my state board of education is looking at a rule change to do just that. This battle is just warming up. If you get involved, don't be on the wrong side.

Among the older devs, a sizable amount of them worked in large companies with ineffectual IT departments where the cloud also meant scrapping the red tape in favor of shadow-IT and actually being able to get stuff done. They, largely, think the cloud is the greatest because it materially improved their lives in poorly run organizations. So it simply must be grand.

With these motivations you can come up with any number of arguments that sound plausible to defend the cloud.

There are a few people with significant experience on both sides, that advocate for cloud. I must conclude that their experience largely falls into the few buckets where it does tend to make sense.

My experience is that cloud is insanely expensive - if you can run and keep a competent IT dept.

You can have a pretty sizable server capability on modern hardware before you need to touch that.

I can serve what... 1M users? perhaps 10M users? before my server equipment needs it's own AC unit. Depending on the system needs, architecture, complexity, and perhaps language. I can get 100Mb-1Gb of egress bandwidth pretty easily at most residences, let alone business locations.

I can buy battery backup capacity for cheaper than ever, can probably skip the generator. If you go multi region maybe even skip the deep backup power, for just enough to get clean shutdown, and just fall back early.

It's never been easier to do hosting than it is now. If you get your head out of the clouds anyway.

CPU hardware kind of stagnated 2014-2018, while SSDs took off. But the last 5 years we've seen some pretty massive improvements everywhere.

How many sites need more than 500 threads, 6TB of ram, and 100Gbit egress? Which you can get in a single system now.

Some do, certainly, but then we're talking about the tiny narrow edge on the upper end of the curve. Almost every new web system built today can fit on a single box, and can become massively profitable on that single box unless you unicorn out and need the new architecture which you can now afford. And... that should be the new default.

But... with the cloud, we're stuck with complex massively parallel services or people starting up on tiny rented instances that are, as you say, pocket calculator equivalents.