Are microservices for you? You might be asking the wrong question.
Deciding whether to use microservices starts with understanding what isn’t working for you now.
Upper Antelope Canyon (source: skeeze via Pixabay)
So here’s the thing: We operate in an industry where any problem has many good answers. It’s rare that any non-trivial challenge we face has a single, simple answer. Instead, we bring to any particular problem our own understanding and skills, look at the situation we are in, and hope that whatever we decide to do is the right thing.
Often we take a reductionist approach to the right thing to do in computing, and the more complex the problem space, the more perilous this view is. What is right for me might not be right for you. The people around us might be different; we might have different skills, different worldviews, different goals we’re trying to achieve. All of this is why it is so hard to answer the question I frequently get asked by people: “Should I use microservices?”
Learn faster. Dig deeper. See farther.
It’s not just over a decade of consulting experience that makes me give the answer “It depends”. It is because, without understanding the context you are in, I cannot give you a sensible answer.
When asked, I used to start asking questions like how big is your organization, how many developers do you have, who manages your infrastructure, what technology do you use. But over time, I realized that these questions, while they might provide some useful information, they sort of miss the point.
Now, when people ask “Should I use microservices?” the first set of questions I shoot back are things like “Why do you want to change?” or “What isn’t working for you?”
Asking what isn’t working helps spot a good fit
Change for the sake of change is rarely a sensible use of time. So, if you are an organization that right now uses a more monolithic architecture, before you start asking if microservices are for you, ask what isn’t working for you, and why you think microservices might be a good fit.
- Perhaps you’re looking to improve autonomy of teams in a larger organization, allowing them to release their software when they are ready without having to coordinate with other teams.
- Maybe you’re looking for different ways to scale out your application or introduce new technology to solve new problems.
- You might even be looking to make your application more secure.
These can all be good reasons to start adopting a microservices approach. However if you’re a small team, working on a brand new domain or have difficulty automating the build and deployment of your existing technology stack, you might want to give microservices a miss for the moment.
In my book, I have a more detailed examination of what benefits microservices can bring and the problems they introduce. In my upcoming online training course, From Monolith to Microservices on October 26 & 27th, I’ll be exploring this further, and helping teams implement sensible microservice adoption strategies (where applicable). I hope you’ll join me to learn more!