[walrus01]

> "Customers of the data track have stateless applications, because they have outsourced all their state management to the various products and services of the data track."

I have no idea what this is even supposed to mean. It's like somebody combined some buzzwords thought up by a fresh business school marketing graduate working in the 'cloud' industry with an attempt at actual x86-64 hardware systems engineering.

The whole premise of the first half of the article seems to be 'you don't need to design a lot of redundancy and fault tolerance', the second part then goes into a weird explanation of NVME targets on CentOS. I hope this person isn't actually responsible for building storage systems at the bare metal level supporting some production business application.

[cowmoo728]

I think the article is saying that a web server (customers) should be stateless, because everything important should be in a database (data track) on another host. And that database probably has application level handling for duplicating writes to another disk or another host.

The conclusion seems to be that it's not important for hardware level data redundancy because existing database software already handles duplication in application code. I don't understand how that conclusion was reached. Hardware level redundancy like raid1 seems useful because it simplifies handling a common failure case when a single HDD or NVME fails on a database server. Hardware redundancy is just the first stage in a series of steps to handle drive failure. I do agree that a typical stateless server doesn't need raid1, but afaik it's not standard practice for a stateless web application to bother with raid1 anyway.

[isotopp]

> I think the article is saying that a web server (customers) should be stateless, because everything important should be in a database (data track) on another host. And that database probably has application level handling for duplicating writes to another disk or another host.

Correct.

> Hardware level redundancy like raid1 seems useful because it simplifies handling a common failure case when a single HDD or NVME fails on a database server

Nobody needs that if your database does replicate. Cassandra replicates data. MySQL in a replication setup replicates data. And so on. Individual nodes in such a setup are as expendable as individual disks in a RAID. More so, because you get not only protection against a disk failure, but depending on deployment strategy also against loss of a node, a Rack or a Rack Row. Or even loss of DC or AZ.

[wmf]

It's basic 12-factor aka cloud native thinking: "Any data that needs to persist must be stored in a stateful backing service, typically a database."