Net API Notes for 2022/06/07 - Issue 199

In this note, I've got several practical references on performing an inverse Conway maneuver within your organization. There's also a lovely piece on microservice problems in various formats. To the notes!

Net API Notes is a regular, hand-curated digest of impactful news and analysis for busy API practitioners. Are you reading this and not subscribed yet? Sign up today and be the first to get ad-free, actionable info delivered directly to your inbox.

INVERSE CONWAY'S MANEUVER: POSSIBLE? OR SIREN'S SONG?

STRAT / DESIGN / DOC / DEV & TEST / DEPLOY / SECURITY / MONITOR / DISCOVERY

The storytelling around Conway's Law has risen in conjunction with the popularity of microservices. Paraphrased, Conway's Law says that an organization's software will end up structured in such a way to resemble that organization's communication patterns. The corollary to this is that if you want to change the software you must also change the organization. To do so is to execute an Inverse Conway's Maneuver (ICM).

That may be simple in theory, but the reality is more complex. Over the past month, there have been a handful of inciteful articles from those who have attempted such maneuvers and lived to tell tales.

The first is from Mathias Verraes. He recently published a post entitled, "Conway's Law Doesn't Apply to Rigid Designs". Mathias defines a "rigid design" as the entire, overlapping interconnectedness between a software system and the other systems it interacts with: the cultural beliefs, the staffing, and even the work environment. It all adds up to something where a reorganization done with the best intentions is unsuccessful in creating the kind of software change needed.

I loved this thread by Flix Tech's Principal Engineer and Twitter user, @tPl0ch. Responding to Mathias's piece, he outlines specifics of what it takes to complete an Inverse Conway's Maneuver. That includes activities like:

• Strategic system boundary design
• Dissolution of existing team identities
• Boundary enforcement via tooling changes
• Process modification

I also appreciated the thread because @tPl0ch also talks about the pros and cons of accomplishing this boundary redefinition. For example, suppose you're decomposing monolith codebase. In that case, you might tell your new teams to "Copy & Change" to their heart's content - copy the existing monolith and cut away everything not related to their new ownership boundary.

However, that is not the only way. The strangler facade (or "strangler fig") is another way, something more accommodating to those larger, "rigid" systems that Mathias referred to (although, tbh, I prefer the term "Ship of Theseus" as opposed to "Strangler Facade"). In his final summary:

1. ICMs are extreme social interventions that need a lot of strategic planning and preparation, otherwise, you'll lose the support of the affected people.
2. The real work starts after the ICM with marking the new boundaries within the old system. Think of it as creating cut-marks, just like in a children's book.
3. Define the "flexibility" required for the new systems. Is it deployment independence or the ability to remodel?
4. Apply suitable patterns to overcome the "rigidity" within the existing systems. Applying some of these patterns will take quite some time to introduce, so make sure the expected returns justify the endeavor.

Finally, if you haven't had your fill of Conway organizational design, the Team Topologies blog recaps Docker's efforts to create more stream-aligned teams. (While they refer to a Reverse Conway Maneuver, it is the same as what I described above.

SEVEN WAYS TO FAIL WITH MICROSERVICES

STRAT / DESIGN / DOC / DEV & TEST / DEPLOY / SECURITY / MONITOR / DISCOVERY

One other piece that I wanted to highlight this week is an InfoQ conversation between podcast host Thomas Betts and Holly Cummings, a Senior Principal Software Engineer at Red Hat. Microservices, when done correctly, increase the autonomy among teams. However, there are several places where microservices can go wrong. In this interview, based on her Qcon talk from earlier this year, Holly correctly points out that:

• When implementing microservices the goal must be something other than "to have microservices" (or driven by "resume-driven development").
• Creating a distributed system does not automatically give you a decoupled system. Contract tests can help to identify and handle the coupling between two services.
• Large enterprises often have multiple layers in their software, such as presentation, services, integration, and databases. If your approach to microservices only addresses one layer, the others will remain bottlenecks.
• Real CI/CD is hard to achieve because it takes a significant investment in automation, and the benefits of the automation can be invisible when they work as intended.
• Adopting microservices, and a cloud-native approach, requires a holistic view of all the changes to be made. Having self-service, but locking it down with traditional governance, minimizes the benefits.

It's an informative recap of an enjoyable podcast based on an excellent talk. I highly recommend it.

MILESTONES

• There's now an AsyncAPI ruleset for Spectral linting.
• Erik Wilde recently updated the list of headers over at WebConcepts. If you were looking at how to leverage native protocol extensions to provide supplemental request context, you've got a wealth to choose from.

WRAPPING UP

The second part of my conversation with Kristof Van Tomme and Marc Burgauer has been published. If you missed the first part, that discussion of complexity, alignment, and the softer side of software is also available.

Stoplight also published a roundup of insights they've gathered from guests on their podcast and published a free "API roadmap" ebook. There's some good company there.

Speaking of Kristof and Marc, they're putting on a series of free online conversations regarding APIs and complexity. I'll even be speaking at the first session on June 15th. If you are interested in considering the entire API forest, not just an API tree, give the event details a look. And if you're in the hunt for a different API meetup or conference event, then NetAPINotes.events lists several more items.

Finally, thanks to this newsletter's Patrons. Their support keeps these email issues free of ads, paywalls, or information selling. Thank you!

Till next time,

Matthew @libel_vox and matthewreinbold.com

While I work at Concentrix Catalyst, a ray of sunshine emerging from behind a mostly-cloudy forecast, the opinions presented above are mine.