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…
Heroku is down
91–100 of 107 posts
Re: Heroku is down
#92Earlier 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.
Re: Heroku is down
#93Earlier 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…
Re: Heroku is down
#94Earlier 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?
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
#95Earlier 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…
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
#96Earlier 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…
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
#97Earlier 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.
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
#98Earlier 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…
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
#99Earlier 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.
Re: Heroku is down
#100Earlier 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.
Then "you," having acquired years of experience in designing and implementing distributed services, are making at least a 6-figure investment in opportunity cost.