Net API Notes for 2020/04/14 - Issue 127 - Uber's 'Macroservice' Move
Well, well, well. Uber mentions they're abandoning microservices in favor of "macroservices". As you might expect, the internet has thoughts.
NOTES
As I wrote about during Monzo's microservice kerfuffle, microservices have become a Rorschach test for people's architectural faith. Ardent devotees continue to iterate practices and toolchains. Microservice agnostics contemptuously wag their fingers at imagined benefits and increased operational complexity. Now Uber's newfound belief in 'macroservices' seems to have offended both camps.
David Heinemeier Hansson, or "DHH", is always outspoken. You might remember him as "that Ruby-on-Rails guy", the co-author of numerous software development books, or co-founder of Basecamp. DHH is also a blogger on SignalvNoise, where he posted, "The Majestic Monolith can become The Citadel".
In the piece, David argues that:
"The vast majority of web applications should start life as a Majestic Monolith: A single codebase that does everything the application needs to do. This is in contrast to a constellation of services, whether micro or macro, that tries to carve up the application into little islands each doing a piece of the overall work."
DHH uses a citadel-and-outpost metaphor as a heuristic for deciding when to split things out into their own codebases. It makes sense abstractly. However, I think it lacks prescriptive guidance when the context is muddier. Further, shaming microservice adopters as "people fantasizing 'about being capital-a Architects'" is harsh (albeit on brand).
Vaughn Veronon, noted domain-driven design author and consultant, also chimed in with his piece, "Microservices and [Micro]services".
Vaughn, correctly, identifies that part of the problem is the number of thought leaders who wrestle for control of definitions. Each purported answer plays to their various strengths. The result are characterizations spinning further and further afield, rather than coalescing around a single truth. Vaughn encourages people, first and foremost, to think critically about how one person is defining the term, and to ensure that they compare and contrast with what others say. (If you're a subscriber to these notes, congrats! You're already on your way!)
For those that need to be more tactical than the citadel-and-outpost metaphor, Vaughn doubles-down on identifying the bounded context within domain-driven designs (DDD). He emphasizes the importance of identifying the ubiquitous language. This isn't just for consistency in terms within a domain, but also as a signal for when a boundary has been crossed. Much more in his piece and I'd encourage folks to read it.
Vladik Khononov, in response to the Uber news, wrote "Untangling Microservices, or Balancing Complexity in Distributed Systems". He defines both monolith and microservice terms, before delving into a larger discussion of what companies are trying to achieve through their architectural practices; is it sets of services? Or systems?
Vladik goes on to argue that companies that optimize the services, while ignoring the system, result in complexity hell. He cites Glenford J. Myers, a computer scientist and author, to argue that global complexity (or the complexity of the system of a whole) suffers due to optimizations made to localized complexity, or the implementation of a service. This is the notorious "distributed big ball of mud" situation.
Vladik also provides a rule-of-thumb, but one borrowed from architect Randy Shoup:
"A service having more integration-related than business-related methods is a strong heuristic for a growing distributed big ball of mud!"
I'll end this section with a post by Christian Posta. He recently shared "Istio as an Example of When Not to Do Microservices". It describes the backtracking Istio did with its architecture.
"If you do go down the path of microservices, be honest with yourself and the organization when it is not working. Correcting course may be the right move for the success of your product."
Considering that Istio is a service mesh for microservice communication, the move to a more monolithic approach is, on the surface, surprising. However, this detailed piece helps explain why it makes more sense for a monolithic approach, even while enabling others' microservices.
MILESTONES
- Spotted by Bill Doerrfeld, the OpenAPI Bot tool allows a bot to answer questions about a net API. This could be used for some cool, self-service integrations.
- Apple and Google are going to release a set of APIs to enable governments and health authorities to do COVID-19 contact tracing. If this sounds like something that you'd be interested in looking into, check out the Bluetooth and cryptography specifications and framework documentation. Ben Adida, a board member with Creative Commons, thinks it looks solid. The Markup's Julia Angwin agrees the system is anonymous but worries it is vulnerable to trolls and spoofing.
- I covered a number of free online training resources in the last newsletter. To that list, I'd add Udi Dahan's 'Advanced Distributed Systems Design' course. The videos are now available online for free. After enrolling, you have access to 97 videos for the next 60 days, a purported $2500 value.
WRAPPING UP
I continue to keep NetAPI.events updated with as many postponements and virtual-event switcheroos as I can. If you have updates on upcoming API-related training, let me know! I'd be glad to share it with my audience.
Finally, thank you to the Patreons who support this work. Another week, another near-thousand-word mile-marker in this journey we call software development.
Till next time,
Matthew @libel_vox and matthewreinbold.com