Cloud is insanely expensive and inefficient. Too many engineers don't understand how slow I/O back and forth is on network storage, or VMs with chatty neighbors are compared to bare metal...
Everywhere we look we see people making the best choice for them. Big apps using Electron vs native. Ports of 250MB games like Starcraft now taking 5GB of "compatibility" libraries to run on modern PCs.
I completely agree that people need to be aware of Latency Numbers Every Programmer Should Know (https://gist.github.com/jboner/2841832), but in reality we don't all have the budget, time, or personal to do things the right way when it's the company ordering us around vs our own projects where we can do things "the right way".
Honestly, I'm glad companies are wasteful. If large companies were super conservative and agile then our economy would be in really, really bad shape. It's thanks to these inefficiencies that small startups can jump in and capitalize in ways the many bureaucracies of enterprise can't.
Then again, the dev in me would LOVE it if everyone rewrote everything in Rust or Zig and we put wasteful scripting languages to death for good.
The math has drastically changed over the last few years. For example, the on-prem database server we bought 4 years ago for $14K is now pricing out at $96K.
They can negotiate better prices based on their scale, and even on their ability to internally source key components if needed.
E.g. if AWS/Microsoft/Google/Apple buy 80% of Micron's entire output it's probably at a much better price than the rest of us competing over the other 20% are going to get.
Even just going to second tier cloud providers will tend to let you rent similar capacity much cheaper.
AWS and the other big cloud providers only gets close to cost efficient when you're big enough to negotiate prices that are nowhere near their public list prices.
And by which time you are spending an ungodly amount of money per month !
Which is why second tier providers are the way to go.
You get better prices. Much clearer price models. Better customer service....
... And all without having to commit to spending more than the GDP of a small country every month on your cloud bill.
A global supply chain storage is a global supply chain shortage.
Most famous recent example being Apple who were absorbing the rapidly increasing cost of supply until even they had to put up the prices to reflect procurement and manufacturing reality.
And this is Apple. The company that even buys its manufacturers plant equipment in return for it being dedicated to Apple.
Yes the big boys get volume discount. But that doesn't magically entitle them to last decades's pricing.
You’re trying to refute an argument I did not make.
They do not have to be cheaper than 2016. They have to be cheaper than what your business could otherwise string together paying current market prices. And they will be.
Four years ago, I needed 256gb of ram, and it was costing about $1-2k a month in the cloud, which I replaced with a server on ebay with 1,5tb of ram for about €2k- which I was pricing against equivalent to what I was renting for about $6k or so on newegg. And I think the dumbest IT procurement manager in the planet could've gotten it from Lenovo or HPE or something for $10k providing the easiest 20% savings if they move on-prem.
How much is your $96k server on AWS?
I am no fan of the idea of reinventing everything to run on cloud primitives but you can't deny reliability of online software is a lot higher now than the pre HTML5 era. Back then, having more than two nines of uptime for random backend heavy web apps was hardly common while now it's table stakes.
Some latency increase must be traded for scalability. But at least we get the required utility in return.
But without that utility, one is just hiking up the cost. Any competitor who can deliver at reduced cost holds a potent weapon that you simply cannot survive.
A company that has efficient cost structure across its operational domains holds an advantage which is near impossible to out-compete. A sense of inevitability and resilience is what reduction in cost buys you.
Cost is a weapon. One of the most fundamental weapons in almost all domains.
The argument of cost is fundamental and no amount of Kafka, etc. can override it.
Considering that the topic is an article is comparing raw NVMe vs EBS performance for postgres storage and GP saying that cloud is unnecessarily inefficient, I misinterpreted your comment as implying that networked storage is always an unnecessary cost. In many cases the cost of replication and availability is lower than the cost of data loss and downtime.
I don't think this is true. I am not sure about those you described, but say you have PG replicas, you can run query on replica node without hitting some network attached storage. This is obviously true for reads but not for writes.
Depends on your metrics. Say you're an early startup - short on man-hours and bare-metal skills, with backers who think that "cloud" sounds fast, cool, and scalable.
Or you're a VP at some big company - with C-suite mandate to deliver Cool Solutions ASAP, whatever the cost...but a byzantine mess of middle managers between you and the actual engineers. Deciding "we'll use CloudCo" can rob your steaming heap of PHB's of a lot of opportunities to make bad decisions and drag things out.
Do you want to spend thousands of dollar upfront for that DB server with sweet sweet NVME SSDs, of which your application might not even use 1% before the app get scraped?
Which is to say, it's good advice.
It lets you load your dedicated servers far higher than what you can safely do if you don't have the option of using a cloud provider for burst traffic, but in practice most people will very rarely need it.
If you can’t afford to throw down enough money on a single box to bring a business up then you’re fucked anyway.
I know whole businesses that make a lot of money and never needed more than that box. (And a hot spare)
However, these days, I notice my DBA skills atrophying because LLMs have encoded most of the answers and diagnostics I need in their weights. Coupled with something like Nix, spinning up new servers including backups and everything, it's easier easier than ever to run your own production database instance.
It would really suck to learn that your LLM-generated disaster recovery plan isn't viable when attempting to use it to recover from an actual disaster.
This isn't a whole lot different than what you should be doing to ensure systems not managed by LLMs are designed and operating properly, of course, which I guess is sort of my point.
Hiding behind the LLM, or even a cloud service like RDS makes you think you can get out of a corner, but you are nowhere near that. Practice, drills, experience are the only solution here. The illusion of that is dangerous.
I spent a couple of days recently digging one of our associated businesses out of the shit because they killed a postgres on RDS instance (AWS bug!) and couldn't google or LLM their way out of it. It hit the trade press and did a lot of damage to them.
If you're not going to do the work, don't take on customers.
Of course you need understanding for when shit hits the fan, but that applies regardless of whether it's a human or an LLM writing the code.
LLMs remove personal exploration from tasks and that's where you really get to know things.
When you optimise for fast and not correct, things are fucked.
I think you overestimate the level of DBA skills smaller startups have in house.
If you have found a way for a company to hold off on taking on customers until they can afford a proper DBA, I'd love to hear more about it. But it sounds backwards to me. In my experience, it typically goes the other way around: only after taking on enough customers to be decently profitable can a company afford a real DBA.
Until then, the choice used to be between managed database services or striking luck with a developer that had some database interest. These days, it's between managed database services, striking luck, or giving the developers access to an LLM. The LLM doesn't replace DBA skills that used to be there. There weren't any DBA skills there to begin with.
However, the main cost would be colocation - it's risen quite a bit.
I wouldn't use Ryzen on a production server myself.
I doubt there's much of a meaningful difference other than a jumper for the brand. Retail pricing and availability might differ.
The day it broke, it's a PITA.
You need that RAID card which is not available anywhere around you.
You need to visit your Data Center, but you suddenly have issues with security and you need to arrange all that stuff.
You need to buy DDR stick but you need to wait a month for delivery.
The guy who knows how to insert a stick took a vacation week ago, and everyone else is too afraid to touch big iron box.
With cloud, you either don't notice that, because they have scale and they have spare parts and they have personnel 24/7. Or worst case you order identical server and deploy your app, hopefully in a few hours restoring from backup.
And for some people it might never broke. But it's all the uncertainty and fear that leads people to cloud solutions. You don't plan for average outcome, you plan for worst outcome.
I can't comment on total costs / costs over time though.
And you're not immune from those issues in AWS. What happens when you run out of EBS IOPS or have to change instance type and it won't boot? What happens when your instance fails? What happens if you hit a quota limit in the middle of a failover?
AWS support is fucking awful unless you pay $5k a month or 10% of your total spend (whatever is greater) and then it's only mediocre.
If you're small enough to not be able to justify spares, then rent servers instead. It's still cheaper than the big cloud providers.
> You need to visit your Data Center, but you suddenly have issues with security and you need to arrange all that stuff.
You rarely do. Anywhere beyond the cheapest third-rate colo provider provides "remote hands" services.
Even when managing several racks worth of hardware, I'd go into the colo facilities a couple of times a year at most.
> and they have spare parts and they have personnel 24/7
Even tiny colo-providers still have personnel 24/7, and you can buy fractional devops services for small retainers from any number of providers (like me).
I remember we ran a pretty large UK website on 5 x Pentium II boxes, using a Perl stack which is not exactly memory efficient. Later we ran a chat server for hundreds of thousands of school kids on a single server which was (if I remember this right) a Pentium III with 128 MB (yes, megabytes) of memory and a spinning hard disk.
Where the money gets wasted, is doing a different server per project, putting everything in different resource groups, and then overprovisioning those servers many times over. So much wasted capacity because of simple project structure preferences.
And then there is also the fact some features are locked behind more expensive models, which is also rarely cost efficient.
All I am saying is, if you simply create 1 database server on the cloud, with a database per app, and different schema's, isolated users, ... it can stay super cheap. But good look getting through an enterprise cybersecurity audit or ISO27000+SOC2 certification.
It's absolutely fine. Everyone has just gone stupid recently.
People have zero concept of how incredibly absurdly fast even a slow computer is. Storage is literally 1000x faster than it was 15 years ago. My first job was firmware for enterprise storage arrays and IIRC we were aiming for 3M IOPS. That's not much more than what kids can put in their PS5 now, and these were arrays running companies like Walmart and JPMC.
With the multi million dollars A MONTH purchase commitment contracts I've seen in my previous employers, you could use a single month budget to buy hardware that could serve our applications for years.
totally different words
In 30 years of hosting on-prem or in colo facilities, I've never once bought hardware up front for corporate accounts.
sell a lie, blame the victim?
No thanks.