Heroku: Why Instant Deployment Matters (YC W08) | Hacker News Reader

Heroku: Why Instant Deployment Matters (YC W08)

blog.heroku.com

83 pointsjnl17 comments

Once every hundred years media changes!

I wish people would stop conjuring up mathematical models to add drama to their observations.

Firstly, mathematics makes for poor theater. Secondly, the silly models distract from otherwise sensible observations: media changes and development gets faster.

But, in the end, the only sensible sweeping generalization may be past performance does not guarantee future results.

I get your point: the deployment-to-development ratio has increased as we've streamlined development processes faster than deployment processes. I understand the underlying theme, Heroku is going to kickass in deployment. More power to you.

Here's what bothered me about this post:

- Scrum fanboyism. It was unexpected and threw me off track while I was reading. I felt it negatively detracted from your point.

- Capistrano bashing. You certianly gave Cap it's due, but calling it an "incremental improvement" compared to what you've got in store takes balls. We'll see how that pays off.

I know this is just a preface to some (hopefully) technical articles about your work, but on it's own, it's just fuzzy math and hype. Here's to some meat in the next one.

Awesome comment. Wow, "scrum fanboyism" is definitely not what I was going for there - just trying to poke fun at how these teams have changed over the years.

Yes, the technical details are on the way - we're excited to share them.

Are these numbers based on speculation?

Since when serious applications are written in 1 week in 2008? You could write 1-week applications since the dawn of computing. Haven't you heard? BASIC was written by B. Gates and P. Allen in 8 weeks.

Has software development really gotten 160x faster in the last 10-15 years? It's a moving target, of course, since people keep trying more ambitious things as tools get more powerful. But that number doesn't feel right to me.

On the other hand, the main argument - that the percentage of effort occupied by deployment has grown - may not need that figure.

Considering there are things you can do with web apps now that you couldn't do at all in 1996, I'd say for some use cases web development is now "infinitely" faster.

Sure you could. You could have built the web and everything you needed and then written your app :)

"Development is faster" presumably means "relative to what people are trying to do". That's the sense in which the OP uses it, because he's talking about development going faster per project. The concept is problematic since what projects consist of has changed as much as everything else has.

The figure that are stated in the article are quite obviously made up but conceivably close to real life scenarios. I think the author is way off on the last example, though: "It then takes just one person a few days to provision new resources from IT or a fast-moving hosting company, install the default web stack, and do the initial deploy." I can see that for an IT department but not for a fast-moving hosting company. With all of the deployment tools available, most of the deployments I've done have ranged from a few minutes (RailsMachine) to a few hours (barebones install). All that aside, though, instant deployment would be pretty darn cool.

Comment I left on the post:

As a potential customer, instant deployment is not what appeals to me. If I knew that 1 day after my code was done, my app would be working just perfectly, I'd be a happy camper. Instant deployment = cool but not mission critical... at least not for me. (Now, if deployment took 2 weeks, I'd be pissed.)

What appeals to me about Heroku is exactly what I like about my MacBook Pro: It just glides. I don't have to think about it. Things just work (at least in theory.) It's not the time, but the thinking about deployment that I'd like to remove.

I just click the magic deploy button (command) and tada, "It's a live." And if I hit the jackpot and land a massive client or show up on TechCrunch, things will just keep on gliding smoothly. And hopefully, I'll make more money and serve more clients.

That is the ideal I'd like to reach.

Now instant deployment might be something I fall in love with (like git) but I'm not there yet. I just want things to "just work" for now.

Ah, bingo. Yes, "it just works" and "it glides" are exactly what we're going for. Our version of the magic deploy button is "git push". We've got some great detailed posts coming up about this.

The thing that we've discovered is that instant and "it just works" are tightly related. If something takes minutes or hours to do (even if automated), it's likely that there are many steps involved - each of which is a potential point of failure.

Your last sentence rings especially true. Each step is a potential point of failure. I tried to set up cap and passenger one day but got stuck on a couple of steps. Sure I could have plowed through and gotten it to work eventually, maybe switched to a different computer or whatever but time is precious. The word "easy" is thrown around too casually in tech circles. Today I've got three domains running on herokugarden and it still shocks me how short the procedure is. Thanks.

The historic argument you guys are trying to push trough to enhance your pitch is shadowing the purpose of your heroku itself because of its controversial nature.

I will advise you remove the whole history thing from your argument and take a different approach of selling your tool which I think has good potential.

I agree. It's enough to say that development has gotten much faster, but deployment is still a slow pain in the neck, and you are the guys who are going to change deployment. Most of the time the smooth, concise story sells best, in my experience.

A valid point undermined by the extravagant attempt to prove it.

I think the numbers/graph are necessary. Of course they are made-up, but the point is the trend over time. I find this argument quite compelling, and I wouldn't have found it interesting had it just been a qualitative description of these trends.

I get the sense that your numbers are based on speculation rather than hard data.

I have several examples of sub 1 week development time to first release from projects we've done in the last few years. But then the initial deploy for those projects, on average, took about 20 minutes of one person's time.

Iterative development often goes hand-in-hand with iterative deployment. Somewhere during week 3, we'd spend an hour moving onto an automated build and deploy system, and from there on out it would be push-button.

Once, and only once, the site got big enough to need its own dedicated box at a colo, so that added an extra couple days building a server, driving it to the facility and moving the site. But by then we were 3 months into development, so the effort was nowhere near 25% of our total spent man hours.

Cool idea for a service though. But maybe you're painting the picture a little more dire than it needs to be.

One thing his historical comparison completely neglects is there was a time when people actually cared about performance (or rather they were so constrained by it they were forced to care). On the other hand most of these one-week wonders suffer from "we'll just throw more HW at it" syndrome.

Reply on news.ycombinator.com