4 ms·

Thanks for the thoughtful reply. I think that you raise some valid points here. Regarding "If you are big you are paying an incredible premium to be on Heroku"

by jaryd 15y ago

Thanks for the thoughtful reply. I think that you raise some valid points here. Regarding "If you are big you are paying an incredible premium to be on Heroku": Sure, Heroku is great (or cheap) for development and small-time deployment, however it is likely true that people get locked into it and (hopefully) grow quickly before they can scale away from a PaaS solution. In these cases, it is imperative to consider the marginal cost of alternative/off-site failover vs. the cost of downtime. This is what I meant by "separate the men from the boys". Those guys who are paying the incredible premium to continue to host on Heroku likely -know- that they are doing so, and have made that decision consciously. While the situation is different, I am reminded of when AWS went down awhile back and the sites that had automated failover to alternative clouds really stood out. The bottom line is that no one solution is ever enough. Tiny apps can likely get away with unexpected//unplanned downtime, however it ultimately delegitimizes them in the eyes of their users (read: customers), and that is universally bad.

dasil003 15y ago
Sure, but my point is that if you determine you need 100% uptime and you are currently on Heroku, you are going to need to build a complete non-Heroku system to fail over to. At that point should you A) pick another high level PaaS provider and maintain two very different stacks, each of which is commanding a high premium, or B) build on a standard Linux stack that can be deployed to multiple completely separate clouds?
- rdl 15y ago
  Or C) Heroku should develop and deploy fully independent availability zones and regions. Amazon hasn't yet done a great job of keeping AZ and even regions independent but better connected than separate providers, but maybe Heroku could do better (even if built on EC2).
  - dasil003 15y ago
    That would be a valuable service for Heroku to provide, but being better connected also implies more likely for joint failure, even if Heroku does everything right, there is stampede failure risk (which is what happened in the last major EC2 cross-zone outage). In any case, I think if you are seriously pursuing 100% uptime, you can't outsource your redundancy.
    - rdl 15y ago
      "better connected" could just be a billing thing; they make sure there is great transport (their own, transit providers, whatever) between AZs running in separate ASes, and don't bill for inter-AZ traffic.

by jaryd 15y ago

dasil003 15y ago

Sure, but my point is that if you determine you need 100% uptime and you are currently on Heroku, you are going to need to build a complete non-Heroku system to fail over to. At that point should you A) pick another high level PaaS provider and maintain two very different stacks, each of which is commanding a high premium, or B) build on a standard Linux stack that can be deployed to multiple completely separate clouds?

rdl 15y ago
Or C) Heroku should develop and deploy fully independent availability zones and regions. Amazon hasn't yet done a great job of keeping AZ and even regions independent but better connected than separate providers, but maybe Heroku could do better (even if built on EC2).
- dasil003 15y ago
  That would be a valuable service for Heroku to provide, but being better connected also implies more likely for joint failure, even if Heroku does everything right, there is stampede failure risk (which is what happened in the last major EC2 cross-zone outage). In any case, I think if you are seriously pursuing 100% uptime, you can't outsource your redundancy.
  - rdl 15y ago
    "better connected" could just be a billing thing; they make sure there is great transport (their own, transit providers, whatever) between AZs running in separate ASes, and don't bill for inter-AZ traffic.