I don't think you are in any position to decide what I do or do not have a strong understanding of. Let's break down your thoughts:
1.) Downtime - You seemed to gloss over my primary point. The downtime today could have been completely avoided if Heroku did not opt to do a 2pm EST scheduled maintenance. This was a very large risk they took and it blew up in everyone's face.
As far as resolving downtime. I stand by my original statement that a PaaS like Heroku cannot recover as fast on average as another solution. They have too many customers that they have to get up and running.
5) Buildpacks - I've been fielding this one on Twitter all day and am considering writing another blog post. I didn't really give much weight to this one and that opens it up to attack pretty easily. Here is my point:
Buildpacks in general do not suck. Heroku's implementation of Buildpacks sucks. Customizing Heroku buildpacks is a nightmare. Maintaining said fork is nearly impossible. There is no versioning of the buildpacks. There is no way to know if/when slugs are updated and my fork is no longer useable or needs to merge in upstream changes. Getting anything into the official buildpacks is a political nightmare. Adding CLI tools not in the heavily stripped down Ubuntu AMI is a gigantic pain in the ass.
re: puppet - I'm not sure why you're hammering me for Puppet as I never mentioned it. You seemed to assume that this is what we will use.
3) Pricing - I dismiss most of your argument unless we're talking about Heroku's database hosting. Their DB hosting is awesome and top-notch. Their app hosting has become a less than stellar. I don't even know what I'm paying for anymore. To me managed devops means I don't ever have to deal with pager duty or I can just hand customers over to someone after we launch their product. That's not Heroku, not by a long shot. At best we're getting security fixes and system updates applied. At worst we are paying a premium on resold EC2 instances for a deploy shell script that has been freely available for a while now.
I don't know about you but I don't really spend that much time swapping the underlying language. At least not without some heavy consideration, what we go with is usually thought out from the start of the project. To me, I'm not interested in the least in being able to swap out MRI for JRuby with a change of a line. In nearly 10 years of professional Rails development I have maybe had to do this twice. Upgrading Ruby is a different story, but that is also not something that should be done lightly.
Today's post was a culmination of years of frustration with the platform. I've had it, we're done with it. Moving on. Good riddance.
1. I don't think your primary point was that valid in that people are going to have to deploy during the middle of the day sometimes, and mistakes happen sometimes. We all have deployed an app with a bug in it at one point or another.
For heroku it is tougher, they are the app that runs other apps, so bugs have a much larger impact. I would hope they have post mortem's and take actions to ensure this doesn't happen again. IE why wasn't this caught in a staging environment?
I agree that heroku totally fucked up, I would feel terrible if I was the engineer that fucked this up (as they should). However I think you are throwing the baby out with the bathwater.
I have seen outages last 1 hour + at big startups in the valley, it happens. I am not saying that it is right, I am saying that it is very difficult to do right, and very few companies are able to do it. It generally takes quite a few people to do it and far too often I have seen it come at the cost of being able to move quickly. Not excusing heroku for making these mistakes, I think it blows pretty hard. I just think there is no good alternative.
I believe that you are seriously underestimating the amount of effort required to deliver 99.9% reliability. I also believe you are underestimating how much heroku does for you on a git push if you think it is a bash script that has already been written. If that were true we would all have Heroku behind the firewall.
5. Heroku's implementation of buildpacks on their stack sucks? They have the only real implemenation of buildpacks? I agree forking/maintaining the fork sucks, I think there should be an easier way to install apt-get dependencies (ENV var).
Alternatively you can use: https://github.com/ddollar/heroku-buildpack-multi which supports versioning and chaining. You just make a buildpack for your custom bits, and install it before your ruby buildpack
I agree I don't often switch between ruby interpreters, however I do frequently upgrade MRI ruby versions, and the fact that it as easy as changing one line has saved me a lot of time. IMO this is much easier than any alternative I am aware of.
I have written a few buildpacks and I have found buildpack multi to be pretty composable.
I agree Dockerfiles are a decent alternative, however the part missing is a scheduling/discovery layer. Mesos docker integration is coming along via the folks at mesosphere but you still need to wire up the bits and pieces yourself.
3. I agree it is expensive, I think it is cheaper than a full time ops person to a pretty decent scale, and I think you need a lot more than 1 ops person to get close in terms of SLA, and featureset.
Honestly I think you just traded one set of problems for another. Who is going to get paged when both the vm's hosting a service die? Who is going to get paged when you run out of disk space? Co-location of apps? Hosting multiple ruby versions on all your hosts?
I don't fully appreciate your model but IMO it sounds like you have a client expectations problem.You should set the deliverable as a deployable app with the target as heroku, if they want to pay more for a VM they can pay more but they should understand the tradeoffs. If they want their own custom maintained servers or pay for you to maintain them, but it ain't free. It will cost you time and hopefully their money.
I don't swap language often if ever, however I do like to use more than one language depending on the problem I am solving.
1.) Downtime - You seemed to gloss over my primary point. The downtime today could have been completely avoided if Heroku did not opt to do a 2pm EST scheduled maintenance. This was a very large risk they took and it blew up in everyone's face.
As far as resolving downtime. I stand by my original statement that a PaaS like Heroku cannot recover as fast on average as another solution. They have too many customers that they have to get up and running.
5) Buildpacks - I've been fielding this one on Twitter all day and am considering writing another blog post. I didn't really give much weight to this one and that opens it up to attack pretty easily. Here is my point:
Buildpacks in general do not suck. Heroku's implementation of Buildpacks sucks. Customizing Heroku buildpacks is a nightmare. Maintaining said fork is nearly impossible. There is no versioning of the buildpacks. There is no way to know if/when slugs are updated and my fork is no longer useable or needs to merge in upstream changes. Getting anything into the official buildpacks is a political nightmare. Adding CLI tools not in the heavily stripped down Ubuntu AMI is a gigantic pain in the ass.
But if that is not enough for you I'll end this point with David Dollar who did a ton of work while at Heroku with its buildpacks https://twitter.com/ddollar/status/481201978391801857
re: puppet - I'm not sure why you're hammering me for Puppet as I never mentioned it. You seemed to assume that this is what we will use.
3) Pricing - I dismiss most of your argument unless we're talking about Heroku's database hosting. Their DB hosting is awesome and top-notch. Their app hosting has become a less than stellar. I don't even know what I'm paying for anymore. To me managed devops means I don't ever have to deal with pager duty or I can just hand customers over to someone after we launch their product. That's not Heroku, not by a long shot. At best we're getting security fixes and system updates applied. At worst we are paying a premium on resold EC2 instances for a deploy shell script that has been freely available for a while now.
I don't know about you but I don't really spend that much time swapping the underlying language. At least not without some heavy consideration, what we go with is usually thought out from the start of the project. To me, I'm not interested in the least in being able to swap out MRI for JRuby with a change of a line. In nearly 10 years of professional Rails development I have maybe had to do this twice. Upgrading Ruby is a different story, but that is also not something that should be done lightly.
Today's post was a culmination of years of frustration with the platform. I've had it, we're done with it. Moving on. Good riddance.