Last week, for the first time I had the opportunity to attend the Glue conference in Broomfield, CO. An aptly named conference, Glue’s mission is to provide a technical forum for web application builders, architects, and integrators to talk about the various technologies that stick together to make a web platform and its associated applications. It’s one of the most exciting and nerdy places you can go, and it’s well worth the investment if you’re in this industry. Perhaps one of the most interesting aspects of this conference is the co-mingling of Big Enterprise and Scrappy Start-up. Big players like Netflix, Google, Intel, GM and HP were all there – but so were small companies like parse, Stormpath, keen.io, and the newly launched Runscope.
No matter which track you attended, the underlying message was pretty clear. As an industry and a society, our reliance on software and the underlying technology that powers it continues to grow. Adrian Cockcroft from Netflix set the standard by taking the stage with Google Glass and simultaneously delivering his keynote speech and recording it live with Glass. The cool factor was immense… that is, until we attempted to view it:
But that’s ok – the mere fact that he attempted it said something about what is coming and that the very nature of our interactions is changing through technology. By the time the conference ended, we had become accustomed to seeing folks walking around with Glass, connecting to the world in a whole new way. Which is, after all, what Glue is about.
This focus on innovation was no more evident than when Onstar’s Nick Pudar took the stage for his keynote about “Automotive Connectivity”. Listening to Nick’s talk about innovation and possibilities was not only enlightening, it was inspiring as well. It’s the first time I’ve ever wanted to work in the automotive industry. But more importantly, it drove home the underlying theme we heard as subtext over the two days – in this connected world, quality needs to take a front seat. Our reliance on the Internet of Things makes it imperative that all this ‘glue’ works. Onstar as an emergency service or maintenance notification system is only as good as the APIs it relies on performing those duties.
John Sheehan drove that concept home with his oft-quoted discussion about “broken APIs”. Sheehan’s keynote about how applications are distributed systems now that rely on both internal and third-party APIs to be functional resonated with many in the audience. Naturally, we all expected him to open his invitation-only Runscope to the public at this conference and he didn’t disappoint. Runscope’s focus is on monitoring and testing the APIs you rely on, and mitigating the pain of persistently broken APIs. It was obviously a concept we all could relate to and that phrase was quoted in more than one subsequent session.
Add to this John Musser’s always-engaging overview of the business of APIs, which has become a very big business indeed. Musser pointed out that Expedia made 2 billion dollars last year, with their primary business driver being their APIs. This gives even more importance to the concept of API quality. Unlike Sheehan’s direct appeal to individual developers, looking at the API industry through the lens of such enormous sums of money should give us all pause.
When you rely on your car to provide navigation assistance, emergency alerts and notifications, and vehicle information, you want the APIs to be rock-solid. When you are the developer building those systems, you want your application to be uncompromised by external code. This was the message underpinning many of the sessions at Glue this year – it was one of the reasons Sheehan struck a nerve with his “broken APIs” comment. In his talk about the “API-ification” of the web, Steven Willmott brought up the increasing focus on APIs and the need for APIs that work. Period. As we leverage each other’s APIs in our own application development, we are not only accessing data and functionality external to our own environment; we are basically tying together distributed systems across multiple cloud platforms and databases.
Now, more than ever there is a need for an increased scrutiny of our quality standards and service level agreements. The API industry seems to be reaching its adolescence after a tumultuous and exciting childhood. Alliances are forming, standards are emerging, and we’re starting to see the need for some kind of rules and governance so we don’t compromise the quality of our deliverables. Anybody who has managed a development team/project knows that it’s always difficult to find the time to test our own code – the increasing reliance on software that is built, hosted and maintained by others adds to the complexity of quality assurance across the board.
So what’s next? My gut tells me we are entering a new phase here – one with a greater emphasis on development and testing tools geared specifically for the API market. At some point, we have to calculate the differences between traditional software development and software development in an API-fueled universe. How do we provide tools that encourage experimentation and innovation while at the same time maintaining quality standards that are measurable and actionable? What do we owe each other from a service level standpoint? I can imagine that once we start answering these questions, we will also be entering into more traditional agreements with other, much like the partner and customer agreements we have been accustomed to in the past. And when we cross that threshold, we will need the tools and reporting to go along with it. We will have to know when our API has not met its defined SLA and what that means to our consumers. Likewise, we will need a way to monitor and troubleshoot the APIs we didn’t build but are relying on.
All in all, I think the mixture of concern and excitement in the API industry today will take the software world to some new creative places. I’m looking forward to the next part of this journey.