Net API Notes for 2020/08/12 - Issue 138

Hello!

Is it August already? Really? Oh-boy.

I don't know who needs to hear it, but this piece on negative habits in the age of Covid-19, by Eric Barker spoke to me:

"-we are starting to acclimate, accepting it all as just another episode of the COVID-19 Variety Hour. Problem is, many of us are not acclimating in a good way. Our positive daily routines are screwed up and COVID is throwing Miracle-Gro on our bad habits. Doomscrolling online, endless TV binges, aimless web surfing or far, far worse things are replacing constructive activities that promote true joy and productivity."

I can't say that reading the article cured me from too much ice cream and bingeing all of Netflix's Warrior Nun in an embarrassingly short amount of time. However, being able to put my finger on just what was going on in my own life was a big first step. Perhaps it will be useful to you to.

Now, onto the links!

NOTES

SHOULDER SURFING SERVICE MESHES WITH TIM BRAY

Tim Bray is one of the co-authors of the original XML specification and, until recently, worked for Amazon Web Services. He recently published his reactions to a presentation on building a service mesh in the GCP environment.

Kelsey Hightower, presenting alongside Stewart Reichling, used Google Cloud's Traffic Director. Kelsey shared his reactions to Tim's reactions in a tweet thread. The original presentation is available on YouTube.

None of the aforementioned resources is a primer on service meshes. If you're looking for that, check out the list of resources in the notes from issue 115. I do want to emphasize how appreciative I am of this kind of civil, public conversation. I feel as though I learn more. Just watching the video versus watching the video with expert commentary is the difference between walking around an unfamiliar city and being lead by a passionate, experienced local guide. Both folks end up enriching the experience with detail I would have otherwise missed.

DESIGNING FOR SPEED AND OBSERVABILITY

On InfoQ, Daniel Bryant has an interview with Mike Amundsen on the importance of designing for speed and observability. The conversation starts with several factoids from a recent IDC Digital Transformation Report. As subscribers to this newsletter might expect, API forecasts are up and to the right.

Because of this, Mike outlined new imperatives for scaling API performance: architecting, monitoring, and managing. If you are in the midst of a digital transformational and moving services to the cloud, I'd recommend checking this one out.

MICROSERVICES AND MANAGING NETWORK REQUESTS

Stop me if you've heard this one:

"When a single visitor accessed the website, it resulted in tens of thousands of HTTP requests in the back-end."

This isn't an architectural style. It is a cry for help. The article's author, Dennis Van Der Stelt, is stating the obvious when he says that this isn't desirable behavior. He then discusses different architectural lenses one could use to see both the logical and physical views.

While "seeing" sources of temporal coupling is good, it doesn't address the underlying problem: microservices remain an architectural Rorschach Test. Take the API statements in an otherwise positive discussion COVID19 work:

• "APIs are only useful if they can be discovered for re-use"
• "The real benefit of creating micro services ... is that they can be built faster and more re-usable."

I agree that reuse is nice. However, it shouldn't be the primary factor. An over-emphasis on "generic" services tends to lead to anemic design; kinda what most people but not doing a single thing well. APIs are an architectural pattern for abstracting technical complexity from integrations. The more you free API consumers from thinking about your interface, and the innards behind it, the more successful you will be. For more on microservice considerations, see my last set of notes.

A Tribble-esque explosion of requests, as mentioned at the top of this section, is an architectural smell. The boundaries, I suspect, fulfilled an artificial microservice definition rather than a practical, business-driven one. Trond Hjorteland illustrates this phenomenon in his piece, "Microservices Without DDD is Risky Business!":

"It gave many mixed feelings seeing that the core ideas of autonomy and business alignment seemed to have taken a back seat to the sizing of the services, in some to the extreme small end. For some it triggered bad memories of the extreme focus on reuse some had back in the day that led to a similar pattern: Nanoservices."

(For the record, nanoservices, and even more diminutive cousins, like picoservices, are not a thing. Anyone who tells you different is trying to sell you something. That stinks.)

It is a great post for folks seeking edification in their own process design.

MILESTONES

• Microsoft announces an SMI specification compliant, Kubernetes native implementation of a service mesh. Read more at OpenServiceMesh.io.
• API Days is recruiting a community manager.
• I'm not a proponent of code-first API development. However, I do acknowledge there are times when developers inherit a legacy system and need to document what exists fast. In that case, IBM now has an open-source OpenAPI Comment Parser. Yay.

WRAPPING UP

Tracking the world of events got more challenging after Covid-19. Things move around, and in-person went digital (or disappeared entirely). Just when I think things are settling into a predictable pattern, there's a new development.

Despite not being directly about APIs, I'm sure most people are familiar with WordPress. Well, they've gone and canceled all in-person flagship events until 2022. Yes, 2022. That's a long time. Interestingly, one of the reasons cited for the decision is "online event fatigue for attendees".

The WordPress folks do acknowledge that organizers for their flagship community events may attempt a virtual event during that time. However:

"As online events continue to evolve to reflect community needs, the Community Team strongly encourages these flagship organizing teams to be creative in their approach," Hugh Lashbrooke said in the announcement. This challenge forces organizers to proceed only if they can knock it out of the park in terms of creativity. Otherwise, it’s simply hosting another online conference in the same tired format for the sake of tradition."

Wow. The sentiment is warranted. I'm already seeing a race-to-the-bottom as online events become an undifferentiated good. People need to think about the online conference space differently. (The recent ALife 2020 is an attempt to watch.)

I anticipate these aren't the only folks thinking along these lines. If and when I see things begin to break this way in the API space, I'll be sure to update netapi.events.

I'll end, as I always do, with thank you to the Patreons who support this newsletter.

Till next time,

Matthew @libel_vox and matthewreinbold.com