Live data from Hacker News

Heroku is down

heroku.com

91–100 of 107 posts

Re: Heroku is down

#91
post #83

Earlier 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…

I am intrigued. Do you have any quick links on hand, or pointers on how one would go about learning how to set up something like this? Or just learning about how to distribute services in general? That is to say, I know my way around Linux, have set up single/standalone servers for all sorts of services, but have never known remotely where to begin on the distributed side of things, much less understand what is requi…

I learned from trial and error and also on the job. In my experience, how-tos are typically antiquated or not terribly clear. My best advice would be to dig into ServerFault and Google what you don't understand.

Re: Heroku is down

#92
post #48

Earlier quoted context omitted.

Honestly, that's pious bullshit. It's the thing people keep saying every time Heroku gets mentioned is that it'd do better than you would yourself for availability, but you'd have to be borderline incompetent to have as much downtime with a more traditional VPS / hardware hosting to match the combined Heroku / AWS downtime. We moved all but one of our Rails apps off of Heroku precisely because of the frequent downtim…

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.

Having administered several "standard uplinks" from 100 Mbit/sec all the way to multiple ten Gbit/sec links, I can safely say that if your transit isn't 99.999%, you need new transit.

Re: Heroku is down

#93

Earlier quoted context omitted.

That means that I need to know about (and program chef to do): logging security hardening firewalls backups (both point in time and complete backups, both for database and for any other artifacts like image uploads) testing backup recovery (both the point in time and complete backups) replication HA LB SSL termination postgresql configuration monitoring (security, system stats, application availability, individual pr…

I think before you put an app on the public Internet for people to consume, you should be comfortable with everything you listed plus more. You might not be doing it for the app at hand, but you should know it at least. Especially if you're doing a solo founder thing, you might be having to implement all of these things before you can afford ops. If you're deploying services without some of the knowledge in your list…

You do realize that it's a 6-figure investment to hire an engineer comfortable with all of those things plus more to deploy a multihomed setup?

Re: Heroku is down

#94
post #93

Earlier quoted context omitted.

I think before you put an app on the public Internet for people to consume, you should be comfortable with everything you listed plus more. You might not be doing it for the app at hand, but you should know it at least. Especially if you're doing a solo founder thing, you might be having to implement all of these things before you can afford ops. If you're deploying services without some of the knowledge in your list…

You do realize that it's a 6-figure investment to hire an engineer comfortable with all of those things plus more to deploy a multihomed setup?

A) My comment was very specifically focused on you, acting as a solo developer/founder, not a person you'd hire.

B) A multihomed setup is not a black box of mystery, and is nowhere near as expensive as people are saying from the hip.

Re: Heroku is down

#95
post #48

Earlier quoted context omitted.

Heroku is really good. You will probably have more downtime than them unless you hire a whole team of operations and admins and pay a lot of money for hosting. It may also take a while to build out the deployment and development tools they have.

Honestly, that's pious bullshit. It's the thing people keep saying every time Heroku gets mentioned is that it'd do better than you would yourself for availability, but you'd have to be borderline incompetent to have as much downtime with a more traditional VPS / hardware hosting to match the combined Heroku / AWS downtime. We moved all but one of our Rails apps off of Heroku precisely because of the frequent downtim…

Yeah, I think Heroku is better than other options for being a fast/easy way to deploy, and great UI and some useful tools, but the combination of lack of visibility into internals for debugging, Heroku outages, and EC2 outages is the reason I don't use it for anything in production.

I'd seriously consider Heroku if they were in multiple regions (fuck AZs, those are a lie). There are huge advantages to a PaaS in terms of speed and lack of hassle, and a well run PaaS is better than most developers at operations, patching, security, etc. (We're kind of unique in that we're better at operations than development, though.)

Re: Heroku is down

#96

Earlier 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…

Ultimately this is why it would be nice for the code/configuration to be independent of the operations. I agree it is unreasonable to expect a random developer to build AND MAINTAIN the entire stack for every project. PaaS makes a lot of sense, especially as a starting place.

The solution is either to have a PaaS provider who ruthlessly eliminates single points of failure (there isn't one, currently), or use some standardized software system which can be operated by multiple independent operators with nothing shared. Unfortunately, the only vendor-independent infrastructure is the physical server, various forms of VPS, etc. -- it's all at the IaaS level. As far as I know there's no PaaS type thing with a common interface which arbitrary providers can operate, with some kind of marketplace for users to pick operators independently from the technology.

Re: Heroku is down

#97
post #67

Earlier quoted context omitted.

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.

I don't think anyone ever considers hosting it on a desktop in the closet on DSL at home/office.

The competition for something like Heroku is EC2, VPS, or dedicated servers, in commercial colocation facilities. A good hosting facility is going to be a lot closer to 99.995% uptime for network and power to the box, but you can of course screw up past that point on your own.

Re: Heroku is down

#98
post #96

Earlier quoted context omitted.

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…

Ultimately this is why it would be nice for the code/configuration to be independent of the operations. I agree it is unreasonable to expect a random developer to build AND MAINTAIN the entire stack for every project. PaaS makes a lot of sense, especially as a starting place. The solution is either to have a PaaS provider who ruthlessly eliminates single points of failure (there isn't one, currently), or use some sta…

The solution is either to have a PaaS provider who ruthlessly eliminates single points of failure (there isn't one, currently)

This isn't possible by definition, right? The PaaS provider itself becomes the single point of failure.

Rings a bit like a "Who created God?" argument. "What single entity can I use to defend against failures by a single entity?"

Re: Heroku is down

#99
post #75

Earlier quoted context omitted.

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.

You actually have the option to enable SSL both on (customer->cloudflare) and (cloudflare->your server).

Re: Heroku is down

#100
post #93

Earlier quoted context omitted.

You do realize that it's a 6-figure investment to hire an engineer comfortable with all of those things plus more to deploy a multihomed setup?

A) My comment was very specifically focused on you, acting as a solo developer/founder, not a person you'd hire. B) A multihomed setup is not a black box of mystery, and is nowhere near as expensive as people are saying from the hip.

> My comment was very specifically focused on you, acting as a solo developer/founder, not a person you'd hire.

Then "you," having acquired years of experience in designing and implementing distributed services, are making at least a 6-figure investment in opportunity cost.

Post reply on HN