Blog Post

Heroku to Exit Beta, Start Charging for Cloud Computing

herokulogo Heroku will unveil tomorrow the commercial version of its Ruby-focused cloud platform, which — in a world full of management interfaces, configuration files and provisioning policies — virtually eliminates the need for a user to do any of the associated grunt work. It’s a process the San Francisco-based startup calls “provisionless hosting.”

In Heroku’s cloud, deploying web applications becomes a trivial process, where developers can forego the busy work of configuring app servers and databases, and of allocating resources to each component. As co-founder and CEO James Lindenbaum explained, while he applauds the work being done to improve the management layers of existing cloud offerings, “We think that’s actually the wrong direction. We think this stuff shouldn’t be so complicated.”

Heroku achieves its mission by utilizing code management tool Git. Developers simply create a code repository for Heroku, push their code to the service and Heroku takes care of the rest. The platform consists of open-source, best-practice-proven web architecture pieces that are captured in a read-only, high-performance copy of a user’s application used to create new application instances in less than two seconds, according to Lindenbaum, vs. a few minutes for most new instances on Amazon EC2 (s amzn). Instead of having to be able to predict load a couple of minutes out, “We can assume that the traffic you’re gonna have two seconds from now is basically the same as the traffic you’re gonna have now,” he said.

It’s worth noting here that Heroku is built on EC2, but Lindenbaum claims that its architecture provides far higher performance because it was built from the ground up to take advantage of EC2. And while he calls Amazon the most viable option available today, he told me that there are many advantages to cross-cloud deployment, and that, “[T]here are other very compelling solutions out there today that we’re looking at.”

Heroku offers a “one-stop shop” style of pricing, though everything about the platform is open (unlike Google’s App Engine, which requires users to write specifically to Google’s infrastructure) and users could at any point move their apps to another cloud that supports Ruby. (The company also notably signed on to the much-maligned — and much-supported — Open Cloud Manifesto.)

It’s too early to tell how Heroku will fare in the real cloud computing marketplace — the one where users actually pay — but the simplicity of its platform bodes well for success. Heroku attracted 25,000-plus applications and 23,000-plus users during its beta period, and that number should grow as Ruby, also known for being user-friendly, gains popularity. By focusing on developers, who appreciate Heroku’s model because it allows them to spend the entirety of their time on application improvement, Heroku should be able to infiltrate enterprises from the ground up.

8 Responses to “Heroku to Exit Beta, Start Charging for Cloud Computing”

  1. Rajeev Kutty

    I agree with Michael on this one, as more and more enterprises look at deploying their applications on cloud, the selection of ‘the cloud’ platform will be influenced by

    1) Backward compatibility (ease of implementation, learning curve,etc…)
    2) Degree of lock-in (It is not just the cost factor!)
    3) Scalability, Performance & Security
    4)Total cost (surprise!, indeed it is NOT the first thing to consider)

    Heroku still has its work cut out, but Google just got a step closer with its support for Java. I am also curious about level of support and escalation process when multiple clouds are involved.

  2. Michael Mullany

    It seems to me that the really big question here is which approach is going to win in the market:

    A) the cloud approach that Amazon and Engine Yard are taking — which is you need to bend over backwards to ensure “backward compatibility” meaning that in order to attract customers to your platform, you have to make sure they can re-use the code and technologies that they’re used to using.

    B) the cloud approach of heroku and google app engine — which is that everything is fine as long as you re-write everything you need in pure ruby/java/python and run it on top of Google’s runtime (or Heroku’s dyno).

    In software history, not having a backward compatibility strategy has always been a recipe for failure.

  3. Derrick Harris

    It’s not so much the app layer as it is about the data layer. Unless something has changed, App Engine still includes BigTable as the default database, whereas Heroku uses SQL. An app written to leverage BigTable certainly couldn’t be transported to any other platform without some changes being made.

    That’s not to say one approach is better than the other, though. Anyone who wants to work with Python or Java, or to take advantage of BigTable, might consider any potential Google lock-in worth outweighed by the benefits of the platform. For its part, Heroku acknowledges that its open-source, best-practices approach does leave it subject to effortless customer abandonment, so it relies on the customer experience to keep them on board.

  4. jamesyi

    also, by putting heroku on top of ec2, youre increasing the number of points of failure, which if youre trying to run a scalable and reliable webapp, youre now relying on both ec2 and heroku being up and running. i think this is the hidden danger of cloud copmuting, is that you start to not know how many layers youre dealing with, and if any of those layers goes away, youre screwed.

  5. jamesyi

    confused…what about appengine isn’t as open as this solution? particularly with the java version that was just released, they implemented almost all the standard java classes, and all the other stuff they implemented is supported by jrs standards. in fact, i watched the video from their campfire, and they took the code running in appengine and copied it over to ibm websphere without changing a line of code.

    sloppy reporting, you should check your facts and publish a correction.