Heroku

Develop a Voice App with Twilio + Heroku, Win a Netbook

Mon, 06 Jul 2009 19:18:08 GMT

Not too long ago building telephony apps, such as interactive voice response systems, was far out of reach for most web developers. Now, an exciting crop of new startups is rapidly changing that, making it easy to incorporate voice capabilities into any web app, or even build standalone voice apps.

Twilio is emerging as one the leading companies in this area, offering a a REST API for building voice apps.

The model is simple: sign up for a number with Twilio. When a call comes in, Twilio makes an HTTP request to URL of your choice, containing information about the phone call. The processing logic resides entirely inside your web app, and instructions are passed back and forth using XML.

To help kick off this new era of voice-enabled applications, Heroku is co-sponsoring this week’s edition of Twilio’s Developer Contest. The rules are simple – develop a Twilio app in Ruby, deploy it to Heroku and submit your entry by midnight on July 13th. The lucky winner gets a netbook and $300 in Heroku platform credit to spend on dynos, database, or add-ons. This page has all the info you need, including links to example code on Github and a screencast showing how it works. We look forward to seeing the entries!

Railslab Interview

Wed, 01 Jul 2009 21:07:21 GMT

Railslab is a great site by our friends over at New Relic that contains a wealth of knowledge on Rails scaling and application performance.

A couple of weeks ago they asked Ryan and Adam to stop by for a discussion of the vision behind Heroku, and the philosophy that drives the design and buildout of our scalable, provisionless hosting platform.

The interview is now available for your viewing pleasure in three parts. In the first part Adam goes into detail about the core vision behind the concept of instant deployment, and how Heroku is committed to making the deployment of Ruby web apps a seamless extension of an agile development workflow.

In the second part Ryan and Adam discuss how scalability and performance really emerge from a strong focus on understanding and implementing the correct solution to common application design problems. This goes straight to the essence of what we like to call stack curation. By providing a fully managed, state-of-the-art application stack we aim to replace the hurdles of tedious configuration and maintenance that often keep developers from doing things the right way with the first truly provisionless hosting environment. With Heroku, we’re not just looking to make correct design possible – we’re looking to make it so easy that it’d be downright shameful not to :)

Finally, the guys discuss some of the tools & services they use in their daily work, and what they think is important to have in your arsenal to really inform your development work – especially in a cloud computing environment.

Whether you’re just curious about Heroku, or an existing user there’s a lot of great information about our platform in these interviews, and we hope you’ll check them out. Big thanks to the guys over at New Relic for yanking Ryan & Adam away from their respective keyboards long enough to get this on tape!

Pimp Your Cart: Shopify Apps on Heroku

Thu, 11 Jun 2009 21:54:57 GMT

Our good friends at Shopify recently released a developer platform which makes it crazy easy to build custom functionality into an e-commerce store using a standalone Rails app. There are already some great apps available in their app store, many of which are running on Heroku. (The shopify.com homepage also now lives here.)

Check out the excellent getting started video by James MacAulay. It shows just how slick the Shopify API is – these guys are really taking e-commerce to the next level. (And bonus points for use of config
vars to store API keys!)

Add-on: Wildcard Domains

Wed, 27 May 2009 19:09:09 GMT

Since we returned from a fun and successful Railsconf in Vegas, we have been in full swing completing the rollout of our paid services. The response has been enormous so far, and paid services are now available to all users.

If you’ve checked out the pricing page, you’ve undoubtedly noticed our line-up of a la carte add-ons. We’re really excited about add-ons becoming a key part of our platform, allowing us to seamlessly deliver popular application services and components with the built-in scalability and ease of use you’ve come to expect from Heroku.

We’ve had a solid first batch of add-ons in beta for a while, and today we’re happy to announce the first graduate: Wildcard Domains, which allows your app to respond on *.yourdomain.com. Since we started supporting custom domains on Heroku this has been high on the list of requested features, and now it’s here! To add it to your app for $5/month, simply go to your app’s Resources page and select turn it on. Enjoy!

Railsconf Schedule

Sun, 03 May 2009 19:57:09 GMT

Railsconf starts tomorrow and Heroku will be there in full force. Here’s our line up:

Monday, 1:30pm — A Hat Full of Tricks with Sinatra

Our very own Blake Mizerany, the creator of Sinatra, is giving a tutorial on Sinatra. Ryan Tomayko will be on hand as well.

Tuesday, 1:50pm — The Future of Deployment: A Killer Panel

Join me as I moderate a panel on deployment, with a truly killer group: Marc-André Cournoyer (creator of Thin), Christian Neukirchen (creator of Rack), Ryan Tomayko (Rack core team, creator of Rack::Cache, Sinatra core team), Blake Mizerany (creator of Sinatra), and Adam Wiggins (Heroku cofounder, creator of RestClient, Rush, and many others).

Wednesday, 10:45am — Rails Metal, Rack, and Sinatra

Adam will be giving a great talk on the latest and greatest about Rack, Rails Metal, multiple Rack endpoints, and even a bit of Sinatra. The patterns and methods he’ll discuss are the latest in scalable architecture best practices for Ruby apps.

Wednesday, 2:50pm — Heroku: Guided Tour and Q & A

Most of the Heroku team will be on hand to walk you through the Heroku platform, show off some new features, and answer questions.

Thursday, 9:25am — HTTP’s Best-Kept Secret: Caching

Ryan Tomayko will be giving a talk on what’s probably the most important issue in Rails right now: HTTP caching. This extremely powerful, transparent, and easy to implement technology is badly misunderstood and misused today. Ryan has been on the front lines for a long time, and is truly an expert; you’re bound to come out of this talk with a new, inspired perspective on HTTP caching.

Exhibit Hall — Heroku Booth

Once again we’ve got a big booth in the exhibit hall, where we’ll be demoing new features, answering questions, and giving out schwag. The Heroku team heavyweights will be available to answer your questions and help you sort out issues with your individual apps, or to just do some hacking. We’ll also be giving out t-shirts, stickers, and free credits for Heroku paid-services.

New Heroku Screencast by Remi

Thu, 30 Apr 2009 07:22:02 GMT

It’s been a bit of a blur here at Heroku HQ in the past couple of weeks. However, amidst all the launch activity we did notice a screencast so sweet we thought we’d share it with you. It really covers the whole platform exceptionally well, and we particularly dig how it manages to show off both Rails and Rack app deployment.

Big ups to Remi for putting this together, and way to shame us for not getting any official screencasts together for the new and improved Heroku. :)

Commercial Launch

Fri, 24 Apr 2009 06:18:31 GMT

When Adam, Orion, and I started Heroku two years ago, we had no idea how much new technology we would have to build to realize our vision of an instant platform for Ruby that just works.

Luckily, we were able to attract an amazing team to work on this problem with us, and the team has really shaped Heroku into the offering it is today. We’re currently by far the fastest and easiest deployment platform for Ruby, and we’ve gotten great feedback on our provisionless hosting architecture.

We have over 25,000 apps running on the platform today, and many of our users have been asking for pricing and paid services for some time now. So today we’re pleased to announce that we are officially out of beta and available for commercial use.

Detailed pricing information is now available.

Dynos

As discussed previously, our system is built around a dyno grid that allows us to deploy your app just by pushing your code, and to scale it up and down instantly. Your app runs inside this grid in any number of dynos.

The number of dynos you run directly affects the concurrency and therefore the performance of your app, so our pricing is based around this same concept. The first dyno for an app is always free, and additional dynos will be billed at $0.05 per dyno-hour.

Play with the dyno slider on our pricing page to estimate your bill.

You can scale your dynos up and down instantly at any time via the web interface, our API, or our command-line gem.

Database

At the database layer, we have two categories of options. We offer a shared database cluster in three storage sizes. The smallest size is free, and you can upgrade/downgrade between options instantly at any time.

For more serious needs, we also offer three dedicated database plans, ranging from small to large in compute and storage levels. These can also be changed at any time, but resizing requires a few moments of downtime.

Add-ons

We’re also officially launching some add-on features. Some of these features, like backups and more frequent cron tasks are paid features. Others, like custom domains and SSL are free, but require you to enter your billing information as an abuse protection measure (more info).

There is a lot more to come – you can get a preview by checking out the beta features in the add-ons section.

Free Service

It’s important to us to continue to provide a free service tier, useful enough to get started with Heroku. This is still available, and is the default for new apps with a single free dyno and free shared database.

This free tier is well suited for rapid-prototyping, staging, and testing purposes, as well as actually running lightweight apps.

Pricing and paid-features are being rolled out in phases across our user base. It may take a few days for commercial service to be activated for all accounts.

The official press release is available here.

Config Vars for Deploy-Specific Settings

Tue, 07 Apr 2009 19:28:22 GMT

Say you’re working on a Rails app, and you want to publish your code on Github. Most apps have some deploy-specific private config values – for example, if you’re using the S3 storage backend for Paperclip, and your S3 keys are saved in config/amazon_keys.yml. You certainly don’t want to push those up to Github – what to do?

You could maintain a separate deploy branch, and commit your deploy config only to that. You can then work on the main branch, and rebase the deploy branch whenever you go for a deploy. That’s a bit of extra work you could do without, though – and you know sooner or later, you’re going to accidentally push the wrong branch to Github, putting your S3 keys up for the whole world to see. Oops.

Wouldn’t it be nice avoid all this headache by storing the data specific to your app’s deploy in a separate configuration registry?

Now you can. Check it out:

$ heroku config:add S3_BUCKET=mybucket S3_KEY=8N029N81 S3_SECRET=9s83109d3+583493190
Adding config vars:
  S3_BUCKET => mybucket
  S3_KEY    => 8N029N81
  S3_SECRET => 9s83109d3+583493190
Restarting app...done.

Your config vars are now accessible in the environment variables for your deployed app. Configure Paperclip like this:

has_attached_file :photo,
  :storage => :s3,
  :s3_credentials => {
    :access_key_id => ENV['S3_KEY'],
    :secret_access_key => ENV['S3_SECRET']
  },
  :bucket => ENV['S3_BUCKET'],
  :path => ":attachment/:id"

Set up like this, your public code and your deployed code can be exactly the same. Push to Github all day long with no fear of leaking your private credentials. Clean and neat, no fuss, no muss.

This also means you can set different config vars for different deployed versions of the app. For example, if you run a staging deploy of your code on Heroku, you can set it to use a different S3 bucket – maybe “myapp_assets” for production and “myapp_staging_assets” for staging.

What about running locally, deploying to a traditional host? Since these are just environment variables, you can set them just as you normally would – in your .bashrc (export S3_BUCKET=mybucket), or on the command line when you run the server.

Or, you can check for the presence of the vars, and use defaults when they don’t exist. In the case of Paperclip, you might do:

has_attached_file :photo,
  :storage => ENV['S3_BUCKET'] ? :s3 : :filesystem,
  ...

Now when you run locally, it’ll use the filesystem store; but running on a deployed app with the S3_BUCKET var set, it’ll automatically go to the right place.

There are many other uses for config vars. For example, you can set RACK_ENV to something other than the default of ‘production’. (RAILS_ENV and MERB_ENV will automatically mirror RACK_ENV on Heroku.) So if you prefer the traditional approach of storing different keys for different environments (development/staging/production) in various config/something.yml files, set your RACK_ENV as appropriate for your staging and production deployed apps on Heroku.

Read the full documentation. Note that you’ll need to grab the 0.7 Heroku client gem (it’s in Rubyforge now, so `gem install heroku` will do the trick) to use this feature.

Fork Our Docs

Wed, 01 Apr 2009 18:46:48 GMT

Heroku is now sporting an updated docs layout at docs.heroku.com. These new docs should be much easier to navigate and link to.

We built this as a standalone Sinatra app serving Markdown files, partially inspired by Assaf Arkin’s approach to Buildr. It uses Cache-Control with a long max-age, to take advantage of the Varnish http cache which fronts all Heroku apps. This makes it as snappy as staticly rendered pages, while retaining the flexibility of a dynamic app on the backend.

The docs app is deployed as a regular app on Heroku (just like this blog). Nothing special-case here: we deploy with git push, just like any other Heroku user. Dogfooding is good for you.

The app’s source is on Github. Fork and send us a pull request if you want to make edits to improve the wording, fix a typo, or even add a whole new section. Watch the repo to keep an eye on new additions to the docs. Or fork and use the code as the basis for your own docs app (though we ask that you not use our images or colorscheme).

Let’s also take a moment to give a nod to AsciiDoc, which we’ve been using for our docs up until now. Although it didn’t turn out to be a long-term solution as a docs CMS, it was a great way to get off the ground. We highly recommend it to anyone looking for an easy way to get good-looking HTML docs generated from a simple and intuitive markdown format.

Heroku at Railsconf

Mon, 30 Mar 2009 23:49:59 GMT

Heroku is gearing up for Railsconf 09 in Las Vegas, and just like last year, we’ve got a sweet line-up for y’all…

Kicking things off on Monday, Sinatra co-creator Blake Mizerany will be hosting an in-depth tutorial on the the micro-framework that’s sweeping the Ruby nation right now.

Continuing in a similarly minimalistic vein on Wednesday, Adam Wiggins will lend his considerable Rack-fu to a talk showcasing Rails Metal – the hot new feature in Rails 2.3 that lets you build Rack endpoints for selected URLs that bypass Routes and ActionController for a massive speed boost. Heck, he’ll even show you how to use Sinatra inside your existing Rails app!

Finally, we’ve put together a massively kick-ass panel about The Future of Deployment. At Heroku we’ve put an immense amount of research into building the ideal Ruby stack based on open-source standard components. This event will be a unique opportunity to discuss every part of it in detail. Joining key members of the Heroku team will be Marc-Andre Cournoyer, creator of Thin and Christian Neukirchen, creator of Rack. We can’t stress enough just how freakin’ excited we are to have these guys join us for what should be a highlight of the conference.

In addition to these talks, Heroku will be present in full force at Railsconf, and we’ll be announcing more details about that as the date grows closer. This is definitely the event in the Ruby community, and we hope to see you there. If you haven’t registered yet, hurry on over to the Railsconf website, and use the code “RC09FOS” for a 15% discount.

Radiant CMS in 5 Minutes Or Less

Thu, 26 Mar 2009 20:45:08 GMT

Radiant is an excellent Rails-based Content Management System (CMS). It was created by John W. Long and Sean Cribbs, and has been around for a couple of years, growing steadily in popularity. With the recent addition of taps and gem manifeststs, it’s super-easy to get this lightweight CMS up and running on Heroku.

Start by installing the latest radiant gem on your local box:

$ sudo gem install radiant

Now use the radiant command-line tool to set up your Radiant CMS locally. We’ll use SQLite as the local database:

$ radiant --database sqlite mycms
$ cd mycms
$ rake db:bootstrap

Before we can push to Heroku, we’ll need to initialize a git repo in our project directory:

$ git init

By default, Radiant caches CMS pages in RAILS_ROOT/cache. This won’t work with Heroku’s read-only file system, so before deploying we’ll change it to make sure cached files are written in the tmp directory. Open up your config/environment.rb, and change the cache config line so it reads:

config.action_controller.page_cache_directory = "#{RAILS_ROOT}/tmp/cache"

We’ll also add a gem manifest to make sure the radiant gem is installed on Heroku when we push. Radiant depends on rSpec 1.2.2, so our .gems file should look like this:

rspec --version 1.2.2
radiant --version 0.7.1

Then commit your changes:

$ git add .
$ git commit -m "changed cache dir and added gem manifest"

Now it’s time to create an app on Heroku and deploy this baby to it.

$ heroku create
Created http://vivid-fog-54.heroku.com/ | git@heroku.com:vivid-fog-54.git
Git remote heroku added
$ git push heroku master
....
-----> Heroku receiving push
-----> Rails app detected
       Compiled slug size is 5.4MB
-----> Launching.......... done
       App deployed to Heroku

Finally, we’ll transfer over our local database using taps:

$ heroku db:push
Auto-detected local database: sqlite://db/development.sqlite3
Sending schema
Sending data
9 tables, 57 records
schema_migrat: 100% |==================| Time: 00:00:00
config:        100% |==================| Time: 00:00:00
page_parts:    100% |==================| Time: 00:00:00
extension_met: 100% |==================| Time: 00:00:00
sessions:      100% |==================| Time: 00:00:00
pages:         100% |==================| Time: 00:00:00
snippets:      100% |==================| Time: 00:00:00
layouts:       100% |==================| Time: 00:00:00
users:         100% |==================| Time: 00:00:00
Sending indexes

And now our Radiant instance is live and ready to go!

Push and Pull Databases To and From Heroku

Wed, 18 Mar 2009 19:38:35 GMT

A frequent question people ask us is “how do I transfer my database between my local workstation and my Heroku app?”

This is an important question for several reasons. First, you always own your data on Heroku, and we want you to be able to get to it quickly and easily at any time. Also – as you may have noticed from previous posts – we’re obsessive about workflow. Whether you’re debugging an issue with production data or setting up a staging environment, being able to quickly pull/push data between environments is key to a smooth experience.

Previously, we offered yaml_db as a solution. We liked that it was simple and database agnostic, but parsing large YAML files is just too slow. We also wanted something that works with any framework compatible with our Rack-based platform. Ricardo, Blake and Adam came up with Taps, which was released last month as a standalone project. Having collected some quality feedback from the community, we’re now pleased to announce that Taps is officially baked into Heroku, allowing seamless and easy database transfer between Heroku apps and any external environment.

To try it out, install the latest Heroku gem. Then use the “db:pull” command to pull your database down from your Heroku app to your local workstation:

$ heroku db:pull
Receiving schema
Receiving data
8 tables, 591 records
users:         100% |================================| Time: 00:00:00
pages:         100% |================================| Time: 00:00:00
comments:      100% |================================| Time: 00:00:00
tags:          100% |================================| Time: 00:00:00
Receiving indexes
Resetting sequences

This loads the schema, data, indexes and sequences of the remote Heroku database down into the local database specified in config/database.yml. You can also specify the destination database using standard URI-syntax:

$ heroku db:pull mysql://root:mypass@localhost/mydb

Because Taps uses ActiveRecord (for schema) and Sequel (for data), it seamlessly transfers between different database vendors. In fact, if you don’t feel like running a local database server, just use SQLite:

$ heroku db:pull sqlite://path/to/my.db

Of course, the syntax for pushing your local database up to Heroku is equally simple:

$ heroku db:push
Sending schema
Sending data
users:         100% |================================| Time: 00:00:00
pages:         100% |================================| Time: 00:00:00
comments:      100% |================================| Time: 00:00:00
tags:          100% |================================| Time: 00:00:00
Sending indexes
Resetting sequences

That’s Taps in a nutshell. It’s live right now, so check it out and let us know how you like it. Full docs are available here.

Rails 2.3

Mon, 16 Mar 2009 15:42:15 GMT

The Rails 2.3.2 gem is now installed and available for use on Heroku. To learn more about what’s new and improved, check the official Rails blog post.

Enjoy!

Gem Manifests

Tue, 10 Mar 2009 20:38:09 GMT

Gem installation and management has always been pain when the time comes to deploy an app. Rails 2.1 made good progress in this area with gem dependency specifications, allowing you to vendor required gems with a of set rake commands. That’s the method we’ve been recommending for Heroku apps until now, but it does leave important problems unsolved.

First, a substantial limitation of the vendoring method is that it only works with pure Ruby gems. Many apps depend on gems with native extensions that need to be compiled on the deployment target. It’s no good compiling a gem on your Mac laptop and trying to deploy the resulting binary to a Linux host.

Then there’s the issue of adding extra bulk to your code repo by checking in vendored gems. Bulkier repos cause slower deploys, and slower usually equates to fewer. From a process perspective, the net result is decreasing the agility of your codebase. And in a cloud computing environment, these translate to direct scalability consequences: big repos don’t scale as fast as lean ones.

A next-generation web host should have a next-generation solution to this problem. Today we’re excited to introduce just such a solution: gem manifests, the new standard for gem installation and dependency management on Heroku!

Here’s the skinny: add a file named “.gems” (this is your gem manifest) to the root of your app. Here you can list your gems in a format identical to what you would pass to “gem install” on the command line:

hpricot --version '>= 0.2' --source code.whytheluckystiff.net
dm-core --version 0.9.10

Commit the file, git push to Heroku, and watch as your gems are fetched and installed. For Hpricot, native extensions are compiled before your very eyes!

$ git add .gems
$ git commit -m "added gem manifest"

$ git push heroku master
Counting objects: 4, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 356 bytes, done.
Total 3 (delta 1), reused 0 (delta 0)

-----> Heroku receiving push

-----> Installing gem hpricot >= 0.2 from http://code.whytheluckystiff.net
       Building native extensions.  This could take a while...
       Successfully installed hpricot-0.6
       1 gem installed

-----> Installing gem dm-core 0.9.10 from http://gems.rubyforge.org
       Successfully installed addressable-2.0.2
       Successfully installed extlib-0.9.10
       Successfully installed data_objects-0.9.11
       Successfully installed dm-core-0.9.10
       4 gems installed

-----> Verifying repository integrity... done, looks like a Rails app.
       Compiled slug size is 4.3MB
-----> Launching.............. done
       App deployed to Heroku

To git@heroku.com:vivid-moon-60.git
   91425e3..fe10e87  master -> master

As you can see, this gem manifest is lightweight, framework-agnostic (works great with Sinatra), and won’t add any weight to your repo since installation is done in the cloud. Your gems are automatically in the require path, so you can pull them into your app easy-as-pie. Finally, gems are only compiled when the manifest changes, so subsequent deploys will be fast as ever.

Check out the docs, take it for a test-drive, and tell us what you think.

Deploy Merb, Sinatra, or any Rack App to Heroku

Thu, 05 Mar 2009 23:32:21 GMT

The past eighteen months have seen an explosion of Rails-inspired Ruby web frameworks. Merb and Sinatra are the best known; plus many others such as Ramaze, Camping, and Waves.

That’s why we’re so pleased to announce the ability to deploy any Rack-compatible web app to Heroku.

Assuming you have a Heroku account, here’s how you can deploy a Sinatra app in about 30 seconds. Make a new directory, and inside create hello.rb:

require 'rubygems'
require 'sinatra'

get '/' do
  "Hello from Sinatra on Heroku!"
end

Then create a config.ru file in the same directory (the location follows the Passenger convention):

require 'hello'
run Sinatra::Application

Now let’s put our microapp under revision control with Git:

$ git init
Initialized empty Git repository in /Users/adam/hello/.git/
$ git add .
$ git commit -m "sinatra and heroku, two great tastes"
[master (root-commit)]: created 93a9e6d: "sinatra and heroku, two great tastes"
 2 files changed, 9 insertions(+), 0 deletions(-)
 create mode 100644 config.ru
 create mode 100644 hello.rb

Finally, create the app on Heroku and deploy:

$ heroku create
Created http://severe-spring-77.heroku.com/ | git@heroku.com:severe-spring-77.git
Git remote heroku added
$ git push heroku master
Counting objects: 4, done.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 385 bytes, done.
Total 4 (delta 0), reused 0 (delta 0)

-----> Heroku receiving push
-----> Verifying repository integrity... done, looks like a Rack app.
       Compiled slug size is 0.1MB
-----> Launching....... done
       App deployed to Heroku

To git@heroku.com:severe-spring-77.git
 * [new branch]      master -> master

Type “heroku open” at your shell (or cut-and-paste the web URL displayed when you created the app – in the example above it was http://severe-spring-77.heroku.com/). Congratulations, you’re riding the Rack!

For more details, including how to deploy other frameworks or even a frameworkless Rack app, check out the docs.

Deployment That Just Works

Tue, 03 Mar 2009 22:59:20 GMT

Last week I talked a bit about why instant deployment matters. A few people have since commented that it’s not instant deployment that matters to them, but rather deployment that just works every time.

Of course, what we’re really talking about is both. Part of achieving deployment that just works is decreasing complexity and removing steps – each a point of possible failure. We are working toward deployment that’s both instant and completely reliable, because we think those things are tightly linked.

We’ve rolled out some new content today explaining more about how our platform works, including some more detailed architectural information. We’re hoping it will continue to build a better picture of the vision we’re striving for. I want to take some time here to explain some of the background behind this architecture.

Instant deployment that just works is, of course, a tall order.
In order to achieve it, there are several requisites:

1. A Sharp Focus on Web Apps

Provisioning is different for different types of apps – a video transcoding farm is very different from a web app. The only way to make the process instant is to know what type of thing you’re dealing with ahead of time. This is achieved by only handling one type of thing (Heroku, for example, only handles web apps, and even then, only those written in the ruby language).

2. Standardization of App Structure

Any time you want to plug and play, most of the work is centered around standardization. Because all lamps have the same power plug and voltage requirements, you can move them around freely and plug them in anywhere. Similarly, all apps need to be self-contained and have the same structure and environmental requirements.

A software framework like Ruby on Rails (or even just Rack) gets us most of the structure we need, but a lot of work remains in self-containment and standardization of environmental requirements.

3. A Dynamic Platform

Aside from standardized plugs and voltage, the reason you can plug a lamp in anywhere is that hidden behind the walls, there’s a complex system of wiring, circuits, breakers, and transformers, which distribute power to the lamps evenly and only when needed, and prevent short circuits and other safety hazards. If one lamp has a short, it won’t destroy the other lamps or your home.

Similarly, we need a platform architecture that can move apps around independently, start and stop them instantly, provide the standardized environment (library dependencies, databases, caching, etc.), distribute compute power evenly, and prevent one greedy or malfunctioning app from damaging others.

4. On-Demand Provisioning of Underlying Infrastructure Resources

Lastly, no matter how many lamps you plug in (within reason), you won’t run out of power. The enormous capacity of electricity producers combined with a sophisticated grid of distribution and storage technologies ensure that power is available right when you need it. This whole system works because you don’t have to plug in a lamp and then wait for someone to turn on another generator somewhere.

This last requirement is non-trivial, and has historically been a major barrier to instant provisioning/deployment. Thankfully it’s available now, in the form of utility computing from services like Amazon’s EC2. When compute power is needed, you can get it within seconds or minutes. It’s still not instant, but it’s close enough that an efficient dynamic platform can hide this delay by maintaining standby capacity (the same way batteries and capacitors hide the delay of a generator starting up on the electrical grid).

This is the real value of utility computing: it has the power to enable truly instant provisioning and deployment, by providing one of the four requisites.

Heroku’s Architecture

We discovered the 4 requisites above as we built our platform, so our current architecture is designed specifically to address these issues. Item 1 is embodied by our decision to specialize on Ruby-based web apps, and item 4 is simply available to us today for the first time.

Items 2 and 3, however, deserve some explanation:

2. Standardization of App Structure

The overall structure of our platform is designed to standardize the web stack, vastly simplifying the deployment process and removing a lot of decisions you might have to make when designing and deploying an app.

Should we use memcached? It’s already included. What about static content? Don’t worry about it – our high-performance HTTP cache will handle it automatically. How many app servers should we run, and how many machines do we need for them? Just start with a few and change it instantly at any time, and never even think about how many servers they’re running on.

We’ve also settled on a standard app stack we call a dyno. The way an app retrieves its configuration from the environment has also been standardized.

3. A Dynamic Platform

We’ve done a huge amount of work on this over the last year, and our efforts have been focussed by the 25,000 apps now running on Heroku. The routing mesh gives us the ability to easily move apps around, and to scale our resources independently of scaling an individual app.

The dyno grid lets us scale an app up, as well as distribute power evenly and route around problems.

This architecture let’s you deploy via Git by simply pushing your code to your app’s Heroku repository. We’re actually “compiling” your app now as it’s pushed; performing integrity checks and verifying that it can start.

So did we get there? Have we achieved instant deployment? Well, we think we’re getting pretty damn close.

Why Instant Deployment Matters

Mon, 23 Feb 2009 18:55:37 GMT

How much better are two steps than three? Does it matter if something takes five minutes instead of twenty? When it comes to software deployment and provisioning, does instant really matter?

Recently, I was ranting on this subject to a user who had the misfortune of asking me about it in person.

“Truly instant provisioning and deployment is the ultimate goal,” I said. “10 seconds isn’t good enough. We have to –”,

“Look,” he interrupted, “I love what you guys are doing and don’t want you to stop, but why are you so obsessed with this?”

My immediate answer: because we’re obsessive people. A couple years ago we stumbled across what we view as a glaring disconnect between the way software is developed and the way it’s provisioned and deployed. Now, like a person who’s noticed a crooked picture on the wall, we are totally fixated on setting it straight.

This was a shallow answer though, and he wasn’t convinced:

“I mean it’s not that bad as is, is it?” he said. “It’s been improving steadily for years.”

And that’s when it hit me. While everyone is adversely affected by this growing problem, most people don’t actually see it. It has crept up on us gradually.

1996: A development team of perhaps 10 people (toting advanced computer science degrees) spends 6 months building software to laboriously defined specifications, writing their own framework, and using limited libraries and no testing harness. It then takes an IT team of say 3 people a couple of weeks to provision server resources, configure and install the OS and software stack, and deploy the software.

2000: A more ambitious team of 6 people (toting half-finished computer science degrees) spends 3 months building a web application to satisfy a PRD, using primitive frameworks and some integration testing. It then takes 3 people about a week (optimistically) to provision servers from IT, install the web stack, and deploy the app.

2004: A 4-person team (half of whom went to art school) spends 4 weeks writing a web app to some short and loose specs, using decent frameworks, unit and integration testing, and lots of user feedback. It then takes just 2 people about a week to provision virtual servers, install a complete web stack, and deploy the app.

2008: An agile team of 4 people (plus perhaps a scrum master) spend a week building the first complete version of their web app from just a rough user story, using advanced web frameworks, fully featured libraries, test-driven development, and sharp agile practices. 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.

Let’s look at these data points:

The bottom row is the percentage of the total project/iteration time spent on provisioning and deployment. Look at it this way:

This is shocking. Provisioning and deployment has gotten 10x faster during this period, but development has gotten 130x faster. Development teams are getting smaller and more agile, doing shorter iterations (deploying more often), and scaling their apps more quickly (more frequent provisioning). This results in a dramatic increase in the portion of time spent provisioning and deploying.

At this rate, in less than 3 years we’ll be spending as much time deploying and provisioning as we spend developing. These numbers are based on our direct experience with medium/large company software projects. You can play around with the scenarios; even with widely different numbers the curve is about the same.

The reason most people don’t see this growing problem is because it’s masked by the gradual improvement of the deployment and provisioning process.

Capistrano, for example, is an awesome deployment tool, which makes us feel great about the improving state of deployment tools. But these incremental improvements aren’t keeping up with agile development; they’re an investment in a race that can’t be won.

We see this playing out often now. We’ve been contacted by quite a few Fortune 500 companies lately who, after a massive agile restructuring of their software development organization, discovered they are now spending as much time on provisioning as development. All the economic benefit of agile development is consumed by provisioning – this has enormous fiscal impact.

How do we solve this problem? It doesn’t seem possible to both make provisioning/deployment faster than development, and also keep it there by continuously improving at a higher rate. How do we get off this treadmill?

What if we could provision and deploy instantly? This is where the difference between “a little” and “none” comes into play. If it’s instant, the portion of time spent on it goes to zero. The development process can then improve at any speed, and deployment/provisioning will never become a barrier. Problem solved.

This is, by the numbers, why instant deployment matters.

How are we actually achieving instant deployment? Over the next two weeks we’ll be posting more information on the challenges involved, and how we’ve designed Heroku’s architecture to meet them.

Build a news site with Rubyflow

Tue, 10 Feb 2009 23:09:31 GMT

Ruby journalist extraordinaire, Peter Cooper, is a busy man. Chances are you’re already following his work to bring you the latest Ruby news on sites such as Ruby Inside and RubyFlow. Late last year he even added a tremendously useful site oriented towards iPhone and iPod Touch development called Mobile Orchard. Somewhere along the line he was also generous enough to leak the source code for Rubyflow, and now a version of that is available through Sutto’s Github repository.That’s great news for anyone looking to start their own news site, especially since it’s a breeze to get working on Heroku.

Start by cloning the source from Github:

$ git clone git://github.com/Sutto/rubyflow.git

Rubyflow depends the thoughtbot-factorygirl gem, so next we’ll make sure to install that and unpack it in vendor/gems:

$ rake gems:install
$ rake gems:unpack

I also found that the captcha used in Rubyflow’s user registration requires “digest/sha1” to be required explicitly, so go ahead and add

require 'digest/sha1'

at the bottom of config/environment.rb. Once you’ve done that it’s time to commit our changes to git:

$ git add .
$ git commit -m "vendored gems and required digest/sha1"

With that out of the way, it’s time to create an app on Heroku and deploy to it:

$ cd rubyflow
$ heroku create 
Created http://high-fire-37.heroku.com/ | git@heroku.com:high-fire-37.git
Added git remote heroku
$ git push heroku master
...
App deployed to Heroku.

Finally, we run migrations to set up the application database:

$ heroku rake db:migrate

…and there you have it!

Be sure to read the docs on site configuration and customization here.

Enjoy!

The Future of Deployment

Fri, 06 Feb 2009 02:04:44 GMT

Application deployment is changing. In relatively short order I’ve gone from buying hardware, to monthly hosting, to metered CPU time, and from building my open-source software manually, to package managers, to fancy config tools and recipes to pre-build whole machine images. What’s next?

The Old Way

I can deploy Rails apps in a traditional hosting environment pretty quickly. For a small app, I might make a new unix user and database on a personal Slicehost slice and do a quick code checkout. After setting up a few permissions and twiddling my Nginx config, in a matter of fifteen minutes or so my app is online. Not bad at all.

For a bigger app, it takes more time. In days of yore I’d build a server from parts or buy one of the excellent Pogo Linux servers and put it in a colo. OS install, Xen setup, guest OS install, OS package setup, security lockdown, then on to the task of all the stack setup (database, Rails, source control) specific to the application to be run.

Once you get into multiple servers, the complexity multiplies out quickly. There are dozens of small decisions to make about how resources are allocated. More RAM or more CPU for the database machine? One slave database, or two? Hardware load balancer vs. multiple IPs vs. something else? All of these require both detailed knowledge about hardware and software deployments, combined with a huge amount of predictive guesswork to try to foresee the quantity and type of load that the app being deployed is likely to face in the next 3, 6, or 12 months.

There’s an enterprisey word for this process: provisioning.

The New Way

Amazon’s EC2 is the vanguard of the new generation of cloud computing. Provisioning a server was formerly a phone call and days or weeks of waiting. Now it’s a REST call and 30 seconds of waiting. Awesome.

But this is a very raw resource: there are still many provisioning decisions to be made, software to set up, and then on to deployment of the app itself. Excellent services like RightScale and Engine Yard’s new offering Solo can help automate a lot of this process and minimize the management burden. So far, so good.

But what if provisioning was instantaneous, requiring no upfront decisions about resource allocation? What if you didn’t need to think at all about the server hardware or software, but only about your application code? How would this change how we build applications?

The Future

When technology breakthroughs make something smaller, or faster, or cheaper, it doesn’t just change current use; it creates whole new types of use. If app deployment is instantaneous, without having to plan for resources, allocate servers, or beg approval from the IT department, what kind of apps will we build that don’t get built today?

In the past decade we’ve seen widespread adoption of agile methodologies in the development of software. This has transformed software development from a slow, failure-prone, and sometimes downright painful process into one that is fast, fun, and fulfilling. But deployment of applications has changed hardly at all during that same time period. The way you deploy a Rails, Merb, Sinatra, or Django app today is very similar to how you deployed a Perl app in 1999.

This coming decade is going to see an agile revolution for the deployment side of the equation. The manual, guesswork-heavy methods of provisioning that we use today are soon to be superseded by methods that will make deploying an app fast, easy, and fun.

No one knows quite what that will look like yet (though at Heroku we certainly have our own opinion), but one thing is for sure: the time is ripe for a revolution in IT.

Heroku + Suspenders

Tue, 13 Jan 2009 01:52:16 GMT

Making Rails readily accessible to developers of all stripes is a big part of the vision behind the Heroku platform, and we try to be supportive of any initiatives that make teaching and learning Rails easier.

A couple of months ago, thoughtbot released suspenders – a freely available Rails template app, loaded with commonly used plugins, sensible configuration options and helpful rake tasks. Simple as it may seem, having a solid default app template is a really important step in eliminating the barriers that prevent developers from jumping directly from concept to coding with Rails. We think thoughtbot are doing the Rails community a real service with this project, so do yourself a favor and check out the github repo and take it for a spin.

Naturally, suspenders runs wonderfully on Heroku :)