April 18, 2022
The First Rule of Building Microservices: Don’t Build Microservices
Does this describe you?
If so, then you must have heard about Micro Services and wondered if this is just a buzzword, or something you should seriously look into. If not… you are free to go read another blog!
I spent much of this year migrating a large legacy system onto a Micro Service architecture, which ended up looking much like the diagram below – and I’ll go into it in some detail later on. As you can see, the diagram includes lots of concepts you probably came across when researching this pattern, such as API gateways, micro services, message brokers, containers and maybe even Kubernetes. I’ll add a few that are not in the diagram itself… “loosely coupled”, “eventually consistent” and “distributed”.
Chances are you don’t have any of these things in your current architecture! Does it sound like this will be a lot of work? Should you do it? Why? What are the gotchas? This blog aims to help you reason about this decision.
Starting with the obvious: yes, this will be a lot of work. It can be done in phases, but it’s a pretty daunting undertaking, so I wanted to spend some time first talking about why you would want to do this – or not!
The usual reason to actually start out on this micro services journey, rather than just read about it, is that you have some serious pain with the way your system is currently architected and the cadence of releases.
The typical “current state” is a legacy system that has bloated over time. It’s written in a somewhat older technology stack, and you would love to take advantage of new tools, frameworks and processes, but your app has grown into a monolith. The system has all kinds of important business logic, but it’s a bit of a mess, with tentacles of code written by different developers and architects, some of which are no longer with you. There are many customizations, special cases, configurable features and hacks that weren’t supposed to be permanent, but just became part of the system. You have customers (internal or external) clamoring for new features, which sound really easy to develop with modern tools – but you can’t because you are stuck with this huge beast. To make it worse, the database has grown to a sprawling web of tables, many of which are just for some custom one off, but there are all kinds of references between the tables, shared data access layer logic and business logic, and APIs, that seem to make it impossible to change anything without breaking something seemingly unrelated. The system is also burdened by all kinds of nightly batch jobs which seem to run longer and longer despite throwing more and more costly hardware at them, and a myriad of system integrations. When you do release new versions, they are full of bugs that only get discovered months later in production.
Here are some of the issues that our team and our system was facing:
Does this sound like your system? Maybe you don’t have all of these issues, but several? How are you going to move forward?
If you are still reading, it’s a safe bet you might think Micro Services might be the silver bullet. Maybe it is – but let’s talk about how this architecture addresses some of the issues detailed above, and even more importantly, what effect it’s going to have on your organization, and what kind of work you will be needing to do with possibly brand new skill sets. This will be the topic of the next blog in the series – stay tuned!