9 ms·

The article does not even mention availability. Service running on a single box will have downtime, both planned and unplanned. And you should think about RPO/R

by zokier 3y ago

The article does not even mention availability. Service running on a single box will have downtime, both planned and unplanned. And you should think about RPO/RTO too, when (not if!) the box blows up how long does it take to recover, and how much data will you lose. > No matter how you design your site, SPA, SSR, some hybrid in between you can’t get around that if there is at least one database query involved in rendering your page, you have to go back to your database in us-east-1. https://aws.amazon.com/rds/aurora/global-database/ https://aws.amazon.com/rds/aurora/global-database/ https://aws.amazon.com/dynamodb/global-tables/ https://aws.amazon.com/dynamodb/global-tables/ https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.RDS_Fea_Regions_DB-eng.Feature.CrossRegionReadReplicas.html https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Conce... https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Redis-Global-Datastore.html https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/... And so on.. Have fun kludging together the equivalents yourself.

floating-io 3y ago
Availability is overblown these days IMO. Ten or twenty years ago I would have agreed with you: the internet was new, and when the site went down, people blamed the site, and things got nasty fast. Nowadays, though? People are much more likely to blame their internet provider first, or just plain try again later. They're used to the unreliable nature of the internet now. Unless you're Google, but how many businesses are Google? As someone else on this thread said, simpler systems are less likely to fail anyway. Keep backups, replicate your DB to a cold DR site if you're truly worried. That will handle the majority of non-FAANG businesses in the majority of non-FAANG cases. And if that failure occurs? So long as you don't lose data, it will be a short-lived blip for most businesses. Even being down for a few days can be weathered if you have good PR, provided that it's a once in a blue moon sort of event. For that matter, data losses can be weathered in many cases. What was that saying? Each nine of reliability doubles the cost or some such? That needs to be accounted for when determining the ROI. How reliable does your business actually need to be? That depends on your target market. The default answer from IT, however, is an automatic "100%!". This is wrong, IMO.
- datascienced 3y ago
  Wat? If the site is down I’ll probably wont be back, and if I am paying for a service I am angry and might unsubscribe. Let alone lost revenue for the company from new sign ups or readers.
  - jakewins 3y ago
    Yeah agree - if a website doesn’t respond I immediately open google in another tab; if google doesn’t respond I blame my internet and swap to my phone. We’re all on redundant internet connections now.
  - kidintech 3y ago
    Your sentence ANDs together an overlap of a bunch of improbable scenarios: - if the site is down for more than a few seconds - if you attempt to access the site during its downtime - if you pay an ongoing subscription (this could very well be a non-profit site, or one that doesn't primarily drive its revenue from subscriptions) - if you feel like unsubscribing How much does this *really* affect a non-moonshot business?
    - datascienced 3y ago
      The article talks about a high traffic site, maybe a top 10 one or something like that. It is already a moon business, not a moonshot. For a small blog or local business, sure a bit of downtime is OK but why are they even bare metal when squarespace etc. exists.
      - kidintech 3y ago
        > The article talks about a high traffic site, maybe a top 10 one The article explicitly restricts the problem space to top 1000 websites. I've taken 30 seconds to browse through top 1000 websites and outside of the usual suspects up top, most of them look like https://www.pro-football-reference.com https://www.pro-football-reference.com or https://www.tempo.co https://www.tempo.co which to me are not far off blogs and local businesses.
simfree 3y ago
Running on bare metal nets you serious latency reductions and I/O bandwidth increases compared to the products you linked to, and you have significantly less complexity in a single server or dual server model, that is why operations like LetsEncrypt choose to use this dual physical server architecture to power their global services at web scale: https://letsencrypt.org/2021/01/21/next-gen-database-servers.html https://letsencrypt.org/2021/01/21/next-gen-database-servers... Very low internal latency from an on server database or directly adjacent database allows your software to run database queries orders of magnitudes faster and spend less resources per client served, resulting in a speedier, snappy experience for your end users compared to what any of these managed database services can provide in practice.
- nostrebored 3y ago
  Right, and to do what any of the services above do, you’re doing this in a HA setup on a per region basis and writing your own cross region consistency code. Users are not noticing the difference between 5ms lookups and 20ms lookups. They are noticing outages, data loss, and inconsistency.
  - simfree 3y ago
    Users are noticing the difference between 5 non-parallel database queries that each take tens of milliseconds to a distributed database compared to querying an on server or directly adjacent server in under 0.2ms. I am not proposing writing any additional cross-region consistentcy code, many CRUD applications have added zero cross-region consistentcy code and just left this entirely on Postgres to handle since bi-directional replicas are now a core feature. The more complicated you make your stack the more likely you will end up with outages, data loss and inconsistency. Using plain jane battle hardened, well developed tools that can serve the internet at scale from a single modern server gives you a very simple architecture where most of that architecture is getting significant improvements every quarter as the libre software community improves Linux, Nginx, Postgres, etc versus whatever random person Amazon is letting work on RDS or DynamoDB for the next year until they PIP them (as they almost always do).
chmod775 3y ago
> The article does not even mention availability. Service running on a single box will have downtime. So will your service running on AWS or equivalent. Complexity brings its own pitfalls and I don't think there's a web service in existence that never screwed this up. That is if it's not AWS itself having a screw-up.
Sammi 3y ago
You will have major availability problems on AWS. VPS is not worse off here.

by zokier 3y ago

floating-io 3y ago

Availability is overblown these days IMO. Ten or twenty years ago I would have agreed with you: the internet was new, and when the site went down, people blamed the site, and things got nasty fast. Nowadays, though? People are much more likely to blame their internet provider first, or just plain try again later. They're used to the unreliable nature of the internet now. Unless you're Google, but how many businesses are Google? As someone else on this thread said, simpler systems are less likely to fail anyway. Keep backups, replicate your DB to a cold DR site if you're truly worried. That will handle the majority of non-FAANG businesses in the majority of non-FAANG cases. And if that failure occurs? So long as you don't lose data, it will be a short-lived blip for most businesses. Even being down for a few days can be weathered if you have good PR, provided that it's a once in a blue moon sort of event. For that matter, data losses can be weathered in many cases. What was that saying? Each nine of reliability doubles the cost or some such? That needs to be accounted for when determining the ROI. How reliable does your business actually need to be? That depends on your target market. The default answer from IT, however, is an automatic "100%!". This is wrong, IMO.

datascienced 3y ago
Wat? If the site is down I’ll probably wont be back, and if I am paying for a service I am angry and might unsubscribe. Let alone lost revenue for the company from new sign ups or readers.
- jakewins 3y ago
  Yeah agree - if a website doesn’t respond I immediately open google in another tab; if google doesn’t respond I blame my internet and swap to my phone. We’re all on redundant internet connections now.
- kidintech 3y ago
  Your sentence ANDs together an overlap of a bunch of improbable scenarios: - if the site is down for more than a few seconds - if you attempt to access the site during its downtime - if you pay an ongoing subscription (this could very well be a non-profit site, or one that doesn't primarily drive its revenue from subscriptions) - if you feel like unsubscribing How much does this *really* affect a non-moonshot business?
  - datascienced 3y ago
    The article talks about a high traffic site, maybe a top 10 one or something like that. It is already a moon business, not a moonshot. For a small blog or local business, sure a bit of downtime is OK but why are they even bare metal when squarespace etc. exists.
    - kidintech 3y ago
      > The article talks about a high traffic site, maybe a top 10 one The article explicitly restricts the problem space to top 1000 websites. I've taken 30 seconds to browse through top 1000 websites and outside of the usual suspects up top, most of them look like https://www.pro-football-reference.com https://www.pro-football-reference.com or https://www.tempo.co https://www.tempo.co which to me are not far off blogs and local businesses.

simfree 3y ago

Running on bare metal nets you serious latency reductions and I/O bandwidth increases compared to the products you linked to, and you have significantly less complexity in a single server or dual server model, that is why operations like LetsEncrypt choose to use this dual physical server architecture to power their global services at web scale: https://letsencrypt.org/2021/01/21/next-gen-database-servers.html https://letsencrypt.org/2021/01/21/next-gen-database-servers... Very low internal latency from an on server database or directly adjacent database allows your software to run database queries orders of magnitudes faster and spend less resources per client served, resulting in a speedier, snappy experience for your end users compared to what any of these managed database services can provide in practice.

nostrebored 3y ago
Right, and to do what any of the services above do, you’re doing this in a HA setup on a per region basis and writing your own cross region consistency code. Users are not noticing the difference between 5ms lookups and 20ms lookups. They are noticing outages, data loss, and inconsistency.
- simfree 3y ago
  Users are noticing the difference between 5 non-parallel database queries that each take tens of milliseconds to a distributed database compared to querying an on server or directly adjacent server in under 0.2ms. I am not proposing writing any additional cross-region consistentcy code, many CRUD applications have added zero cross-region consistentcy code and just left this entirely on Postgres to handle since bi-directional replicas are now a core feature. The more complicated you make your stack the more likely you will end up with outages, data loss and inconsistency. Using plain jane battle hardened, well developed tools that can serve the internet at scale from a single modern server gives you a very simple architecture where most of that architecture is getting significant improvements every quarter as the libre software community improves Linux, Nginx, Postgres, etc versus whatever random person Amazon is letting work on RDS or DynamoDB for the next year until they PIP them (as they almost always do).

chmod775 3y ago

> The article does not even mention availability. Service running on a single box will have downtime. So will your service running on AWS or equivalent. Complexity brings its own pitfalls and I don't think there's a web service in existence that never screwed this up. That is if it's not AWS itself having a screw-up.

Sammi 3y ago

You will have major availability problems on AWS. VPS is not worse off here.