Why a Pattern Language for Microservices?

In this article, I’m going to talk about why use a pattern language for microservices.

30 years ago, the famous computer scientist Fred Brooks, who’s better known for The Mythical Man-Month said that there were no silver bullets in software engineering. What he meant is there’s no technique in software that we can adopt to give us a 10x increase in productivity.

Famous computer scientist Fred Brooks

Interestingly, there are a lot of techniques that we can adopt that will give us a sort of 10x reduction in productivity, sort of lead weights rather than silver bullets, but there isn’t necessarily a technology that can give us a dramatic boost in productivity.

Yet, 30 years later, developers are still passionately arguing over their favorite silver bullets. So if we look around the software community today, there are various technologies, languages, and approaches where there’s just tremendous passion. And people are convinced that these are genuine silver bullets, whether that’s Golang or functional programming or Node.js or Docker or ECMAScript, the latest version of JavaScript. No doubt that these particular technologies have tremendous benefits, but they’re not necessarily silver bullets. The way the debate gets expressed is in what Neal Ford refers to as the suck/rock dichotomy, which sort of is a discussion along the lines of your favorite technology sucks, but my favorite technology rocks. And you sort of see that in these debates around JavaScript versus Java, Spring versus Java EE, functional programming versus object-oriented programming, or containers versus virtual machines.

There’s this sort of very passionate debate where people love their favorite technologies, can’t see any of the downsides, and then sort of hate with a certain passion some other technology. They’re two mirrors of one another. Also, if you look at how technologies tend to get adopted, they sort of follow the Gartner hype curve, whereas, in the beginning, there’s this sort of ever-increasing level of hype around the technology, so where there’s just this belief that it’s awesome. Hype grows, and it eventually reaches this peak of inflated expectations. But then what happens, of course, is that no technology is perfect.

At this point, people actually start discovering the downsides. There are failures. And then suddenly the hype plummets dramatically, where this technology is not awesome. It reaches this trough of disillusionment. But then people start to understand the tradeoffs with a particular technology. You will go up the slope of enlightenment and end up on the plateau of productivity, where people understand that there are both benefits and tradeoffs, and they figure out how to use technology. It’s sort of an interesting exercise too.

Look around the software community, and think about where certain technologies are on the hype curve. And I think many of the popular technologies today are definitely shooting up towards the peak of inflated expectations. So why is this? Cognitive psychologists like to use the metaphor of the elephant and the rider to sort of describe how the human mind works. And the way this metaphor actually goes is that the elephant represents the emotional part of our brain. It turns out that we make decisions using our emotions, primarily. The rider represents the rational part of our brain. It tries to kind of steer the elephant in the right direction, but of course, the elephant, being big and powerful, can actually go in whatever direction it wants. Often, the rational part of our brain is actually kind of rationalizing the decisions that have already been made emotionally.

If you take that as a model of how human beings make decisions, it actually explains an awful lot about the world around us. But we as engineers, need a way of discussing and thinking about technology that sort of overcomes sort of the limitations of our human infrastructure. One technique that I’ve found to be particularly useful is the concept of a pattern. Now, of course, patterns have actually been around for quite a long time. The book Design Patterns, which popularized the idea, came out in 1994. Interestingly, patterns actually went through that height curve, as well. There were periods in time when there was a certain school of thought that said, well, you should construct your enterprise application just by applying patterns. Of course, patterns are useful, but you shouldn’t use them for everything. In general, the concept of a pattern is a really great idea.

So what is a pattern? So it’s actually a reusable solution to a problem that occurs in a particular context. And already there are some really interesting aspects to that. Specifically, it says that problems occur in contexts, and the particular solution that you might use to solve a problem is actually context-dependent. So that kind of already tells us that not all solutions are universally applicable. We always have to think about context. And we can use that idea to think about technology. The actual structure of a pattern provides a great framework for discussing and thinking about technology. So the structure of a pattern can actually take various forms, but here’s the one that I like to use. So patterns have a name. And ideally, some kind of evocative name. They have a section that describes the context, which is also known as the situation that which this problem is occurring. There’s a description of the problem that the pattern solves. Then, there’s a set of forces. So these are issues that you actually have to address. Sometimes, the issues are actually conflicting. So there’s not always a perfect solution to a particular problem. There are always tradeoffs, and you have to balance the various forces. There’s the solution. That’s kind of the core of the pattern, what’s the actual solution to the problem that you’re trying to solve within a particular context. And then there are two really, really interesting parts to a pattern. You actually have the resulting context. In other words, what are the consequences of applying this particular pattern? Then there’s also the idea of related patterns. So it’s like, well, you could use this pattern, but then there are these other patterns to actually think about.

So let’s first look at the context. The context is a consequence of applying the pattern. So there’s actually made up of three parts. There are benefits to applying the pattern. So that’s good, right? We’ve applied it, and good things have happened. But then there are the drawbacks, so the downsides to applying the pattern. Then there are actually the issues to resolve. So in other words, if we pick a particular solution to a problem, that can actually introduce other problems that we then have to solve. So this is already giving us a lot of balance, right? So rather than just always thinking about the benefits, we actually have to think about the drawbacks, and we have to think about the issues that we have to resolve, as well. We can’t ignore them. They’re part of the pattern. Related to that is the idea of the sort of related patterns. There are other patterns that provide alternative solutions to the same problem.

So in terms of microservices, you have the microservice pattern, but you also have the monolithic pattern, as well. These are sort of an either/or alternative solution approach. And then there are other patterns that solve problems that are introduced by this pattern. So in other words, you apply a pattern that gives you issues to resolve, and you resolve those issues by applying other patterns. By expressing something like a pattern, you point the user in other directions. That can be tremendously valuable. So patterns end up forming a pattern language, which is basically a web of patterns. The idea of a pattern language was actually created by a real-world architect called Christopher Alexander many years ago. To his surprise, he found himself being invited to keynote at software conferences, where he’d sort of ended up with quite a significant following. In his book, A Pattern Language, he has patterns that range the spectrum of sort of real-world architecture from a very high level, where do you place a city, the solution to that is access to water, all the way down to how do you design a room, light on two sides. It’s an absolutely fascinating book.

So just for completeness, I should express what I’m talking about in this article in terms of a pattern. So you could think of it as a meta-pattern. The problem we’re trying to solve is how you talk and reason about technology. The context is emotional software development culture, and the solution is to use the pattern format. Express design decisions, express technologies in the pattern format that forces you to talk about, or explicitly talk about both the benefits, the drawbacks, and the issues to resolve. There are various benefits to that, but namely, you have a much more objective way of describing the technology. The downside is it’s less exciting. You can’t hype it up. You actually have to be explicit about what the drawbacks are for a particular technology.

You could say that the related pattern to this is the one that’s the alternative approach, which is the “it’s awesome” pattern, where everything is wonderful, everything is great, for instance. Anyway, so that’s the meta-pattern, and that’s sort of the philosophy behind the big part of this tutorial. And now I want to sort of talking more about the actual microservices pattern language. Every few months, people introduce some more patterns. And you can find them at microservices.io.

The pattern language is made up of a few different sorts of sections. So there are the core patterns, the microservice architecture, and the monolithic architecture patterns. Because they’re connected by a double-headed dashed line, that indicates that they are alternative solutions to the same problem. There are also deployment patterns. Those are related to the microservice architecture by a solid line that’s with a single arrow. That indicates that there are problems so there are patterns, rather, that solve problems introduced by applying the microservice architecture. There are various alternatives. There are actually two main alternatives, multiple services per host, and a single service per host. Then there are various specializations of the single service per host pattern. Packaging services as VMs, packaging services as containers. Then there are various communication patterns, right? We’re building a distributed system, so we have to think a lot about distributed system issues, and interprocess communication issues.

So there are patterns around style. Do we use messaging? Do we use remote procedure calls? There are patterns around service discovery. How does an HTTP client find the network location? In other words, how does it find the IP address and port number of a service that it wants to communicate with? And then there are also some application-level patterns, some really interesting patterns around distributed data management, which, as you’re going to see, can be solved by adopting an event-driven architecture. So that’s the overview of the pattern language.

As I’ve described, by using patterns, we can take a more objective Then we’ve got this pattern language that provides a whole bunch of guidance as to if and when we should apply microservices. If we do decide to use microservices, how to go about doing it? In the next few articles, I’m going to look at the core patterns, the monolithic architecture, and the microservice architecture patterns. Thank you for reading!

You can support me by buying a coffee ☕️ here https://www.buymeacoffee.com/asirihewage

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store