[keewee7]

In the coming years we will probably see a lot of complicated microservice architectures be replaced by well-designed and optimized Rust (and modern C++) monoliths that use simple replication to scale horizontally.

[pixl97]

Replication and simple never belong in the same sentence. DNS which is one of the simplest replication systems I know of has its own complex failure modes.

[qaq]

It can be outsourced complexity as in just using horizontally scalable database like Spanner, CockroachDB etc.

[TideAd]

CockroachDB is nice to use but every database has complexity you have to deal with.

Here's one I ran into recently: if a range has only 1 of 3 replicas online then it will stop accepting traffic for that range until it has 3 replicas again.

(for the folks at home, "range" is a technical term for 512 bit slice of the data - CRDB replicates at the range level)

So, in some code I wrote, I had account for not only 1) the whole DB being unavailable but also 2) just one replica being unavailable (they're different failure modes that say different things about the health of the system).

It's a good behavior! Good for durability. But I had to do some work to deal with it, spend an hour coming up with a solution, etc. There are databases that work at Twitter scale but no there are no silver bullets among those that do. You need full time engineers to manage the complexity and keep it online, or else it could cost the company shitloads of money - I've seen websites of similar scale where a two-hour outage cost them $20 million.

[riku_iki]

You could have more replicas,if availability is critical?..

[pixl97]

All complexity must be paid for and typically the more complex the problem the higher the cost to manage.

[hinkley]

Yes, but it won't be because they're better, it'll be because they're different.

Like last time, and the time before that, and the time before that, and the time before that.

[Hasu]

You're right, no progress has ever been made in software, no new ideas are better than any old ideas, and it's fads all the way down. The only difference between software today and software in 1980 is that today's software is hip and software from 1980 is square.

I understand the frustration with flavor of the week "best practices" and the constant churn of frameworks and ideas, but software engineering as a practice IS moving forward. The difficulty is separating the good ideas (CI/CD, for example) from the trends (TDD all the things all the time) ahead of time.

[hinkley]

Motion is not progress.

In fact it’s often meant to distract from the lack of progress.

It’s not the lack of progress that is the concern, it’s the subterfuge.

[Nextgrid]

You don't even need Rust or highly optimised code. Just moving the existing code from "vCPUs" and networked storage to real CPUs with direct-attach NVME storage will be enough for most purposes. (btw you can do that now, just get yourself a beefy server at OVH/Hetzner and play around with it)