It’s great that people explore new ideas. However this does not seem like a good idea.
It claims to solve a bunch of problems by ignoring them. There are solid reasons why people distribute their applications across multiple machines. After reading this article I feel like we need to state a bunch of them.
Redundancy - what if one machine breaks either a hardware failure a software failure or a network failure (network partition where you can’t reach the machine or it can’t reach the internet)
Scaling- what if you can’t serve all of your customers from one machine ? Perhaps you have many customers and a small app or perhaps your app can use a lot of resources (maybe it loads gigs of data)
Deployment - what happens when we want to change the code and not go down if you are running multiple copies of your app you get this for cheap
There are tons of smaller benefits - right sizing your architecture
What if the one machine you choose is not big enough you need to move to a new machine, with multiple machines you just increase the number of machines.
You also get to use a variety of machine sizes and can choose ones that fit your needs so this flexibility allows you to choose cheaper machines
I feel like the authors don’t know why people invented the standard way of doing things.
Because we don’t want everything to fall over when one machine goes down we need at least 3 machines (for raft). So if our traditional db would have 500 GB of data we now need 3 machines with 500 GB of ram running at all times. That is an epic waste of money. Millions per year to run ? And you could store it in a db for a couple of dollars.
So all of this ram is being used and is only accessed sporadically if at all. This is not good.
Sounds like you could implement the entire thing on a micro db instance (redis or a regular db) with no raft or any other custom implementation or messing.
It claims to solve a bunch of problems by ignoring them. There are solid reasons why people distribute their applications across multiple machines. After reading this article I feel like we need to state a bunch of them.
Redundancy - what if one machine breaks either a hardware failure a software failure or a network failure (network partition where you can’t reach the machine or it can’t reach the internet)
Scaling- what if you can’t serve all of your customers from one machine ? Perhaps you have many customers and a small app or perhaps your app can use a lot of resources (maybe it loads gigs of data)
Deployment - what happens when we want to change the code and not go down if you are running multiple copies of your app you get this for cheap
There are tons of smaller benefits - right sizing your architecture What if the one machine you choose is not big enough you need to move to a new machine, with multiple machines you just increase the number of machines. You also get to use a variety of machine sizes and can choose ones that fit your needs so this flexibility allows you to choose cheaper machines
I feel like the authors don’t know why people invented the standard way of doing things.