Good microservices have a clear purpose, but not all good microservices have a clear owner. Some services serve a utility purpose and are shared among multiple consumers in your technical landscape. How do you best look after these shared services?
Examples I've come across include services that manage page layout, services for generating PDFs, and services for sending emails or SMS messages. It's easy for these services to fall into disrepair because they lack a clear owner.
Here's how to best manage them, based on my own experience of working in a microservices environment.
1. Make sure you actually have shared services
If you don't have any shared services, you have a different problem. The only thing more prone to disrepair than shared services is lots of very similar code distributed across multiple codebases.
If everyone writes their own code to send emails, for example, then three things happen:
Your microservices become bloated with email code and stop having the laser focus that's useful for microservices.
Everyone wastes time writing duplicate code.
The "duplicate" code will never be an exact duplicate, and all of those small differences will lead to odd bugs and hard-to-pin-down inconsistencies.
The downside of creating shared services is that they're tricky to maintain. These tips will help you navigate successfully.
2. Keep domain logic out of shared services
Avoid domain logic leaking into shared services. Imagine if you created your PDF-generation service in such a way that each new consumer needed to add little bits of logic or information about their specific domain. The PDF microservice would end up with little pockets of, for example, payment logic and user registration logic.
A good, well-focused PDF microservice should be able to go for months without code changes, even while taking on new consumers. But if your service is built in such a way that domain logic needs to sit in the shared service, every new consumer needs to add and modify the code. This can easily lead to bugs in code unrelated to the new consumer.
It also means that the PDF service is harder to look after because there's a lot of non-PDF code in there. A developer who needs to perform some maintenance (e.g., upgrading an out-of-date dependency) will have a tough time testing all the domain-specific behavior that the service is expected to have.
3. Automate checks to prevent disrepair
Because good shared microservices can go months or years without any active development, it's easy for them to be forgotten. You might say that this is okay—"if it's not broken, don’t fix it"—but the odds are that outdated dependencies mean latent bugs and security vulnerabilities.
New versions of libraries also often include performance improvements. In addition, by avoiding upgrades you incur "upgrade debt." It's easier to go from v5 to v6 than from v5 to v9 in a single go.
The problem is how to keep an eye on how out-of-date a service is when you're not looking at it all the time. Here are some tips:
Use a service such as Greenkeeper or a library such as npm-check to alert you when dependencies fall too far behind.
Set up a build to run npm audit (or use a service such as Snyk or the vulnerability detection offered by GitHub) to ensure that you know as soon as security vulnerabilities are discovered in your dependencies.
Alert when a service grows too much; for example, if too many lines of code are added in a short space of time, it may indicate a problem with the architecture.
Alert when a shared service logs too many errors or warnings, or returns too many 500-response codes. This is a strong indicator that the service needs some urgent attention.
4. Figure out an ownership model
If no one feels like the owner of the shared service, no one is going to look after it. But how do you figure out a sensible owner? Here are a few models to consider.
Assign the service to one person
This is an effective short-term strategy because it's very clear where the buck stops. And when one person is responsible for dealing with all the problems in a service, they're likely to take a no-nonsense approach to new development and say no to things that will make looking after the service harder.
The downside to this approach—and it's a big one—is that you create a key-person dependency, and you probably stress out the backup person when the primary person is on vacation or leaves the company.
Assign the service to a team
The team approach solves the key-person dependency problem, because the whole team shares the knowledge and the responsibility. There's also the advantage of shared care and focus.
The downside is that the team will probably not need to do any work on the shared service for a long time. In fact, most work on shared services is likely to be done by new people. That means the other team members will be slowed down by the burden of reviewing or helping with the new work, and they're unlikely to do it well if they have more pressing things on their own roadmap.
Have an informal rolling 'expert' for each shared service
In this informal approach, you deem someone who recently worked on the service as the current "expert." The person is not necessarily expected to do the work, but their recent expertise is leveraged to offer help, advice, and review.
Imagine a conversation like this: "Jane's done a lot of work on service x recently; let's ask her what she thinks." This approach means you share responsibility and avoid fatigue. The downside is that the service doesn't have a clear owner for maintenance work.
These models all have their trade-offs, but your services may benefit from one or a combination of these approaches.
Look after your shared services, and they'll look after you
Shared services are the backbone of your microservices architecture. Paying attention to how you look after them can save you a lot of headaches in the long term.
The more you pay attention, the more you'll spot opportunities for automation, architectural improvements, and ways to better manage ownership.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
