Chris Richardson talks about the common antipatterns found in microservice architectures and discusses the decision-making process for their adoption.
Join the DZone community and get the full member experience. Enterprise applications often evolve into large and complex monolithic architectures that can often be quite challenging to maintain. This makes adopting a microservice architecture very appealing for most modern organizations who would like to undergo digital transformation. But, as with most things, this is easier said and done — not just because of the technology-related challenges, but also because of the way people react to change, as well as their preconceived notions as to what microservices should be. In this episode of cocktails, we talk to an industry expert on the microservice antipatterns that have emerged over the years, how to avoid said anti-patterns, why both monoliths and microservices can become mistakes, and how we can ‘ strangle ‘ the monolith. 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. KM: 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. KM: 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? CR: 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. DB: 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? CR: 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. DB: 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? CR: 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.
