Voltaire, Vonnegut, and the Vocabulary of Microservices

DZone 's Guide to

Voltaire, Vonnegut, and the Vocabulary of Microservices

Read on to see how Vonnegut's ''Cat's Cradle'' can help us understand microservice architecture and its vocabulary.

· Microservices Zone ·
Free Resource

I took my son to the library the other day to get some books to read over summer break. While there, I stumbled across a copy of Voltaire's Candide, a book I'd heard of often but never read. What a crazy book! I found it fascinating to read such biting satire from the 18th century. And since I have been obsessing about microservice architecture for the last four years, two other things struck me. First, the book's concluding message that "we must cultivate our gardens" reminded me of Erik Wilde's "service landscaping" concept. Secondly, I am convinced that Candide must have had a big influence on my favorite author, Kurt Vonnegut. But what does Vonnegut have to do with microservice architecture?

Kurt Vonnegut's 1963 novel, Cat's Cradle, tells the story of the world ending from irresponsible scientific progress, an allegory for the nuclear proliferation threatening the globe at that time. In it, Vonnegut creates a fictional but surprisingly fleshed-out religion called Bokononism that is essentially a collection of untrue but useful proverbs. Bokononism also has its own vocabulary, and a few of its concepts have stuck with me since I first read the book as a teenager:

  • Karass — A group of people linked in a cosmically significant manner, even when superficial links are not evident.
  • Wampeter — The central theme or purpose of a karass.
  • Granfalloon — A false karass; a group of people who imagine they have a connection that does not really exist.

I have no idea why Vonnegut picked these words, but they're certainly memorable. And in the tech world, we know the importance of memorable words and acronyms. I've seen a few examples of the catchiness of a company's name being the difference between a startup failing and succeeding. But what about the concepts themselves? One of the most important aspects of succeeding with microservices is defining the boundaries between the services themselves, which in turn define the boundaries of the teams supporting them. This is also one of the trickiest parts of microservice architecture. In working with companies who are moving to a microservice architecture, I've seen a rapid progression of technological hot topics, but the non-technical challenges-like defining service boundaries-remain the same. Maybe what's missing are some memorable words, concepts, and proverbs to help microservice adopters overcome these hurdles.

To define service boundaries, perhaps we could seek out service karasses. First, we could start by finding the right wampeter for our service karass. A popular wampeter would be business domain alignment. And we would have to watch out for service granfalloons, which would lead to sub-optimal boundaries. Trying to group by entities or horizontal functions could certainly lead to service granfalloons. Or maybe we should leave Vonnegut's terms and concepts to Bokononism. Still, come up with a vocabulary for microservice architecture is a useful endeavor.

Through the publication of Microservice Architecture in 2016, my O'Reilly course on "Microservices for the Enterprise" in early 2017, and Securing Microservice APIs earlier this year, I've been interested in helping to standardize the language of microservice architecture and distributed systems in general. Software engineering is the most rapidly evolving industry in the world, but the lack of collective agreement on shared terms and axioms is holding the industry back from maturing even more quickly. The same competitive spirit that drives the industry's progress contributes to this divide, and many basic lessons are repackaged and relearned over and over again. We see this all the time, from the recent "service mesh" trend purporting to be something new (when it's really a clear evolution of distributed systems communication patterns) to GraphQL proponents claiming superiority over RESTful APIs (when they don't even know what REST is). I hope that putting the focus on concepts and capabilities instead of vendors and products can help to move the industry in the right direction.

In a previous blog post, I outlined the terms and concepts we used in Securing Microservice APIs. From the DHARMA model, you can see how the "domain" concept mimics the "service karass" above, and the "domain relation" is its "wampeter." Brendan Burns' recent book, Designing Distributed Systems, also takes this "concept-first" approach and builds on timeworn software architectural principles. Next month, I will be hosting the Microservices Conference at API World. My opening talk will explore this thinking in more depth. I'm aiming to cut through the hype of recent trends like microservices, service mesh, and even APIs to trace the evolutionary path of distributed software engineering. Establishing a common vocabulary for that wide field is definitely an ambitious goal, but also a very necessary one if we want to stop reinventing our digital wheels and tackle the big, unsolved problems facing our industry.

And so it goes...

distributed systems, enterprise, microservices, software architecture

Published at DZone with permission of Matt McLarty , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}