Are you early in your microservices journey? Maybe you’ve decided you need to start deploying applications outside your monolith but you haven’t cut any code yet. Or maybe you’ve put your first few services into production and addressed some of the first pains that happen when you start on that path.
A common question that comes up for teams at around this time is:
“What should we split out into a microservice first?
And why?”
A lot of organisations start with a monolith and move to a more distributed architecture once the business has some traction. At the point where microservices becomes “a thing we want to do”, there can be many options for which parts of the product could be used as the pioneering experiments.
Over the next few weeks, I’ll be publishing a series of articles that looks at heuristics you can use to choose valuable parts of your system to separate out. First, though, let’s talk about the overarching heuristic that drives all of the suggestions in the following articles:
The #1 Heuristic for Your First Microservices: Choose a Problem to Address
You’re doing microservices for a reason, right? Maybe you have some problems already that you think it will address. Or maybe your foresee problems that will rise up soon if you don’t start doing things differently. You’ve decided to either split up your monolith, or do new work outside the monolith as much as possible.
My over-arching guideline for choosing what to attack first is this: You’re moving to microservices to solve problems, so your first microservices should be things which will solve your current problems.
You’re moving to microservices to solve problems, so your first microservices should be things which will solve your current problems. Share on XIn the upcoming posts, I’ll cover a slew of problems which your organisation might already have identified. I”ll show how each of them could be solved as part of your migration to a microservices architecture.
Get a Return On Investment From Your First Microservices
One thing you want to keep in mind with each problem area I’ll cover is to always judge the return on investment. Just because you identify with one of these problems doesn’t mean that it’s a problem that your team must solve now.
Remember that the cost of deploying microservices is usually high for orgs who are new to this. You’ll have to figure out new approaches to deployments, monitoring, and security, among many other things. If you choose to attack a problem that has a small impact, you could find that deploying the functionality into a new service won’t pay off in the near term. Ideally, you’ll want to look for the service opportunities that are quick wins in terms of the value returned to the organisation.
However, there is also a counter-argument to consider here. Each new service deployed will give the team feedback and start building their muscle around deploying and operating a distributed system. That muscle will result in compounding returns in the long run. So you won’t get all of the benefits immediately, but ideally you’d love to get a large chunk of payback quickly.
Focus on Making Measured and Continual Progress
Finally, I recommend being careful about not chewing off too much at once. Don’t try to change too many things or tackle multiple hard problems in one go.
For example, let’s think of an organisation that’s building their first microservice, and everything in their monolith currently uses a single database schema. Such an org should consider making their first service something which doesn’t need a database. That way, they can focus on the problem of getting a second piece of software deployed into production, without the added concerns of getting a new schema into production and all the ripple effects that has on usernames, passwords, backups, and the like.
However, you also don’t want to leave those extra hard things too long. As soon as you’re comfortable with deploying new things that don’t have databases, move on to deploying something with its own database. If you leave the harder bits for too long, that extra challenge may start to appear too hard and become a mythological danger zone where no team wants to tread.
Problems That Could Be Solved By Your First Microservices
I’ll be adding each blog in the series in a list below as it is published. If you want to be notified when future articles are published, sign up using the form on the right just under my photo.
- Using Microservices to Solve Slow Build Times
- Using Microservices to Solve Developers Stepping on Each Other’s Toes
- Using Microservices to Make Costly Deployments Less Frequent
Image credits:
‘Project 365 #71: 120317 Box Of Cogs‘ by Pete (from Liverpool)