The socio-technical aspects of microservices: teams that you depend on

This article is part of the series “the socio-technical aspects of microservices”.

To make your microservice architecture successful, you have to consider a lot more than the technical aspects. Unfortunately, one aspect in particular often gets overlooked: the relationships between teams.

In the previous article we already discussed the advantages of building good relationships with teams that depend on your service. But what about the teams whose services you depend on?

I would advise you to build good relationships with those teams as well, as they often reveal new opportunities for improving the overall system.

To get the most out of those relationships, supplement them with a few techniques:

Coordinate feature rollouts

New features often introduce additional access patterns. If you’ve got a large user base, you might trigger a lot of additional load for some of the services you depend on.

In the worst case, this could result in outages.

To mitigate the risk, roll out new features incrementally. Make sure to inform the other teams about your plans. Listen to any of their feedback during rollout. If things are about to go wrong, don’t be afraid to pause or even revert the rollout.

Look for ways to adopt abandoned services

As the number of microservices in your organization grows, it may be more likely for some of these services to become abandoned. That’s because teams occasionally lose the ability to maintain their services, e.g. because of a shift in priorities.

But if you depend on an abandoned service, there’ll be problems: What if the abandoned service no longer receives security upgrades? What if no one performs capacity planning? Or what if no one even knows how that service works in the first place?

In those cases it might be in your best interest to adopt the abandoned service. If you’ve got a good relationship with the owners of that service, you can ask to take over ownership of the service.

Make it easy to identify the traffic generated by your service

It can be surprisingly useful to identify all the traffic that is generated by your service. This enables the other teams to ask questions about your integration. Here’s a couple of good questions to ask, just to name a few:

• Which API endpoints does that particular service use?
• Does a particular service receive correct answers within the expected amount of time?
• Can we trace a particular failure back to its source?

You can support questions like this by adding just two additional pieces of information: client authentication and trace ids.

Design your service to tolerate faults

Because microservices are developed and deployed independently from each other, each of them could be broken at a particular point in time.

Even if the teams that you depend on are doing everything possible to keep their services operational, there are no guarantees: There might be a mistake in the software, the host machines could crash and the network might get partitioned because of a hardware failure.

If you want your microservice architecture to be fault tolerant, you need to consider those failure scenarios in your designs and think about how you would handle them.

Ideally, you would find ways to keep your own service up and running even though some of the services you depend on are unavailable.

Having a good relationship with the teams you depend on can help you with that. Together you can discuss different failure scenarios and think about ways to mitigate them.

Conclusion

When taken together, these four techniques can help you to make the most out of your relationships with other teams. None of the techniques are straightforward and they require quite a bit of additional work. However, the time spent will be well worth it.

This wraps up the series on the socio-technical aspects of microservices. In this series we’ve covered only five different aspects. This is far from complete, but I’m hoping that this series got you interested enough to start thinking about the topic on your own.

If you’ve got any new insights or questions, I’d love to hear from you!