By Matthew Reinbold in Newsletter — May 16, 2019

Net API Notes for 2019/05/17 - Google, Nest, and API Platform Management

This week I was pleasantly engaged in hashtag camping both the Nordic Austin API Summit and the Web Conference (formerly WWW) out of San Francisco. I'll have cherry-picked the most interesting bits from both of those events for next week's newsletter. This week, however, we need to talk about what happened at the past Google I/O, as it is relevant for API platform practitioners.

The Verge proclaimed "Google's Nest changes risk making the smart home a little dumber". Ron Amadeo, writing on Arstechnica, said "Nest, the company, died at Google I/O 2019". What both pieces are referring to, in part, is the discontinuation of the "Works with Nest" program at the end of August. The APIs at the heart of that program is what provides Nest devices with interoperability with other services and devices.

As so often the case, the reality behind the sensational headlines is both more nuanced and less damning than one might assume.

Under the previous access paradigm, other services and devices could call APIs directly on the devices themselves. Google cited privacy concerns in this model; there were no controls on how these other companies were using the data. In the future, Google intends to give "a small number of thoroughly vetted partners access to additional data". Who those partners are, what they'll have access to, or what the vetting process will be is unknown at this time.

While all that makes sense, it is disruptive for a cottage industry built upon the current ecosystem. Come August, thousands of products and services, like IFTTT, will stop working with Nest devices. When that functionality will be restored, if at all is unknown. And while popular integrations from well-funded, well-staffed companies will most likely make necessary accommodations, the long tail of esoteric actions and experimentation are unlikely to be replicated. From the Verge piece:

"Tinkerers have used Nest’s relatively open APIs to build all sorts of things that weren’t officially supported by device manufacturers. An example of this is Samsung’s SmartThings, where the company never officially supported Nest’s thermostat or other devices on its platform. But the community of home-brew developers built unofficial integrations that allowed SmartThings customers to access data from their Nest thermostats and use it to control other devices that SmartThings does support. It’s safe to say that those types of integrations will no longer work at all once Works with Nest shuts down."

A bit later:

"Direct control is being traded for google assistant-mediated access."

Running a successful API platform, resulting in flourishing ecosystems, is hard. I am smitten with Amrit Tiwana's "Platform Ecosystems: Aligning Architecture, Governance, and Strategy" (it's OK, that's not an Amazon affiliate link). In the book, Amrit talks about how all successful platforms need to balance developer autonomy with integration ability (which denotes a degree of conformity and consistency with what has come before).

In this case, it appears that Google is dialing back the autonomy and regaining a degree of data control. Whether that truly means the death of an entire ecosystem, or a die-off of undesirable weeds, will be interesting to see played out.

Now to this week's notes.

NOTES

DESIGNERS AND PRODUCT MANAGER'S ROLE WITH APIS

Caroline Hane-Weijman, David Edwards and Francisco Hui make a compelling case for product management and design skills when building APIs in their piece "Principles of Designing and Developing an API Product". Assuming design and product management isn't necessary if something doesn't have a UI is a mistake, but one that I see all too many people make. Highly recommended.

LINKS, NOT KEYS

Martin Nally, writing on the Google Cloud blog, has a thought-provoking piece about why a developer should use links, not keys to represent relationships. He does a great job introducing the problem. For example, Martin relates exposing ids through an interface design to exposing a foreign key database relationship.

"Web APIs that pass out database keys rather than links are harder to learn and harder to use for clients. They also couple clients and servers more tightly together by requiring more shared knowledge and so they require more documentation to be written and read."

Hypermedia discussions sometimes start with autonomous agents proclamations and end with versionless schema theorizing. Perhaps approaching the discussion with a sanity check about systems coupling is a more palatable approach?

OPEN SOURCE BENCHMARK FOR MEASURING MICROSERVICE "DEATHSTARS"

The final note is a hefty one and comes from Adrian Colyers excellence computer science paper recaps. In a recent post, Adrian cites a paper (with 24 authors!) proposing "An open-source benchmark suite for microservices and their hardware-software implications for cloud and edge systems".

This is rigorous academic research into the behavior of complex microservice systems. As such, the actual text can be quite dense. However, the key takeaway, as Adrian writes, is:

"that microservices systems can be especially latency sensitive, and that hotspots can propagate through a microservices architecture in interesting ways."

Specifically:

Microservice architectures put more pressure on performance predictability
Microservices spend much more time sending and processing network requests over RPCs or other REST APIs (compared with monoliths, unsurprisingly; however, this becomes becoming pronounced under high loads)
Because of the pressure on the network processing, network acceleration becomes an avenue of acceleration
This acceleration could be aided by Configurable Cloud architecture, placing a layer of reconfigurable logic (FPGAs) between the network switches and the servers

When we talk about microservices, it is important to remember, as the paper points out, that we trade off code complexity for a new kind of emergent system complexity. Sometimes, like in the cases of development team autonomy and scaling, this makes sense. However, if that is the choice, the paper illustrates how microservices introduce back-pressure effects, leading to propagation of cascading QoS violations. This unpredictable system performance needs to be addressed in other ways.

All of the applications from DeathStarBench are made available under a GPL license. The "so what?" of that is explained by a follow up post Adrian provided later in the week. Based on DeathStarBench data, the Seer system:

"observes the behaviour of cloud applications (using the DeathStarBench microservices for the evaluation) and predicts when QoS violations may be about to occur. By cooperating with a cluster manager it can then take proactive steps to avoid a QoS violation occurring in practice."

MILESTONES

Google has published the guidelines they use for internal API review. (The 'AIP' in the link refers to "API Improvement Proposals".) Great to see a reference example for how others can do their API reviews.
Interesting post on the Twitter developer blog entitled "Building the Next Generation of Twitter API". Considering the track record of spurned partners, "renew our investment in our entire developer platform" raises an eyebrow. The first step seems to be opening up access for academics and researchers, a welcome step considering my recent discussion on 'the Post-API era of Academic Research'.
I missed it when it was announced, but Swaggerhub has a new visual editor. If we're going to treat APIs as a product, then product managers need to have the ability to contribute to the API definition. Hand-rolling YAML or JSON in an editor window was a barrier to that. Moving to a more visual, wizard-like format grows the number of potential contributors.
Smartcar accuses Otonomo of API documentation theft. It is one thing to offer an API similar in function to another for easier customer adoption. But when the same token UUID appears in both spots? That's a bit shady.

WRAPPING UP

Bill Doerrfeld recently interviewed me for a piece entitled "The Platform Economy: Why APIs And Integrations Are Crucial". That has now been posted over at the Adobe CMO blog.

There are new items cataloged on Netapi.events. I've added many new meetups, in addition to the fall API the Docs conference, in Amsterdam. Got something that isn't mentioned? Shoot me an email; I'd be happy to add to it.

Finally, thank you to my Patreon sponsors.

Till next time,

Matthew @libel_vox and matthewreinbold.com