The socio-technical aspects of microservices: a teaser
This article is part of the series “the socio-technical aspects of microservices”.
I’ve learned a lot about microservices in the past seven years. During that time, I helped to design, deploy and operate a handful of systems based on microservice architectures. Some of those systems turned into success stories. Others caused more trouble than they were worth.
Based on all that experience, I’ve developed a strong opinion about what working with microservices should be like.
There is so much to say about topics like resilience, security and performance. But because this is a blog about teamwork, I’m going to focus exclusively on the socio-technical aspects of microservice architectures.
It’s going to take me a while to write all the articles though, so for now I can only give you an overview of things to come.
Over the next couple of weeks, I’ll publish five articles about microservices. Each article will explore one of the following rules:
- A microservice should have exactly one owner (where owner = team).
- A microservice should be small enough to fit into your head.
- A microservice should facilitate learning.
- You should build a good relationship with teams that depend on your service.
- You should build a good relationship with teams that your service depends on.
When taken together, these five articles will outline my design goals for all systems based on a microservice architecture. I hope they can serve as a conversation starter for your team.
In the next article we’ll talk about service ownership, which I believe is the single most important aspect.