Designing Microservices for fast flow
Small Talk with Chris Richardson
This blog post is the transcription of the chat we had with Chris Richardson about his Designing Microservices Workshop on 2 September 2024.
The conversation has been slightly edited to better fit the written format. Enjoy!
Avanscoperta: Chris, would you please introduce your workshop to us?
Chris: Designing Microservices Workshop is a three-day in-person experience (Milan, 20-21-22 November 2024 - tickets and info). As you can guess from the name, it's about designing microservices. Specifically, it introduces a process, a sequence of design activities with deliverables for designing a microservice architecture. It's not about technologies like Docker, Kubernetes, Kafka, and many of the things that we traditionally associate with microservices.
This is for one simple reason—technology is important, but it's not the hard problem to solve when using microservices. The key to determining the success or failure of your development efforts is to design a service architecture.
You define the service architecture by identifying services, defining their responsibilities and APIs, and then designing distributed operations or requests that span multiple services. This includes appropriately applying service collaboration patterns like Saga, API composition, and CQRS.
This is the key challenge you will face when using microservices. If you get it wrong, in the worst case, you can create a distributed monolith that combines the complexity of a distributed architecture with all of the friction of a monolithic architecture. So, instead of accelerating software delivery, it will actually make it worse, and you can end up in a world of pain.
The first thing you need to do is ask yourself - is the microservice architecture a good fit for my application? Do I have the complexity and the team size, the warrants using microservices, or should you stick with the monolithic architecture? And then if microservices are a good fit, in the workshop we will see how to design a good microservice architecture.
The workshop is targeted at senior developers, enterprise Java, C#, .NET, but all in all it's pretty language-neutral and technology-neutral.
So it's for people who are building enterprise applications, architects, CTOs, VPs of engineering, who either want to use microservices or are thinking about it, or are in the middle of using it, and want to do better at it.
Avanscoperta: One of the things that emerged is the importance of this workshop not being purely technical. So it's not about the technology itself, but more about the overall approach.
Let’s read a question from the audience—this one is from Marco Heimeshoff, one of our trainers (Hi Marco!). He asks: How does API composition relate to CQRS and microservice architecture?
Chris: Microservice architecture it's comprised of multiple services (two or more), and as a result, some operations or requests will span multiple services. In order to implement them, you need to use what I call the service collaboration patterns. And there's four patterns, two for implementing commands, which mutate data, and two patterns for implementing queries, that retrieve data.
This question actually asks about API composition and CQRS, which are the two patterns for querying data in a microservice architecture. So the problem you're trying to solve is something like - find order history, which has to query a bunch of services, such as order service, restaurant service, delivery service, so on and so forth, and gather data from all of them.
API composition is a very simple pattern in which a query is implemented by retrieving data, issuing subqueries to retrieve data from the services that own it, merging the results together, and returning them to the client, the browser, or whatever.
Whereas CQRS actually maintains a replica of the data, designed from multiple services, specifically to answer that and perhaps other related queries. The services that own the data publish events that trigger the update of the replica so that it can be queried.
These are the two patterns, and there are just different trade-offs associated with each one. API composition is super simple but it might not be efficient. So you might want to use CQRS, but then you've got the cost and the complexity of replication and the fact that updates are delayed and so on and so forth.
Each pattern has its trade-offs, and this is one of the key topics we’ll explore in the workshop.
Avanscoperta: When we talk about microservices, it's still one of those buzzwords that's been around for a good number of years now. And your work has been really important for this.
So do you think microservices are they still in their moment of hype somehow or is it fading? How do you see the implementation of microservices in the overall scenario?
Chris: I would say that it’s like every technology - they go through this hype cycle. It rushes up to the peak of inflated expectations where people just think it's truly amazing and it has no downsides. But obviously, all technologies do have downsides and then it plunges to the trough of disillusionment where everyone thinks it’s terrible. And then after that, you've got the sort of plateau of enlightenment followed by the plateau of productivity.
The ideal state is to reach the plateau of productivity, where you understand the trade-offs associated with the technology and know when to use it.
I would say that microservices are past their peak of inflated expectations, and a fair number of people are writing about how the pendulum has swung the other way.
And if you post, and this has been true for a while now, a really insightful tweet about microservices, the level of engagement is OK, kind of average. Whereas if I say something good about monoliths, well, the engagement is off the charts.
Interestingly, I actually wrote about this 10 or 11 years ago, talking about the Gartner Hype Cycle and microservices. I've sort of always viewed my mission as actually fighting against the hype and the anti-hype and moving developers to the plateau of productivity as quickly as possible so that they know when to use it and when not to, and also how to use it effectively as well.
And I’ve been doing this because it's my area of expertise, but on the other hand, it's a tool, you know, and you use it when it's appropriate and you should not use it when it's not appropriate.
Avanscoperta: This is a good hook for my next question about monolith vs microservices, sometimes referred to as a dichotomy but as you just said - sometimes is good to have a monolith, it is not always a bad thing.
Chris: Well, it's like, what is better, a bicycle or an aeroplane? Depends on where you have to go, right?
I feel that the software community can become very polarized, which should be avoided. To stay within the example, I might use a bike to get exercise around my neighbourhood, but I'm not going to Europe on my bicycle.
Avanscoperta: There's a quote from one of our trainers, he also does a workshop on microservices, and he’s called Gianluca Padovani. He basically says that the monolith is like a person who does not feel well, you shouldn’t fight against or hate the monolith. The monolith just needs treatment. You shouldn’t be against the monolith for the sake of it, kind of thing.
Chris: Ten years ago, I created the microservice architecture pattern language. In the very beginning, there were three patterns: monolith, microservices, and API gateway. This was the first release of the pattern language, and by definition, the monolith is a pattern—it's not an anti-pattern. It's got benefits and drawbacks, and it depends on when you use it—just like microservices.
In a way, I feel like I've spent a lot of the past 10 years trying to refine the criteria for when you should use one versus the other and the trade-offs associated with each one.
Avanscoperta: As usual, it’s all a big “it depends”, as it is with all trade-offs. Next question from the audience: Does a database have to be a microservice on its own?
Chris: Interesting question for a couple of different reasons. One of the defining characteristics of a microservice architecture is that services must be loosely coupled. And there's a few different meanings to that word, but one that is relevant here is loosely design time coupled, which means that changes to one service should not require changes to be made to other services.
A key part of loose design-time coupling is services not sharing database schemas, which would introduce tight design-time coupling.
The schema is basically an implementation detail of a service, which you should be free to change without having to coordinate with the 10 other teams whose services are using the same database schemas as yours.
It’s like a database schema per service, and ideally, to maximize the loose coupling, you should have a dedicated database server. But that's not a hard requirement; it's just convenient from an operational perspective. One service cannot overload a shared database and perform essentially a denial-of-service attack on the other services.
And we just covered some background. The wording of the question is interesting—does its database have to be a service? In my mind, in a microservice architecture, you have services which are like well-designed domain objects, a mixture of behavior as in business logic and data as in a database schema.
I wouldn't have a database and stick a REST API on it to make it into a service. That's very likely to be an anti-pattern, primarily because of reasons of design-time coupling and lack of encapsulation, because you're basically exposing the database in its entirety as a REST API.
Avanscoperta: Let’s go back to what we’re actually going to do during your workshop. You mentioned that the workshop won't be based on a specific language. So how are we gonna balance the theory vs practice aspect during these three days? What will we be doing?
Chris: There are certainly lectures. The overall format is that I will walk you through the five steps of the design process, which are:
- discovering system operations,
- designing subdomains,
- defining a service architecture,
- evaluating said service architecture and
- refactoring.
So those are the five steps of the design process.
We're going through that design process for an example application. At the start of each step phase, there will be lectures and discussions introducing what we’re going to do next, but then the bulk of the time will be spent getting together in small groups—essentially four teams—and doing the design exercise either literally on paper or, if you want, on a Miro board or whatever medium you want to use. I've even had people in workshops using spreadsheets as design documents, which sounds strange, but it definitely worked for them.
Then we get together, and another really valuable thing happens: we review the design and discuss it in detail. The format is lecture, design, exercise, review, and iterate until we're done, basically. Post-it notes can be used for this too. Not quite as many as Alberto, but you can use a fair number of them.
Avanscoperta: As we discussed, you’re also the author of a few books on microservices, one of them being very famous. Are there any tips or interesting stories about how the books came about, or is there anything you’d like to share about the process of writing a book, which I imagine must be a challenge somehow?
Chris: Microservices patterns came out in 2018, and was my second book. The first one was Pojos in Action, all about Spring and Hibernate, published back in 2006.
I don't know why, but for some reason, starting in the early 2000s, I sort of had this desire to write a book. I even started drafting a completely different book about web frameworks as in HTTP and frameworks… so that is to say I did have this strange desire to write a book.
And then the first one actually ended up taking four years, I think I virtually had post-traumatic stress syndrome. It was such a painful process! I like comparing writing a book to climbing Mount Everest—it might seem fun at first, but then you get to 20,000 feet where it's freezing cold. You're starting to get frostbite and you can barely function because the oxygen level is really low.
But you've invested so much in it that you can't quit. It is just a truly stressful experience, and that was the first time.
The second time I spent two years writing the book and it was a lot less stressful but to a certain extent… Mount Everest was still there. A lot of analogy applies. But I did not suffer from PTSD the same time around. I could actually open the book and look at it without getting an anxiety attack. That's a good improvement.
Avanscoperta: Is there a third book in the work by any chance?
Chris: Very unofficially I'm in the super early stages of thinking about the second edition for Microservices patterns.
Avanscoperta: Would it be an updated edition or will there be some new content?
Chris: The microservices patterns book was written from 2016 to 2018, and what's really cool about it is that the core patterns have not changed, but obviously, some aspects of technology have changed. Kubernetes has become much more mature, for example.
Surprisingly, a lot of stuff, the concepts have not changed a huge amount, but in reality, I feel like I've changed a lot. So the design process that I'm teaching in the workshop we’re doing together was developed after the book. So in the book, I just have a few pages dedicated to the process, whereas now I've got quite a rich body of work around this design process, meaning there are quite a few years of conceptual improvements that can be incorporated.
I guess a lot of people know The Hitchhiker's Guide to the Galaxy, which started off as a British radio drama and comedy. One of the quotes from one of the authors, Douglas Adams, is, "I love deadlines. I love the whooshing noise they make as they go by."
My publisher doesn't like that quite as much, of course!
Avanscoperta: One of my last questions is about feedback on this approach. Do you usually get called into companies to transform from monolith to microservices, or not? In general, how are people reacting to this?
Chris: In a nutshell, I’ve been teaching this workshop for a while now, and then some of the core concepts from the workshop—I've been talking about those even longer, particularly the dark energy and dark matter concepts, which are about the 10 criteria that you can use to evaluate the suitability of a design.
In general, the feedback has always been positive. Folks say that it provides a good framework for thinking about design. I think this is at the core of it.
And the key message is - it depends. The next thing is—well, what does it depend upon? It tends to depend upon these 10 criteria within dark energy and dark matter.
Overall, my work provides people with a great way of thinking about the numerous design decisions that they need to make when designing a microservice architecture and avoids the trap of simply defining lots of tiny little services, which is the myth associated with microservice architecture.
Avanscoperta: Are there any other resources we should check out as we prepare for your workshop?
Chris: Yes, microservices.io has a tremendous amount of content, and you can read about the design process.
There's also premium.microservices.io, where, for a modest subscription fee, you can read practical articles about the challenges that engineering leaders face and how to solve them.
Avanscoperta: Thanks a lot!
Check out Small Talk on YouTube or Spotify.
Cover picture by Mitchell Luo on Unsplash.
Learn with Chris Richardson
Chris is the trainer of the Designing Microservices Workshop, taking place on November 20-21-22, 2024, in Milan (Italy).
Check out the full list of our upcoming training courses: Avanscoperta Workshops.
Subscribe to our Newsletter 📩 (available in Italian and English) and be the first to know when we schedule a new workshop or we publish a new workshop.