5 ms·

It never occurred to me that anyone would need it explained to them that RDS is cheaper than the time of any software engineer. The opportunity cost of buildin

It never occurred to me that anyone would need it explained to them that RDS is cheaper than the time of any software engineer. The opportunity cost of building your own database is 10,000x the cost of running RDS for a year.

foldr 3y ago
That sort of logic doesn't really apply here because: * RDS costs obviously scale linearly with ongoing time and probably scale linearly with the total amount of data being backed up. So depending on the revenue of the business, these extra costs could easily end up outweighing the (notional) cost of the time saved, which is mostly a one-off expense. * The cost of a software engineer's time is notional in the context of a one-person business. The author of Tarsnap isn't going to be able to employ fewer than zero additional software engineers to maintain Tarsnap because of the time saved by using RDS.
- zetalyrae 3y ago
  [flagged]
  - gus_massa 3y ago
    Perhaps I'm biased, but I read every part like: > I realized that this was introduced by some code I wrote in 2014: Occasionally Tarsnap users need to move a machine between accounts, with an implicit "and I fixed that code now" or "and I will fix that tomorrow when I get enough sleep". Let's hope he writes later a follow up explaining the details. > [a] postmortem on the front page of HN Is that bad? I upvoted this almost instantly, then went to the comment section to upvote cperciva if he was here, then I read the full post and verified my first upvote was correct.
  - foldr 3y ago
    The outage was caused by a hardware failure and (I assume) the lack of any redundancy. Using RDS wouldn't have made a difference as far as I can see.
    - zetalyrae 3y ago
      RDS can have replication. But more than that: servers should be stateless! A server going down should never take down your business. If you use Postgres, and stateless servers, then if a server goes down it's no problem, it gets rebooted and there may be other servers and a load balancer to pick up the load. If Postgres goes down, you have a replica, or it gets rebooted, and Postgres always recovers from crashes (in my experience), and if it doesn't you have PITR. AWS has everything under the sun to prevent this kind of thing happening. This is a 1990's outage. This didn't have to happen.
      - foldr 3y ago
        The hardware failure was on the server running the application code, so RDS replication wouldn’t have helped. You’re right of course that this failure points to a lack of redundancy – but that’s a separate issue from choosing S3 vs. RDS as the data layer. By the way, S3 is insanely reliable and in fact more reliable than a replicated RDS setup. So switching from S3 to RDS would almost certainly reduce the basic reliability of the data layer, however many conveniences it might bring.
        zetalyrae 3y ago
        Once again, the problem is not S3, it is reinventing a database on top of S3, the logic of which runs on EC2.
        catiopatio 3y ago
        Once again, no, that’s not the problem. PostgreSQL and RDS are quite a bit more than just a log-structured data store, and are not prima facie the correct solution for this problem domain, regardless of how much arrogant ignorance you bring to bear on the debate.
        zetalyrae 3y ago
        [flagged]

foldr 3y ago

That sort of logic doesn't really apply here because: * RDS costs obviously scale linearly with ongoing time and probably scale linearly with the total amount of data being backed up. So depending on the revenue of the business, these extra costs could easily end up outweighing the (notional) cost of the time saved, which is mostly a one-off expense. * The cost of a software engineer's time is notional in the context of a one-person business. The author of Tarsnap isn't going to be able to employ fewer than zero additional software engineers to maintain Tarsnap because of the time saved by using RDS.

zetalyrae 3y ago
[flagged]
- gus_massa 3y ago
  Perhaps I'm biased, but I read every part like: > I realized that this was introduced by some code I wrote in 2014: Occasionally Tarsnap users need to move a machine between accounts, with an implicit "and I fixed that code now" or "and I will fix that tomorrow when I get enough sleep". Let's hope he writes later a follow up explaining the details. > [a] postmortem on the front page of HN Is that bad? I upvoted this almost instantly, then went to the comment section to upvote cperciva if he was here, then I read the full post and verified my first upvote was correct.
- foldr 3y ago
  The outage was caused by a hardware failure and (I assume) the lack of any redundancy. Using RDS wouldn't have made a difference as far as I can see.
  - zetalyrae 3y ago
    RDS can have replication. But more than that: servers should be stateless! A server going down should never take down your business. If you use Postgres, and stateless servers, then if a server goes down it's no problem, it gets rebooted and there may be other servers and a load balancer to pick up the load. If Postgres goes down, you have a replica, or it gets rebooted, and Postgres always recovers from crashes (in my experience), and if it doesn't you have PITR. AWS has everything under the sun to prevent this kind of thing happening. This is a 1990's outage. This didn't have to happen.
    - foldr 3y ago
      The hardware failure was on the server running the application code, so RDS replication wouldn’t have helped. You’re right of course that this failure points to a lack of redundancy – but that’s a separate issue from choosing S3 vs. RDS as the data layer. By the way, S3 is insanely reliable and in fact more reliable than a replicated RDS setup. So switching from S3 to RDS would almost certainly reduce the basic reliability of the data layer, however many conveniences it might bring.
      - zetalyrae 3y ago
        Once again, the problem is not S3, it is reinventing a database on top of S3, the logic of which runs on EC2.
        catiopatio 3y ago
        Once again, no, that’s not the problem. PostgreSQL and RDS are quite a bit more than just a log-structured data store, and are not prima facie the correct solution for this problem domain, regardless of how much arrogant ignorance you bring to bear on the debate.
        zetalyrae 3y ago
        [flagged]