In a recent article on GigaOm, I talked about how the proliferation of APIs will empower developers to influence significant shifts within enterprise IT organizations. Aptly termed “composable” infrastructure by Jonathan Murray, EVP & Chief Technology Officer of Warner Music Group (@adamalthus), this new environment promises to rearrange not just architectures, but the entire power structures within enterprise IT organizations by pushing more power to developers at the point of prototyping. Not surprisingly, such an environment should stoke the furnace of innovation. More ideas can be tried, faster, and at very little cost beyond the cost of labor to bring them to life.
As we rush toward this brave new world of innovation, it's important to expect the inevitable implications and limitations of composable infrastructure. Not all APIs are made the same. Brian Proffit covered some of the biggest potential pitfalls of mis-managed APIs on ReadWrite. However, are there some key indicators of a well managed API, too. If you are considering integrating a new API into your development environment, here are some important features – a Bill of Rights, as it were – to look for:
An Open Roadmap. Restricting roadmap access and input to only the highest paying customers is a barrier that keeps most developers from making an informed choice about that service. An API's product vision should be shared to all users. The process by which features land in the production queue should be readily understandable. A service that plans to break backwards compatibility for a feature that a subset of users depend on should do so publicly, and as early as possible, so that those users can make the appropriate plans to modify or migrate.
Operational transparency. Everything is groovy until you find out your service provider stores all their data in a single instance of SQL Lite, running on a Lenovo laptop with weekly backups to a thumb drive. Composable service providers need to provide ample insight into how they operate the infrastructure housing your critical data and services. Providers may claim that all you need to worry about is that their API responds within an SLA, but if you can't get basic answers that satisfy your concerns or curiosity, trust your gut and use a different provider. Providers should make public operational metrics like historical uptime, disaster mitigation and recovery plans and provide at least some information on the architecture behind the service.
Performance data. While related to overall operational transparency, performance data doesn't necessarily apply to every system. When it does, a system that doesn't provide performance data and the details for how benchmarks can be reproduced should be approached with trepidation. While not a deal breaker for everything, it behooves you to have a firm understanding of the performance you can expect, and ensure that the service will willingly provide reproducible benchmarks.
Security – As Tim Prendergrast, CEO of security firm Evident.io recently told us, you should evaluate your service provider's security across two dimensions – proactive and reactive security. On the proactive side, the service provider should disclose how they secure their systems, at least enough so that you can get a sense of whether or not security is an afterthought or a focus. Have they shared the standards with which they comply? Do they have anyone focused on security? What security and privacy policies have they published?
On the reactive side, they should offer an easy way to report bugs. Do they run a bounty system that sends the message that they want help solving security problems? Do they promise to do post-mortems and inform you after an event? Have they ever failed to disclose a security breach?
Lock-in. If you are locked in, you are trading whatever convenience the service provides for future mobility, and hence freedom to pursue what is best for your project or business. Suffice to say, if the service fails any of the following criteria, you are in jeopardy of signing up to the infrastructure version of the Hotel California (you can check in any time you like, but you can never leave…):
You can cancel at any time. That is not to say that if you pay for a fixed term in return for a discount, you should be able to renege on that commitment, but there should always be an option that allows you to terminate service at will.
Your data is your data – you should be able to leave a service at any time and take all of the data you put into that service with you. Otherwise, it isn't your data.
Interoperability – even if you can get your data out, if you have nowhere else to put it, you are still locked in. Make sure you know when you are consuming features of a service that are proprietary.
Simple pricing – You can't understand what you're getting into if pricing requires an MBA and MatLab to comprehend. You should know that if you take action X, it will consume service Y, and that service will cost you $Z. Free tier? There is no free tier. Even the easiest to use infrastructure requires your time and effort to try it out.
A free (and easy) tier. Easy means two things – how long does it take to get started, and how easy is it to grok the service's utility and benefits? Are there clients for your preferred language? How long does it take you to open an account, read some basic documentation (yeah, right) and start curl'ing JSON objects into the API?
One architecture for all user levels – Free and low cost models that include a multi-tenant architecture at the low end of the consumption scale, and dedicated systems at the high end, are just masquerading as open and composable architectures. If you have to pay extra to TRULY experience the full benefits of a system (including paying to migrate your data between tiers), if it involves dedicated infrastructure, and if those benefits (a.k.a. attendant problems) come at a premium to the Free-n-Easy tier, you might find yourself with few of the benefits of a modular system, but a whole lot more expense. You should be able to experience the full scope of a service and only pay more if you use more of the service or desire professional services.
The list is certainly not exhaustive, but should serve as a good starting point for assessing API candidates for your project. They're rules we take to heart as an API provider, and attributes we expect from APIs that we use in our own applications.