Net API Notes for 2020/05/08 - Issue 129 - Tetrads

Have you ever seen it rain inside a fireplace? Because the universe decided these times weren't weird enough, I've had to scramble for some unexpected home repairs. While I need to deal with that, here's the latest batch of Net API Notes!

NOTES

HOW DO YOU MEASURE API SUCCESS? WITH API METRICS

When determining the success of an API effort, there are numerous levels of scale to consider. The metrics one would apply at the team level for an individual API are different than the way the C-suite would track a digital transformation effort.

Jana Frejova, writing on APIFriends, shares several possible ways to measure success. Much of it is introductory material. However, what I appreciated was Jana's inclusion of what to watch out for. Metrics are a powerful tool. Proceed with caution.

If this is a topic area of interest, a couple of additional posts worth mentioning are Mark Boyd's 2017 piece, "Five Metrics Every API Strategy Should Measure". And I'd be remiss to mention API metrics without a shoutout to the father of all API metric conversations, John Musser's 2014 deck, "KPIs for APIs".

NET API STANDARD EVOLUTION

Web standards, like sheltering-in-place, may seem to have been around forever. However, each of the bricks comprising our modern application facade came from somewhere, somewhen. And many may be newer than you initially thought.

Kin Lane, the API Evangelist, was recently digging into history. Many of the responses are thought-provoking. However, the graph provided by Luis Augusto Weir, chronicling his research, is excellent.

Taken on their own, each of these data points is an interesting factoid on the way to the most inaccessible game of Trivial Pursuit, ev-ar. Together, however, they tell a story of an industry constantly evolving. Knowing the history also lends to put today's burning hyperbole in an appropriate context, which leads us to:

A MEDIA-THEORY APPROACH TO MAKING SENSE OF CURRENT API TRENDS

In a previous issue, I listed many individuals debating the appropriateness of microservices as an architectural pattern (TL:DR; yes, they're useful in the right circumstances, but not a silver bullet, and there is a lot of half-cocked cowboy architecture firing off).

Critical thinking models help us question our assumptions. They also illustrate new insights we may not, otherwise, considered. There are a variety of models. I frequently mention, for example, the Gartner Hype-cycle.

Marshall McLuhan, a philosopher and media theorist, developed a different model. His Laws of Media described a tetrad of effects that any technology, or medium, has on society. Any successful technology, simultaneously:

1. Extends a human property
2. Obsolesces the previous tech and may turn it into a luxury, sport, or form of art
3. Echoes, or retrieves, a much older tech that was obsolesced before
4. Flips or reverses its properties into the opposite effect when pushed to its limits

How does this work in practice? Microservices has been around long enough that, I feel like we should have a good grasp of the broad pros and cons, even if we may disagree on low-level nuance. Let's look at its tetrad:

Starting in the upper left and going around counter-clockwise:

• Microservices enhance code simplicity, enable independent deployment, allow for polyglotism, etc.
• In the process of doing microservices, we call back to previous software efforts that attempted to reduce complexity by creating smaller units, whether that is Eric Evan's domain-driven design (DDD) in 2003, or the object-orientated module work in the mid-90s. Of course, we also call back to the organizational effects on this architecture, which Conway was talking about in 1967.
• Microservices are meant to obsolete monolithic codebases; the deployment independence means that the quarterly (or even yearly) packaged software releases are a thing of the past, or a novelty marketing event.
• Taken to the extreme, however, the code complexity moved out of individual microservices begins to manifest in deployment and test complexity. The more services made, the more significant this impact.

There's more to it. Perhaps you would rephrase or have different points. That's OK; the point of these kinds of models is to generate a conversation. Connections are made that might, otherwise, be missed.

Let's do a couple of more recent API developments: service meshes and event-driven services.

Service meshes are a software abstraction layer that enables standardized registration, discovery, and communication between services.

Service meshes:

• Enhance standardization of things like logging, monitoring, and communication across many services, freeing developers from recreating non-differentiated code.
• Retrieve features that previously were performed by dedicated infrastructure (network firewalls and load balances) and recreates them in code.
• Further obsoletes the network admin; with Devops, this is an example of moving additional responsibilities to developer management via code.
• Taken to the extreme, the benefits reverse; the sidecars add additional compute and management overhead. Further, extending to handling traffic from the wider world (ingress) isn't a straightforward proposition.

Event-driven services:

• Enhance real-time experiences
• Retrieves concepts from past distributed systems, like queuing systems that may employ transactions and sagas, or even patterns from enterprise service buses (ESB)
• Obsolete polling architectures
• Like elsewhere, when taken to extremes, event-driven services result in additional complexity.

The event-driven (micro)services graph is the least populated, on purpose. What items are missing? And what other technologies (and their impacts) should we analyze?

MILESTONES

The first milestone is a regrettable one. Jan Stenberg, a Senior IT Architect and frequent contributor to InfoQ, has died from Covid-19 related illness. Jan frequently wrote about API-related issues. I even covered his work in this newsletter on multiple occasions (1, 2). According to those closer to Jan, he contracted the virus while attending a QCon conference in London, the subject of his final tweet.

He will be missed.

Other milestones:

• In March, the Center for Financial Inclusion released the "API Deployments in Inclusive Finance" report. The report says, in part, "The experiences of fintechs that used bank APIs have not been ideal, with significant upfront costs to complete basic tasks like understand API documentation or establish secure connections". Ouch.
• Sam Newman has a new video on his YouTube channel. The latest bite-sized entry is entitled, "How Big Should Microservices Be?". Have you been following the Rate My Room Twitter Account? After careful study, Sam's videos have the "hostage video made by flamboyant captors" vibe. Content is top-shelf, however.

WRAPPING UP

"Help the helpers" is something I've been trying to live by, especially in these times. Last issue I mentioned several organizations that are doing good in the world, including Binc's assistance to booksellers and comic retailers. Along similar lines, I recently gave Bookshop.org a try. Bookshop is a B-Corp, or corporation dedicated to the public good that supports local bookstores. You can either choose a local shop that will receive the full profit from an order. Or the profits will go into an earning pool is evenly distributed among independent bookstores.

Amazon is great for many things. However, when we're able to gather again, I'd like to think that there will still be local bookstores around. A good bookstore acts as an anchor for our communities. If you, like me, are filling your time with new and interesting books, consider giving Bookshop.org a look.

Have you been to NetAPI.events yet? It includes numerous rescheduled conferences and virtual-events. If you have updates on upcoming API-related community gathering, let me know! I'd be glad to share it in an upcoming letter.

Till next time,

Matthew @libel_vox and matthewreinbold.com