Net API Notes for 2020-03-17 - Issue 124

If open rates are anything to go by, people are preoccupied at the moment. I don't blame them. However, if you're interested in a bit of distraction while studying the nuances of distributed systems, I've got another collection of notes for you!



Erik Wilde is resurrecting the MTV VeeJay role for an age of APIs. If that wasn't enough, he continues to write about APIs on a number of sites. A recent piece, "The Fallacy of the Factory caught my attention. I had presented on the dangers of Feature Factories last year. It reads as if Erik has had similar experiences.

When in an API, modernization, microservice, or digital-transformation effort, there may be strong incentives to "churn out some APIs". This is an attempt to demonstrate, quantifiably, that a big bet has taken hold.

However, the design (and, thus, the longevity and ROI) on such APIs are about what you would think. Erik encourages thinking less about assembly lines and more about workshops. Maybe it's my farm roots showing, but I'd go further. Leaders who are in a position to influence programs need to think less in manufacturing terms and more in terms of gardening. It is more important to create the conditions for good design to continually evolve and change (water, fertilizing, weeding out bad actors) than fabricating a precise, static result.


Tim Anderson, writing for the Register, covered a presentation from Monzo's Matt Heath and Suhail Patel. In it, they cover the 1600 microservices that Monzo uses to operate their business. If Monzo sounds familiar, I covered the architectural kerfuffle they caused on social media late last year. At the time, their graph of 1500 microservices caused both hand-wringing and fist-pumping, depending on which side of the microservice-trough-of-disillusionment you are on.

In my experience, complexity is rarely eliminated. What happens much more frequently, however, is that it is renamed and made someone else's problem. Yes, Monzo may have simplified things for its developers, paving the way for 1600 microservices. However, blink, and you might miss the mention of *the dedicated ops team stood up to manage all those Kubernetes environments.

Devops was supposed to tear down the problematic practice of standalone development and operations teams. However, "modern" deployment pipelines and production environments have grown to such complexity that everything old is new again; we now have dedicated operations teams.

There's no perfect architecture or software development model. When you see success stories like this in the wild, it is vital to question it critically. Is success the result of something new and/or novel? Or are the wins claimed at the expense of other, and just-as-important, principles?


But we're not done with microservices yet! Amit Gud has a fascinating discussion of how Uber uses multi-tenancy in its microservice architecture.

While you might come for the multi-tenancy, you should stay for the discussion on microservice testing. As I mentioned above, microservices solve a particular class of problems while introducing others; testing being a big one. Amit contrasts "parallel testing" verses "testing in production". He then ties it back to how multi-tenancy allows for multiple versions to "test in production" to work.



There have been several cancellations, like Berlin's 2020 microxchng conference, that I've tracked on I've also noted which events have gone 'virtual'.

Things aren't going to be normal for a while, neither for nor all of us, collectively. Society didn't just flip a switch, and we do what we did, but from our homes. It is OK if you are not as productive as you have been. Tend to your family, friends, and neighbors. Do what you can, but remember to take time for yourself. Take a moment to breathe; be slow to anger, quick to laugh. These are interesting times and we get to the other side of this together.

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.