The last few weeks have hosted two key APIDays conferences: One was in partnership with API Strategy & Practice in Berlin, and last week APIDays Mediterranea was held for the second time in Barcelona, Spain. Conferences like these stimulate a lot of thinking about how best to implement APIs technically, how APIs are being considered in a business context and how APIs will shape the future of digital. Like APIcon in the U.K. and San Francisco last year, APIDays refrains from allowing product pitches in presentations, instead encouraging speakers to contribute to key themes experienced across the API economic landscape.
Here’s a summary of some of the chatter we heard in feedback sessions, over lunches and after official proceedings were over.
1. Hypermedia APIs Could Be Reaching Their Heyday
At APIDays Berlin, many hypermedia stalwarts in the audience eagerly appreciated Sébastien Cevey’s opening keynote covering hypermedia:
— Apiwise (@apiwise) April 24, 2015
A well-attended breakout session on hypermedia was also held in Berlin, with Pieter Colpaert talking about a model for using JSON-LD hypermedia links to enable transport route planning at scale. Colpaert proposes a solution where data could be published in data fragments using JSON-LD vocabulary to allow a route-planning agent to piece together the data needed from multiple sources.
Meanwhile, API evangelist Kin Lane was overheard saying that as a researcher in the API space, at times he has to make hard decisions about what parts of the landscape he tracks as a core subject. In the past, hypermedia APIs fell into one of those categories of the API space that lay beyond his remit. Lane was heard saying that hypermedia has become one of the core subjects he is regularly tracking.
Then in Barcelona, Steve Klabnik held the audience in the palm of his hand as he fulfilled a residency requirement of living in Brooklyn, New York, by presenting his whole keynote using only a Moleskine notebook and a quick show-and-tell of his Ruby homage tattoo. Klabnik presented his work on the open source JSON API specification that he has been working on with other primary editors Yehuda Katz, Dan Gebhardt and Tyler Kellen. The specification was built in the open via issues submitted on GitHub.
Klabnik said version 1.0 of the specification will be launched on May 21. It is reminiscent of the JSON-LD specification, but, according to Klabnik, instead of “trying to reinvent the Semantic Web without the bad part of the Semantic Web,” JSON API allows for the definition of objects on the server so that clients can do CRUD operations on them. A longtime hypermedia evangelist, Klabnik reassured the audience that the specification “encourages but does not require use of hypermedia APIs.”
With the hype about hypermedia growing, perhaps Gareth Jones from Microsoft’s OneNote API summed it up best:
2. Techniques for Building Cross-Business Support
Speaking of Jones, he was heard sharing some ideas on how to encourage an API strategy across a business’ operations following one conference session.
“Find an edge piece that has an independent data store and look at how you could build a microservice architecture around that,” Jones suggested to those looking for a way to demonstrate the value of APIs in a practical project in the enterprise.
How to sell the advantages and benefits of APIs within a business was still very much on many participants' minds at both events. It seemed as though at this year’s conferences, the decision to go with APIs in a business or enterprise had more often been made, whereas in previous years, participants were attending in order to build the business case for an API strategy. However, many developers and solution architects attending both events still faced internal barriers and resistance toward getting APIs implemented across business departments and grappled with demonstrating the value of a composable, microservices approach, hence Jones’ advice to choose a project that could demonstrate the benefits without requiring months of reorienting existing legacy systems.
Akana VP Michael Goerlich’s comments around knowing “who is looking at the API metrics and from what angle” resonated in lunchtime discussions. Several participants thought they could push their API strategy a bit more by acknowledging the business metric of “how fast can IT do something for the business?” But again, this can present more internal political struggles: As many lamented, time to market goes down with APIs, so the biggest beneficiary will be IT because it can do its work faster. But traditional IT decision-makers can also have the largest pushback for an API strategy internally.
In Barcelona, Manfred Bortenschlager from 3scale presented an API-focused business model canvas and suggested that if API strategists mapped out their business APIs using the model, the canvas could then be used as a "talking points cheat sheet" when aligning the value of an API strategy with other business concerns across an enterprise.
3. Sam Newman Could Have Sold a Lot of Books Here
There should be an API bingo game at some of these events: If you'd had both “legacy systems” and “monolith” on your word card, you would have been shouting "Bingo!" at every tea break. Also: microservices. For some, after selling the API advantage internally, the next obstacle was exactly how to get started breaking down a monolithic, legacy system into a series of composable API services and data stores.
Whereas the "composable enterprise" was the key descriptor for a business’ API architecture last year, this year's term to describe almost exactly the same thing was "microservices": the idea of breaking down business functions into their smallest unit and packaging them up via API so they can be chained (or webbed) together independently, with no one service causing a single point of failure. Almost everyone who spoke of microservices had read Martin Fowler’s seminal articles, so the crowd would have been primed to then purchase Sam Newman’s deep dive “Building Microservices.” Honestly, he should have had a little card table in the corner and a stack of books to sign.
4. 'Exceptional Experience'
Google Cloud Platform developer advocate Mandy Waite’s presentation in Berlin stirred up many discussions and was quoted in several other presentations. Waite is part of a team that is building client libraries idiomatically. While the client library is auto-generated from the API documentation, it is then hand coded to match the sorts of idiosyncrasies that developers come to expect with their favorite language or framework. Waite says this is all about providing developers with “an exceptional experience rather than acceptable experience.”
Many participants at both events echoed the importance of client libraries as central to providing a welcoming developer experience.
Speaking of Waite's being quoted in other presentations, we would have loved to have seen someone else do the trick Tony Blank from Context.IO used to add quasi-real-time content to his presentation. In the presentation before Blank’s talk at API Days Barcelona, Andy Thurai from IBM offhandedly mentioned the powerhouse of data that lies inside emails. When Blank took the stage and began talking about automating email and the rich data available in a business’ emails, he included a slide with a photo of Thurai from 10 minutes earlier when he had made the comment, and was able to start his presentation by saying, “As we have heard from Andy…” Segue accomplished with class!
5. Everyone Wants to Play With the Chaos Monkey
For API leaders who have been part of introducing a microservices architecture into their enterprise, and startups that have built a distributed application infrastructure from the ground up, the next must-have cool tech is definitely a Chaos Monkey.
This is a continuous improvement type of approach designed to help dev teams always be prepared for unexpected failures in their systems.
The term comes from the Simian Army at Netflix, which describes the Chaos Monkey as “a resiliency tool that helps ensure that your applications can tolerate random instance failures.”
The idea is not new — Adam DuVander mentioned it on ProgrammableWeb back in November 2012 — but as more businesses are now implementing a distributed application architecture approach where APIs do a lot of the integration work, they are finding that when things fall over, massive failure is costly and leaves dev teams scrambling. The idea is that by inserting a Chaos Monkey into an architecture environment, something random will go wrong eventually (albeit within standard business hours), requiring dev teams to be agile and solution-focused, while avoiding a reliance on any system long term, which was part of the problem that created the legacy systems culture in the first place and has been so difficult to dismantle.
Conversations Moving the API Economy Forward
What was most fascinating about all of the conversations overheard at both conferences — and something noticeable at last year’s APIcon events as well — was the culture of a sharing economy among participants and speakers.
The general idea of discussing with other participants, it seems, is to grow off their experiences, to create in the open wherever possible, and to share data and insights on what is going wrong and where the obstacles are being faced. API conferences are an important platform to encourage that sharing and discussion in a way that passes the "Monday morning test." That is, after the conference is over and everyone has returned home, can you apply what you learned in your work on the next Monday morning? The answer from those at APIDays is a definite yes, even if that means recruiting a monkey to help you out.