a tornado of razorblades

Paul Graham’s essay on tablets referenced a fascinating term I hadn’t heard before: “ephemeralization.” Wikipedia describes it as “the ability of technological advancement to do ‘more and more with less and less until eventually you can do everything with nothing’.”

An example: video playback technology

Fifty years ago, the only option for watching video was an entire movie theater, with a huge projector fixed in place, and film reels the size of barrels for a single movie. The 1980s gave us VCRs and VHS tapes: a playback device that you could carry with two hands and that offered more features than a movie theater (like pause, fast forward, and rewind); the tapes were small enough that you could keep a reasonably sized movie library on your bookshelf. In the 1990s we got DVD players and DVDs, shrinking the playback device yet smaller, shrinking the movie media (tapes -> DVDs) yet smaller, and offering yet more features (like higher resolution).

In the 2000s Playstaions, XBoxes, and computers appeared with built-in DVD players, shrinking the playback device to nothing (it became part of a device you already owned). And in 2010, with Netflix streaming, you have instant access to tens of thousands of movies without needing any physical media at all. The playback device and media have both shrunk to have no corporeal representation whatsoever (hence “ephemeralized”), yet you have access to movie movies and more features for playback of those movies than ever in the past.

Ephemeralization at Heroku

Heroku is a company built on the premise that running a software as a service can be ephemeralized. Where Netflix streaming eliminates dedicated playback devices and media, Heroku eliminates servers, routers, and most or all systems administration.

Ephemeralization is a core value of our engineering and product design approaches. I believe this has been a big part of our success: internally, it helps us succeed at building a scalable, maintainable infrastructure; and externally, it helps us succeed at offering a lean product which has not turned into a swiss army knife despite ever-expanding capabilities.

Machete, not a swiss army knife

One of our core values on product design is that we want to create a machete, not a swiss army knife. A machete is a simple tool that has wide application to many tasks. A swiss army knife is a complex tool that has specialized gadgets for each task you might want to perform. (See James' startup school talk, about 12m in, for further elaboration.)

Some examples of user-facing ephemeralization Heroku has executed:

• Switching from our custom gems manifest to the community, off-the-shelf solution of Gem Bundler. This allowed us to maintain much less code and documentation, while offering a more sophisticated gem dependency system. Rails 3 comes with a Gemfile out of the box, so to the user’s perspective, the effort of declaring your version of Rails as a gem dependency has disappeared.
• Our new logging system merges all logs into a single stream, so logs:cron is no longer a separate codepath. Users can still filter to just their cron logs, but this is done via a general-purpose filtering interface.
• Those of you who have been using Heroku since the beginning will recall we once had a single sign-on system (known as heroku_user) that allowed you to use your Heroku user login to log into your app. This was a cool feature, but in the end the maintenance cost was high and the gain low. More general-purpose, standards-based solutions such as Google Apps login became commonplace (with tools like Warden to help Rubyists use them), so we removed heroku_user altogether and let users roll their own.

Each of these changes gave our platform a more machete-like user experience.

Ephemeralizing infrastructure

Internally, we’re always looking for opportunities to reduce or eliminate infrastructure.

One example of this was when we switched from a specialized server type for our main database (the one that contains our user, app, and billing records) to a database running on the same system we use to provision databases for Heroku user apps. Self-hosting gets us more leverage out of our existing database management and monitoring tools.

We also look to replace internally-built tools with off-the-shelf solutions whenever we can. Two examples of this are when we switched from a custom-built pager system to PagerDuty, and switching from a custom-built logging system to syslog and Splunk.

Each of these changes made our ability to manage and scale our infrastructure substantially easier. Fewer moving parts means less to keep track of, less to worry about, and less to go wrong.

Applying ephemeralization at your company

If you decide that you’d like to apply this principle at your company, how do you do it?

Everyone is your company should be constantly pushing to do more with less. This means being willing to look at every component, every user-facing feature, and every line of code with a critical eye. Some questions you should be constantly asking:

• What can replace with third-party solutions? (like Heroku did with gems manifest -> Bundler, custom pager -> PagerDuty, and custom logger -> syslog/splunk)
• What user-facing features can be merged together to create a more machete-like UX? (like Heroku did with cron:logs -> logs)
• Where can we generalize an existing system in order to have it take over the duties of a more specialized system? (like Heroku did with our specialized database server -> self-hosted database)
• What can we eliminate completely when its cost vs benefit analysis comes up short? (like Heroku did with our heroku_user single sign-on system)

Proposals to ephemeralize a component or feature will sometimes be met with emotionally-charged responses from your team. It’s totally reasonable to feel attached to a component everyone has worked hard on and has been important historically. But realize that the component has value because it got you to where you are today, not necessarily because of its ongoing existence in the future.

Everything Heroku has ever ephemeralized out of our infrastructure was part of our journey to the product and infrastructure we have today. I don’t regret for a moment all the time I spent coding on our single sign-on solution, our old cron log fetcher, our gems manifest, or any of a host of other things that are either gone or are fading out of our product today.

Referencing to video example again: DVDs were a fantastic bit of innovation and brought the world forward into the modern age of movie-watching. But our love of DVDs shouldn’t be a blocker to us adopting new technologies with more capabilities and a smaller footprint, like on-demand streaming video.

Conclusion

Every month, Heroku strives to do more with less. More: users, traffic, capabilities, and versatility for the users. Less: lines of code, components, moving parts, APIs, server types, tools. Ephemeralization is how we keep our product and our infrastructure lean and nimble over the long term.