Coding Over Cocktails is giving away a FREE eBook copy of “Microservices Patterns” by Chris Richardson to one (1) lucky listener courtesy of Manning Publications via Manning.com. To enter, simply follow Coding Over Cocktails on Soundcloud and share your thoughts on this episode in the comments. 

All listeners will also be given a 35% discount to purchase “Microservices Patterns” and other products from Manning’s entire catalog. Just enter the promo code PODCOCKTAILS21 before checkout. 

Kevin Montalbo

Joining us today, as always, for a round of Cocktails is TORO Cloud CEO and Founder David Brown. Hi, David! How’s Sydney?

David Brown

Good day, Kevin! And it’s pretty wet and cloudy today.

Kevin Montalbo

Okay. Our guest for today is an experienced software architect and entrepreneur who provides consulting and training for organizations to successfully use a microservices architecture.

He’s the guy behind Microservices.io, which outlines a pattern language that helps users decide if microservices are a good fit for their organization. He’s also the author of Microservices Patterns, and POJOs in Action, both published by Manning, and is a “Java Champion” as well as a JavaOne rockstar speaker and speaks regularly at conferences all over the world on software development.

Today, he joins us for a round of Cocktails. Chris Richardson, welcome to the show!

Chris Richardson

Thanks! It's good to be here. Sadly, I don't actually have a cocktail. It's just a cup of peppermint tea.

Kevin Montalbo

Yeah. no problem. I have a coffee. It's too early for a cocktail here in the Philippines too. All right, so let's talk first about your startup, Eventuate IO. Can you explain to us what challenges associated with microservices are you trying to address over there?

Chris Richardson

Yeah. So if you think about what is microservice architecture, it's an architectural style that structures the application as a set of loosely coupled services. It sounds super simple, but one immediate consequence of that is that services should not share databases. They should not share database tables and ideally, they should not share database servers either because that introduces both design time and runtime coupling. Take a really simple use-case like creating an order, you know that you create an order in the order service. But at the same time, in order to make sure that the order can be created, you have to reserve credit in the customer service and say, potentially, inventory in the inventory service, right? So you've got a request that spanned multiple services. 

You can't just use regular transactions. You can't use distributed transactions. You can't use two-phase commit. So instead, you have to use a pattern known as the Saga pattern. There's a couple of other ones as well. Basically you have these distributed data patterns, and Eventuate is an open source framework that enables you to solve those problems. It provides you either an implementation of these patterns or the building blocks that let you use the pattern in a way that's appropriate for your application.

David Brown

In 2018, you released the book Microservices Patterns with Manning. It's been praised for being a must-read book on patterns and architecture. A few years have passed. Has anything changed? Is there anything you would update in that book? Or are we still largely following the same architectural principles that you outlined there?

Chris Richardson

What's interesting, if you actually think about the book, it was written more or less over a two-year period, I think, like late 2016 all the way to mid-2018. I think what's remarkable is I actually think it's all generally pretty valid still, right? It's still set around key patterns. I think there's like 40 plus patterns in the book, right? And, you know, they're still very applicable. Certainly you could say that since writing the book or even while writing the book, I did a tremendous amount of consulting and training, which gave me insights into how organizations kind of adopt microservices and use them. And certainly some of the technology has matured.  You could say maybe in the beginning, Kubernetes was not that well-established. And of course, now it is, and so on. So sort of the core stuff, I think the core of it is very, very stable now. 

Now one day, could I write a second edition? I think I could. So, you know, a few things come to mind. For example, in chapter two of my book, I described a process for defining a microservice architecture. You know, based on my experience over the past two years, I would expand that chapter considerably. I mean, there's actually a risk that it might be an entire book in itself. It might be a challenge to fit it in the book. I've certainly learned a lot about how organizations adopt or to be more specific, misadopted the microservice architecture. So, I could imagine adding a chapter there about antipatterns of microservice adoption. 

David Brown

Let’s talk more about antipatterns. You mentioned you've talked about those extensively, and so we often talk about the organizational change required to implement microservices when we've had these podcasts with other guests. And we often talk about how it's an organizational challenge, not just a technology challenge. But you've gone through a bunch of antipatterns, and I'd like to go through some of those technicalities. Before we do, you published your book in 2018. We recently had James Lewis, who in 2014, wrote the definition of microservices. How influential was that for you, that paper?

Chris Richardson

Well, yeah. You know, what's funny is, so I actually got interested in this style of architecture. As in, you know, breaking up what would otherwise be a large monolith into multiple services back in 2010, right? I read this book, “The Art of Scalability.” And in the book, they had this scale cube, which was a three-dimensional model of scaling. And one of the dimensions was the Y-axis, which was functional decomposition. And that really resonated with me because up until then I had just been building a series of monolithic applications and in the last one, had actually been the original Cloud Foundry. That was a monolith, the original Cloud Foundry. It was actually a monolith. And even though it was built by a tiny team, i.e. two people, it was actually quite elaborate. Quite. It wasn't your standard sort of enterprise application. And there was all this diverse functionality packaged into a single Java WAR file. And had we at the time, built it using the microservice architecture, we would actually solve a whole bunch of problems. Really, the scale cube model and functional decomposition really resonated with me. But I didn't have a name for it. And I actually gave a talk about this in 2012, and it was, like decomposing applications for, I don't know, testability and scalability or something. It was one ability and some other ability, I talked about it. Well, maybe we could call this a “modular-polyglot architecture”, but that doesn't exactly roll off the tongue.

So it was funny. It was kind of new to me. But then, of course, Amazon had adopted this architecture back like 2002. And eBay, it adopted this architecture back in 2008, but there wasn't really a name other than this sort of “distributed system”, which is kind of boring. So that paper, you know, which promoted the term microservices even though for reasons I could go into is actually a terribly misleading term, that was a term that the whole community could adopt. The whole industry could adopt as well, and it generated a lot of momentum, right? Including vendors who had previously been cloud washing their products are now trying to claim they were microservices-relevant as well. But, you know, just having a term that everyone understood kind of acted as a great unifier.

David Brown

Interesting. You said previously, in order to migrate to microservices, you have to learn how to strangle the monolith. Can you explain it to us a little a bit?

Chris Richardson

You know, interestingly, it's sort of a slightly violent term. And it actually goes back to an application modernization strategy that Martin Fowler promoted in 2006, I believe, known as the Strangler Application. And he has since modified it to the Strangler Fig Pattern. And so I guess one day he was going for a walk in a rainforest, I think in Queensland, right? Do they have rainforests?

David Brown

They do in Northern Queensland.

Chris Richardson

Yeah. And so he got inspired. He came across a Strangler Fig, which is this plant that starts off life in the canopy of a tree and then actually grows down to the ground and establishes roots and basically grows so large it envelopes or sort of, you could say shades out the tree, and that can actually cause the tree to die.

And so that was where he got inspired to think about modernizing applications that way. So instead of doing a big bang rewrite, which is extremely time consuming and risky, you actually incrementally build up a strange regular application around the legacy application. Sort of migrating functionality out of it, you know? Very intuitively. And so the legacy applications shrink, and the Strangler Application continues to grow. And so that was his generic application modernization pattern. And that's how you should migrate to a microservices architecture. So, you gradually migrate functionality one module at a time, out of your monolith into this Strangler Application or Strangler Fig Application and so that's this incremental iterative process. Yeah, we can take a number of years, but the key thing is you focus on those areas of your application that give you the sort of the greatest return on investment. So say the areas of the application that a quarter of the business that gives you the competitive advantage, those parts of the application that you're changing constantly.

David Brown

And I guess starting off with probably the simplest one with the most narrow scope possible as well. So you get an easy, quick win and say, “We've now migrated one tiny, tiny little bit of our monolith into a micro service,” and they've got the learnings associated with that. 

Chris Richardson: Yeah. Well, you might want to practice. You might want to practice on some easy parts, but you know very quickly. You should focus on those parts of the application that have a module that's constantly being developed. You turn it into a service so that you can quickly develop it or maybe there's a module that's causing scalability or reliability issues, you migrate that into a service so that you can scale it independently.

David Brown

Now, interestingly, you responded to a tweet a couple of months ago, saying that microservices and monoliths can both be mistakes. How did that come about? And what do you mean by that?

Chris Richardson

These days, if you wanna get a high level of engagement on Twitter, you should just tweet “Microservices suck” or “The monolith is the way to go.” 

David Brown

Having a resurgence is another one. There’s been a lot of people who say monolith still has its place.

Chris Richardson

Well, yeah. I mean, you know, I think to a large extent, right? I mean, what's happening is we're following the Gartner hype curve right? Where, you know, with, like, every technology seems to go through this, right? So, it gets hyped up and you know, microservices aren’t for everything, and you reach the peak of inflated expectations. And then, of course, you realize that it's not appropriate, and people get frustrated. You know, they build distributed monoliths that are worse than an actual monolith, and then they can give conference talks on it. It kind of sucks for the business. And then, you know it was the trough of disillusionment. Right? So this was sort of in this backlash phase. And so it's sort of to some extent, it's understandable.

But my approach has always been, you know, which is why I created Microservices.io and created the patterns of language is that, you know, the monolithic architecture is a pattern. You know, it solves the problem in a particular way, and it has certain benefits and drawbacks. Microservice architecture is another solution with benefits and drawbacks, right? And neither of them is universally applicable or universally wrong. And your job as an architect is to pick the architecture that is best suited to your particular application to your particular context. Right? Which is why I kind of started down the patterns path, right? I didn't create a Microservices manifesto, because I think those are sort of garbage actually, apart from the Agile manifesto, because I think Agile is generally good. But, you know, a lot of these sort of manifestos, they're not engineering documents, right? Because, you know the right solution really does depend on a particular context.

David Brown

Well, I'd like to talk about some more of the engineering principles here. So you talk about antipatterns for microservices and various interesting phrases like “magic pixie dust” and the like. So can you explain some of the antipatterns of microservices?

Chris Richardson

Yeah. So these were sort of patterns that I observed while basically consulting with various organizations. You know, there was this time when you could get on a plane and you could fly to places and have face-to-face meetings. 

David Brown

Sounds awful. 

Chris Richardson

And you know you have to put on pants.

David Brown

Really?

Chris Richardson

Yeah. Anyway, apparently people did this, right? So you know, I think I was flying like 160,000 miles a year or something like that. It was kind of insane, but it was just like visiting all of these organizations and helping them adopt microservices. And with some clients, I saw these sort of antipatterns of adoption. You mentioned magic pixie dust, right? And that's sort of believing that microservices are this magic pixie dust. You just sprinkle it on your development organization, and it will solve all of your delivery problems, right? And in reality, if you have issues with your development process and your organizational structure, throwing microservices into the mix won't fix those problems, and it's very likely to make them worse. So that's a common pattern. And, you know, that ties back to the earlier thing about microservices hype and just seeing them as this amazing thing that you should just use always, right? 

And then, you know, the other pattern, which is really interesting, is like, kind of measuring success as a function of the number of microservices you have. The more we have, the more successful we're going to be right? And in particular, there was one client where, CIO just announced “We're going to do microservices.” And it's a very sort of top-down hierarchical organization. And I meet developers. And it was like, “Why are you doing microservices?” “Well, my manager told me to.” Right? And it was almost like the bonus was dependent on how many services they created. But you know that's terrible. 

David Brown

What’s the red flag law?

Chris Richardson

And then the red flag law. So the idea there was that, you know, in the early 19th century, when the automobile came out, some jurisdictions - at least I don't think this is sort of an apocryphal story - some jurisdictions required a pedestrian to walk in front of the car waving a red flag. So you had this vehicle which presumably could go faster than a walking pedestrian, but they were slowed down. And so the idea with that pattern is you've adopted microservices, but you've kept in place your existing organizational structure and your existing processes so you can't properly benefit, right? Like one client I worked with, you could only deploy to production like on the third Saturday of the month at midnight. Right? That was the rule, which is great, but you want to adopt a microservice architecture that lets you deploy safely into production many times a day. But you're not gonna let people develop, you know, deployed into production many times a day. I mean, it's sort of very reminiscent of this pedestrian waving a red flag, right?

David Brown

Yeah. I mean, one of the objectives is clearly to become a more agile organization with more frequent deployments and change.

Chris Richardson

Yeah, that's the big driver, right? You know, Covid is a great example of this, right? In the world, the state of the markets within which businesses operate are very sort of volatile, uncertain, and complex and ambiguous. You have no idea where competitive threats are going to come from. Apparently, now we have to contend with a global pandemic which has directly impacted IT in a lot of organizations, right? So that means that IT needs to be nimble. They need to deliver software rapidly, frequently, reliably and sustainably. 

And how you do that is a combination of DevOps, continuous delivery, continuous deployment, having the organizational structure as a network of loosely coupled teams, and then the third element here is your architecture, right? So, if you think about DevOps, that's all about delivering a small stream of changes very rapidly. A stream of changes into production.

So, that requires an architecture that's testable and deployable, right? You think about the organizational structure, you think about Conway's Law, where in order to have a loosely coupled organization, you actually have to have a loosely coupled architecture as well. So you need a modular, loosely coupled architecture there. If you think about those characteristics, it has to be deployable and testable because that's what DevOps requires. It has to be loosely coupled and modular. That's what the organizational structure requires, right? As an architect and if you're working in an environment where you do have to deliver software rapidly, frequently, reliably, you need to make sure that your architecture has these characteristics. This is what I call the success triangle. 

And sometimes, if you've got a monolith, a monolith is just fine, particularly when you have a small application and a small team of people. But as the application grows - as long lived applications typically do - and also, if you're super successful, you get a bunch of VC fundings, before you know it, you've got a couple hundred developers or more, right? That large team is pushing you in the direction of using the microservice architecture rather than having a lot of developers all contributing and clashing, trying to deliver this large codebase where you break it up into an architecture where each team has their own service that you're likely to be much more successful.

David Brown

Are you seeing the momentum being driven by migration of legacy systems or in New Greenfield development?

Chris Richardson

Most people I've met with over the years, it's like enterprises have already written the key business applications, right? The majority of the scenarios have been migrating a legacy monolith to a microservice architecture. And even newer companies, like startups that are just a few years old, have started with a monolith, which is usually a good approach, by the way. Because if you're a small startup, you don't have a massive codebase, a large team of people. So, you don't really have the problems that the microservice architecture evolved, but very rapidly, I think, you know, particularly VC funded startups, they actually find that they actually got a big application, big monolith on their hands. And they need to split it up and migrate it to a microservice architecture.

David Brown

Understood. Interesting. So what are the technology changes, if any? Like, you know, we've seen protocols like gRPC. Are there any other sort of technologies which are influencing a microservice adoption?

Chris Richardson

What I find interesting is - and this is actually another antipattern - is that you know, organizations often focus on the technology side of it. There was actually one client I worked with a few years ago, where before they even implemented their first service, this VP of Engineering was going, “Well, should we go spend, you know, six figures on some fancy PaaS platform?”

It depends on the PaaS vendor and make sure you like it. But you know what? I was just saying, “How about waiting? Waiting until you've actually deployed some services and operated them and actually properly understand the problems that you're going to be facing and before making such a big purchasing decision?” Because if you're doing it up front like that, you're making decisions when you have the least amount of experience and the least knowledge, right?

But that’s sort of a generic thing. It's sort of like “Technology, technology, technology,” whereas in reality, the most critical issues and decisions that you have to face really are around, “What are my services?” and “What are the responsibilities of each service?”, “What is the API that each service offers and how do the services collaborate?” Right?

And you know, that kind of decision making is actually very abstract, and it's fairly, pretty independent of the underlying technologies that you're using. In fact the only aspect of technology that's critical is that you should have, primarily, a loosely coupled asynchronous architecture as opposed to one way your services are communicating using synchronous protocols like, REST and the synchronous aspects of gRPC .

David Brown

I understand. And you've built some amazing resources on this on Chrisrichardson.net. Tell us what sort of things people can expect to find on your website?

Chris Richardson

Yeah, my content sort of split across Microservices.io and Chrisrichardson.net. So Microservices.io is primarily the pattern language. There's a bunch of other stuff there, links to presentations, code samples and so on. And then on Chrisrichardson.net, there's just very various blog posts on whatever topics on my mind. I don't really blog enough. I get too much bottled up inside my head.

David Brown

Chris, thank you very much for your time. Today has been a pleasure. We look forward to speaking to you again in the future.