3 ms·

The complexity of AWS versus bare metal depends on what you are doing. Setting up an apache app server: just as easy on bare metal. Setting up high availability

The complexity of AWS versus bare metal depends on what you are doing. Setting up an apache app server: just as easy on bare metal. Setting up high availability MySQL with hot failover: much easier on AWS. And a lot of businesses need a highly available database.

spwa4 11mo ago
A high availability MySQL server on AWS is about the same difficulty as on your own kubernetes instance (I've got a play one on one of those $100 N100 machines, got one with 16G mem). Then: helm repo add mariadb-operator https://mariadb-operator.github.io/mariadb-operator helm install mariadb-operator mariadb-operator/mariadb-operator And then you can just provision MariaDB "kind", ie. you kubectl apply with something specifying database name, maximum memory, type of high availability (single primary or multimaster) and secret reference and there you go: new database, ready to be plugged into other pods.
- papichulo2023 11mo ago
  Dont you need ECC in your db nodes?
  - dd_xplore 11mo ago
    N100 supports DDR5 memory (although 1 channel) but I believe DDR5 has some error correction... May not be full ECC
  - 1oooqooq 11mo ago
    amazing how nobody even know about ECC these days. see so many series B+ companies running DB and storage without a care in the world.
  - spwa4 11mo ago
    N100 is my homelab, for playing. For instance I have a kubernetes cluster running KubeVirt, which runs 5 VMs, which ... have a kubernetes installation (so I have multiple worker nodes doing a "distributed filesystem" all of which is resharing disks from the same SSD). My production servers are generally older Xeons with ECC ram, which are also running kubernetes.
PenguinCoder 11mo ago
Most businesses really don't need that complexity. They think they do. Premature optimization.
- speleding 11mo ago
  If your database has a hardware failure then you could loose all sales and customer data since your last backup, plus cost of the down time while you restore. I struggle to think of a business where that is acceptable.
  - wredcoll 11mo ago
    That's not the same as a "high availibility hot swap redundant multi region database". Running mysqldump to a usb disk in the office once a day is pretty cheap.
  - danhor 11mo ago
    My "Homeserver" with its database running on an old laptop has less downtime than AWS. I expect most, if not 99%, of all businesses can cope with a hardware failure and the associated downtime while restoring to a different server, judging from the impact of the recent AWS outage and the collective shrug in response. With a proper raid setup, data loss should be quite rare, if more is required a primary + secondary setup with a manual failover isn't hard.
  - evanelias 11mo ago
    Why are you ignoring the huge middle ground between "HA with fully automated failover" and "no replication at all"? Basic async logical replication in MySQL/MariaDB is extremely easy to set up, literally just a few commands to type. Ditto for doing failover manually the rare times it is needed. Sure, you'll have a few minutes of downtime until a human can respond to the "db is down" alert and initiates failover, but that's tolerable for many small to medium sized businesses with relatively small databases. That approach was extremely common ~10-15 years ago, and online businesses didn't have much worse availability than they do today.
    - 11mo ago

spwa4 11mo ago

A high availability MySQL server on AWS is about the same difficulty as on your own kubernetes instance (I've got a play one on one of those $100 N100 machines, got one with 16G mem). Then: helm repo add mariadb-operator https://mariadb-operator.github.io/mariadb-operator helm install mariadb-operator mariadb-operator/mariadb-operator And then you can just provision MariaDB "kind", ie. you kubectl apply with something specifying database name, maximum memory, type of high availability (single primary or multimaster) and secret reference and there you go: new database, ready to be plugged into other pods.

papichulo2023 11mo ago
Dont you need ECC in your db nodes?
- dd_xplore 11mo ago
  N100 supports DDR5 memory (although 1 channel) but I believe DDR5 has some error correction... May not be full ECC
- 1oooqooq 11mo ago
  amazing how nobody even know about ECC these days. see so many series B+ companies running DB and storage without a care in the world.
- spwa4 11mo ago
  N100 is my homelab, for playing. For instance I have a kubernetes cluster running KubeVirt, which runs 5 VMs, which ... have a kubernetes installation (so I have multiple worker nodes doing a "distributed filesystem" all of which is resharing disks from the same SSD). My production servers are generally older Xeons with ECC ram, which are also running kubernetes.

PenguinCoder 11mo ago

Most businesses really don't need that complexity. They think they do. Premature optimization.

speleding 11mo ago
If your database has a hardware failure then you could loose all sales and customer data since your last backup, plus cost of the down time while you restore. I struggle to think of a business where that is acceptable.
- wredcoll 11mo ago
  That's not the same as a "high availibility hot swap redundant multi region database". Running mysqldump to a usb disk in the office once a day is pretty cheap.
- danhor 11mo ago
  My "Homeserver" with its database running on an old laptop has less downtime than AWS. I expect most, if not 99%, of all businesses can cope with a hardware failure and the associated downtime while restoring to a different server, judging from the impact of the recent AWS outage and the collective shrug in response. With a proper raid setup, data loss should be quite rare, if more is required a primary + secondary setup with a manual failover isn't hard.
- evanelias 11mo ago
  Why are you ignoring the huge middle ground between "HA with fully automated failover" and "no replication at all"? Basic async logical replication in MySQL/MariaDB is extremely easy to set up, literally just a few commands to type. Ditto for doing failover manually the rare times it is needed. Sure, you'll have a few minutes of downtime until a human can respond to the "db is down" alert and initiates failover, but that's tolerable for many small to medium sized businesses with relatively small databases. That approach was extremely common ~10-15 years ago, and online businesses didn't have much worse availability than they do today.
  - 11mo ago