They went down literally the moment our demo thing started. I swear this is because of me.
Same here! This happened last year too! Annoying.
Heroku is down
71–80 of 107 posts
Re: Heroku is down
#72As a newbie, I've really enjoyed deploying on Heroku. However these outages really terrify me. Is there an easy way to host a redundant version of your app outside of Heroku?
Ask a simple question, get a simple answer: No. This is no knock on Heroku, either. No hosting solution can make that easy: it is an enterprise requirement which implies six figures of investment and a dedicated ops team with no newbies on it.
I'm sorry, but that's completely untrue. I can't speak for using Heroku specifically, but in the end hosting is just running an app. It's fairly trivial to make an app multi-provider these days through a plethora of methods. DNS and a low TTL is on the easiest-to-approach end if your app is designed for it and aware of the complications, which implies thinking about your database and other supporting architecture from the perspective of a multihomed setup. If your app isn't idempotent nor designed to be multihomed, it'll be harder, but six figures of investment is insanely high even in that awful case.
Perspective: I could throw an app on Rackspace and Amazon, with a replicated database, for under $200, in about a day.
Re: Heroku is down
#73What would really help in these situations is a failover to our maintenance pages or some other static page we could provide instead of showing the Heroku "Application Error". This is probably harder then it seems, especially when the outage is related to their routing infrastructure.
Well, there is an option to have error pages on your heroku domains, but that is probably dependent on at least a minimum level of the routing layer working. https://devcenter.heroku.com/articles/error-pages
Yeah, I have that setup but its not being used at the moment with this outage - if full redundancy with multiple regions is a huge challenge, perhaps some interim basic routing redundancy would go a long way so we could at least display a branded error page during an outage.
Re: Heroku is down
#74Earlier quoted context omitted.
If you use Cloudflare it will serve a static version of the site until it is back online.
I always use Cloudflare in front of Heroku; mainly because of that and the cheap & simple SSL set-up that they have.
Do note that Cloudflare is throwing mallware/captcha notices to legitimate users, which is extremely annoying.
When I get such a screen I immediately close the website I'm visiting. And no, contrary to what they tell me, I do not have "a virus" nor is my computer part of a botnet.
Re: Heroku is down
#75Earlier quoted context omitted.
If you use Cloudflare it will serve a static version of the site until it is back online.
I always use Cloudflare in front of Heroku; mainly because of that and the cheap & simple SSL set-up that they have.
Also, careful with Cloudflare SSL. It only secures between the browser and Cloudflare's data center. The connection between your server and Cloudflare remains non-SSL.
Re: Heroku is down
#76Earlier quoted context omitted.
Ask a simple question, get a simple answer: No. This is no knock on Heroku, either. No hosting solution can make that easy: it is an enterprise requirement which implies six figures of investment and a dedicated ops team with no newbies on it.
I'm sorry, but that's completely untrue. I can't speak for using Heroku specifically, but in the end hosting is just running an app. It's fairly trivial to make an app multi-provider these days through a plethora of methods. DNS and a low TTL is on the easiest-to-approach end if your app is designed for it and aware of the complications, which implies thinking about your database and other supporting architecture fro…
One of the problems with using multiple providers is you can't use any of the specific features of a provider.
For example, I really like AWS's security groups and ELBs. Those serve as my firewall and my load balancer and SSL terminator.
Replicating the application to another service means configuring and testing all that on my own.
If I use heroku and use their logging system, then replicating it to another provider means I need to be an rsyslog expert.
I don't really want to be an expert on rsyslog, postgresql configuration, floating IPs for HA LB, the best IO scheduler for file systems, etc. As someone who is in charge of all the sysadmin duties, and is solely responsible for writing all the business and db logic for several e-commerce sites, I want to spend my time on writing code. Not fucking around with figuring out the syntax for iptables.
Re: Heroku is down
#77Earlier quoted context omitted.
I'm sorry, but that's completely untrue. I can't speak for using Heroku specifically, but in the end hosting is just running an app. It's fairly trivial to make an app multi-provider these days through a plethora of methods. DNS and a low TTL is on the easiest-to-approach end if your app is designed for it and aware of the complications, which implies thinking about your database and other supporting architecture fro…
One of the problems with using multiple providers is you can't use any of the specific features of a provider. For example, I really like AWS's security groups and ELBs. Those serve as my firewall and my load balancer and SSL terminator. Replicating the application to another service means configuring and testing all that on my own. If I use heroku and use their logging system, then replicating it to another provider…
That's exactly why you don't want to use those features, for what it's worth.
Re: Heroku is down
#78Earlier quoted context omitted.
Ask a simple question, get a simple answer: No. This is no knock on Heroku, either. No hosting solution can make that easy: it is an enterprise requirement which implies six figures of investment and a dedicated ops team with no newbies on it.
I'm sorry, but that's completely untrue. I can't speak for using Heroku specifically, but in the end hosting is just running an app. It's fairly trivial to make an app multi-provider these days through a plethora of methods. DNS and a low TTL is on the easiest-to-approach end if your app is designed for it and aware of the complications, which implies thinking about your database and other supporting architecture fro…
The context of the original question was improving the availability of a product deployed to Heroku or other PaaS, which implies a lack of dedicated operations staff.
An experienced ops team willing to be on call 24x7 is easily six figures by itself.
Re: Heroku is down
#79Earlier quoted context omitted.
I'm sorry, but that's completely untrue. I can't speak for using Heroku specifically, but in the end hosting is just running an app. It's fairly trivial to make an app multi-provider these days through a plethora of methods. DNS and a low TTL is on the easiest-to-approach end if your app is designed for it and aware of the complications, which implies thinking about your database and other supporting architecture fro…
The context of the original question was improving the availability of a product deployed to Heroku or other PaaS, which implies a lack of dedicated operations staff. An experienced ops team willing to be on call 24x7 is easily six figures by itself.
If you are running an app that is utilized by more people than just yourself, there is never "a lack of dedicated operations staff". That situation simply does not exist in any known realm. In the case of a solo developer, you are the operations staff. You are on call, 24x7.
With that in mind, everything I talk about in my reply is doable by one person, or a solo developer. A cursory understanding of administration goes far, and if you're deploying to Heroku, you should know enough about administration to not be completely in the dark when things fall apart.
Deploying a mass-consumable Web service implies that you have accepted the fact that you are now a developer and administrator.
Re: Heroku is down
#80Earlier quoted context omitted.
They are at 99.97% uptime. It's not that easy to get to even 99.5%, just the flakiness of a standard uplink will put you below that.
Huh? The flakiness of a standard uplink will have you down for 44 hours a year? On what planet? With our non-AWS hosting providers we tend to see 2-4 hours of network issues per year . Heroku's uptime also hasn't historically been anywhere near 99.97%. They were down for several days last year in The Great AWS Failure.
This is in the context of hosting it yourself, not using a different large-scale business provider.