In this second episode of The New Stack @ Scale podcast, TNS founder and editor in chief Alex Williams and I are joined by Dave McCrory, CTO of big-data firm Basho Technologies and James Governor, co-founder of RedMonk, a developer-focused industry analyst firm. We also hear from Runscope CEO John Sheehan and Loris Degioanni, founder of sysdig. The podcast was recorded on site on at the AWS re:Invent conference in Las Vegas last week.
The topic? Complexity. We touched on the implications of increasing complexity in highly scalable systems, and focused on the hidden complexities involved in integrating large numbers of microservices that may be dependent upon each other in unexpected ways.
As Dave explains:
“The idea behind microservices is to have each service be very discrete and specific about what it does, and not to mix or aggregate many different capabilities into a single servic —so, very much a purpose-built service. The problem with that is, instead of being able to easily deal with the integration of things, you’ve loosely coupled everything, and loosely coupling everything leads to complexity.
“Not only does it lead to complexity—and you now have to manage this network of things, which are dependent on one another—you can have circular dependencies, you can have unidirectional dependencies—but then, in addition to that, each one of those discrete services is versioned. And if you change it, it could affect five other things downstream. So you have this huge dependency graph now that you have to manage. It’s really easy to manage the microservice code, because it only does this one little thing, which is great. But now, how do you deal with the ramifications of all the behaviors and all of those dependencies upon it? And that’s one of the real challenges once you actually start implementing microservices.”
There’s much more in the discussion, and you can read a detailed rundown of the topics in Alex’s blog post on The New Stack (The New Stack @ Scale, Show 2: Managing Complexity and Battlestar Galactica). It’s a serious, thoughtful conversation, but my favorite part comes 27:41 into the episode, where the four of us decide we need to have a bit more fun and launch into a spirited debate on which science fiction franchise offers the best metaphor for the nature of microservices. (My take is below the podcast player.)
New Relic is a sponsor of the New Stack @ Scale Podcast. However, the content and views expressed are those of the participants of the New Stack @ Scale Podcast, which is the property of The New Stack. Any views expressed on the New Stack @ Scale Podcast do not necessarily reflect the views of New Relic. By embedding the audio for the New Stack @ Scale Podcast or linking to The New Stack, New Relic does not adopt, guarantee, approve or endorse the information, views or products available on The New Stack site.
OK, so here’s the science fiction set up. It seems James recently started watching the cult-favorite science fiction show Battlestar Galactica, and quickly determined that “the Cylons are an allegory about microservices.” The show’s Cylon humanoid robots, he says, are completely disposable and immutable. “When one is killed, a new one pops up exactly the same … with a persistent storage layer.” Just like microservices!
But Dave counters that Star Wars’ Stormtroopers are actually the better metaphor. They’re kind of autonomous, he pointed out, and you can clone them by the hundreds of thousands if needed. (There’s that scale issue, again.)
The argument may seem like just silly fun, but I think it’s more than that. Figuring out how to work with containers and microservices can be difficult, and having an easy-to-understand metaphor (or metaphors) can go a long way toward making the concepts more accessible to less-technical folks.
Me, I think of containers and microservices are more like Minions; cute, fun-loving little fellows swarming around trying to be helpful but sometimes getting in the way. But frankly, I don’t really care what metaphor people use, as long as we have another visual metaphor besides the newly ubiquitous shipping container.