Heroku is at the end of its first full year as part of Salesforce.com. During that year, the number of applications running on the platform has grown eight fold to over 800,000. Byron Sebastian, Heroku's CEO, said that much of this growth has come from an increasing presence of enterprise customers, many of whom are new to the API-driven Platform-as-a-Service offering that Heroku offers.
The quality and ease-of-use of Heroku's APIs are central to its success. The alpha-geek startup developers want a stable and powerful API that allows them to create new applications. The enterprise community wants that, but also wants more of the trappings of a product: administration, monitoring, and security infrastructure. Both groups demand great design and documentation as a sine qua non. Heroku has expanded its appeal greatly by moving beyond its roots in the Ruby language to add support for Java, Python, Scala, Clojure, node.js, and others. I sat down with Sebastian this month to discuss the way Heroku approaches to the design and implementation of APIs and the lessons the company has learned.
Lesson 1: API First, without the Threat of Termination
The most entertaining "reply all" error of 2011 happened to have an important lesson for people looking to APIs to transform their businesses. Google engineer and Amazon alumnus Steve Yegge, recalled in this post that Amazon CEO Jeff Bezos that he threatened to fire anyone who didn't expose their assets through APIs.
The interesting part of this story is that Bezos was talking about internal APIs. It seems he wanted to make sure that all the different parts of Amazon could work together better, faster, and with fewer bottlenecks.
Sebastian said the Heroku has found that the same API first policy pays off over and over again. API first, of course, is not a policy that has much impact on Heroku's core offering, which is a set of APIs that allow people to create and deploy Ruby applications in the cloud. The API first policy has had the most impact in the way that Heroku has built all the componentry the surrounds its APIs, such as administrative interfaces, monitoring, account signup, and so on. Heroku has put APIs at the foundation of everything it has created and as a result, has reaped the benefit of innovation and flexbility in dozens of unexpected ways.
For example, Heroku has an API for managing the platform that allows starting and stopping of services and scaling the app up and down by adding or subtracting resources. This same API is used to support a command line interface. The same API is used to support a web console. Developers have taken that API and created an iPhone App to allow mobile management of Heroku sites.
"Our API first policy brings us dozens of unpredictable benefits," said Sebastian. "We have lots of stories of people using the mobile app to rapidly scale their web site up after a huge stream of traffic arrived because the site was mentioned on TechCrunch."
Lesson 2: Not All APIs are Created Equal
One of the key things to remember are that APIs are just another kind of interface and need to be designed with the same care that Apple or other great product companies bring to their products.
Sebastian points out that people have strong opinions when they go to web sites and can easily tell if the web site is well designed or not. If you don't know what to do next, if you cannot find what you are looking for, if you are confused, the design of the interface is usually to blame.
Sebastian suggest that people don't often apply the same design thinking to the creation of APIs. You have to bring the same level of art, technique, and craft to the challenge of API design that you should bring to designing any other type of interface.
"It's not just a matter of whether you have an API or not," said Sebastian. "But have you really thought through that API. You must really think about how developers are going to consume that API. You must deeply understand what is going to be intuitive for the developer in using the API, and so on."
In other words, sweat the design. Challenge and test your assumptions. Invoke the ruthless advocacy for the consumer that Steve Jobs brought to the table. A good API, like any good product, needs that sort of intensity.
"We don't think, 'We need to have an API,'" said Sebastian. "We think, 'We need to have a great API that developers are going to love using."
Lesson 3: Iterate Often, but Carefully and Respectfully
APIs present a tricky design problem. The must be great and they must be stable. Heroku, like most modern technology companies, is a strong advocate of agile, iterative development. You must test the API in the real world with customers to find out if it works and has a great design. But on the other hand, with an API, that agile cycle cannot take place in public after launch. Once an API is launched developers expect it to be stable. Lots of changes are just going to create anger and reduce adoption.
Heroku has resolved the tension between agility and stability by using a development cycle for APIs that has the following stages:
- Internal only: All APIs at Heroku are first released for internal use only. During this phase the experts inside the company use the API and identify flaws and opportunities for improvement.
- Extended Beta: Once the API has passed through internal use, it is then subject to a rigorous and extended round of testing that involved three stages: alpha, private beta, and public beta.
So by the time an API is launched, Heroku can be confident that the APIs are quite strong and won't need to be revised to address large problems.
"Once an API is launched, you don't have permission to be constantly changing that API," said Sebastian. "People are going to be relying on it. They are going to be investing time in using that API."
These lessons from Heroku's experience will help both beginners and advanced practitioners avoid serious mistakes. If you have more lessons or stories you would like to share about API strategy or questions you would like answered please drop me a line at dwoods@CITOResearch.com.