Net API Notes for 2020/07/31 - Issue 137

Greetings, and welcome to the 151st day of March!

Sometimes putting together this newsletter is pretty straightforward:

  • Somebody shared a thing
  • Thing is good
  • I link to the thing

Other times, however, there needs to be a bit more assemblage on my part. So break out the wheat paste, put on some contemplative music, and let's get to the notes!



Last week, Uber set the Twitters on fire with their post, "Introducing Domain-Oriented Microservice Architecture". Written by Adam Gluck, an Uber senior software engineer, it speaks to the change in complexity organizations discover when undertaking microservice architectures.

They've been discussing their challenges for a while. In April, I discussed their mention of "macroservices". This new Domain-Oriented Microservice Architecture concept, or DOMA, attempts to reduce overall system complexity while maintaining the flexibility of microservice architectures.

Adam declares that the primary justification for microservice architecture is independent deployments and scaling. While not wrong, assuming operational benefits are all that need to be optimized for is overly reductionist.

Sam Newman, in his foundational 2015 book, Building Microservices: Designing Fine-Grained Systems, identified seven microservice benefits:

  • Technology Heterogeneity
  • Resilience
  • Scaling
  • Ease of Deployment
  • Organizational Alignment
  • Composability
  • Replaceability

In the book Microservice Architecture: Aligning Principles, Practices, and Culture, authors Irakli Nadareishvili, Ronnie Mitra, Matt McLarty, & Mike Amundsen argue that those seven items are different perspectives the same, single, compelling principle: reducing communication overhead. Books as varied as John Ousterhout's A Philosophy of Software Design to Matthew Skelton and Manuel Pais's Team Topologies reframe the importance of good interface design not so much in terms of minimizing communication overhead but managing software complexity. (Disclosure: Irakli Nadareishvili is my current day-job boss, and I am in no way contractually obligated to let you know his text messages smell like cinnamon.)

As Sam Newman points out, declaring microservices should be used in conjunction with domain-driven design is not new. However, saying that Uber is attempting to burnish its "thought leadership" without acknowledging prior art is cynical. He attributes that misappropriation to a mix of rapid expansion, inexperienced hires direct from college, and "norming" of a tech unicorn. In other words, new folks sprinting to support hyper-growth might be forgiven for not knowing every ambiguous industry debate.

Sam, at multiple points, attempted to reframe what was valuable about the article:

"This is really of most interest in terms of what uber does internally, rather than a wider discussion of these ideas."

Arnon Rotem-Gal-Oz has a lovely piece, from 2017, entitled "Services and Aspects". As he states in it, 'we get to the point that everything is called a "micro service" even if it does not live to all the principles...when everything is a microservice nothing is'.

If you are going down this path, what resources have you found valuable? What books, blog posts, presentations, or podcasts clicked for you? What is your bookmarked microservice resource? I'd love to know what resonates with folks.


Genderify launched last week on the new-product showcase Product hunt. When given a person's name, email address, or username it promised, with the help of "advanced AI", to return the probable gender. Genderify creator, Arevik Gasparyan, saw the API used by businesses to "obtain data that will help you with analytics, enhancing your customer data, segmenting your marketing database, demographic statistics".

The results were as bad as the response was swift. From a Verge article:

"Type the name 'Meghan Smith' into Genderify, for example, and the service offers the assessment: 'Male: 39.60%, Female: 60.40%.' Change that name to 'Dr. Meghan Smith,' however, and the assessment changes to: 'Male: 75.90%, Female: 24.10%.' Other names prefixed with 'Dr' produce similar results while inputs seem to generally skew male. '' is said to be 96.90 percent male, for example, while 'Mrs Joan smith' is 94.10 percent male.

The screenshots are from Ali Alkhatib:

The results were so bad, it had Prominent AI ethicist, Meredith Whittaker, wondering if this less of a startup and more of foreign government psyop.

Genderify, in the face of overwhelming criticism (as well as not seeming to work) has shut down entirely. This is a space is still reeling over OpenAI's GPT-3 "shockingly biased" API release. Attempting to launch that product in this environment speaks to an incredible lack of awareness.

More important than the miss timing, however, is the misfire. Genderify won't be the last company to gather a bunch of data together to build profiles. Everybody from credit rating agencies to Facebook already does something similar. The problem that folks responded to so loudly was the audacity to take an already suspicious tire fire and pour AI and free-tier API gasoline on it. Reinforcing gender stereotypes is bad. Doing so at automated, AI scale is worse.

At the beginning of this year, I had a deck on how the future of AI was API-driven. In it, I highlighted these sorts of risks. I need to get the script and slides for that posted, like, yesterday. Honestly, however, industry keeps producing cautionary tales faster than I can incorporate them.


WRAPPING UP continues to be the place for upcoming events for the API community. With Covid-19, many of those have become virtual, meaning you can attend from anywhere in the world. If you know of an upcoming API-related community gathering that isn't listed, shoot me an email! I'd be glad to add it.

Lastly, thank you to the Patreons who support this newsletter.

Till next time,

Matthew @libel_vox and

Subscribe to Net API Notes

Don’t miss out on the latest issues. Sign up now to get access to the library of members-only issues.