# Growing Pains
## More Services, More Pain
When exactly problems will occur with a microservice architecture is related to a multitude of factors. The complexity of service interactions, size of the organization, number of services, technology choices, latency, and uptime requirements are just a subset of the forces that can bring forth pain, suffering, excitement, and stress.

- The sorts of problems that arise in a company with ten services tend to be quite different from the ones seen at a company with hundreds of services.
- The number of services seems to be as good a measure as any for indicating when certain issues are most likely to manifest themselves.

*Don’t think of adopting microservices as flipping a switch; think about it as turning a dial.As you turn that dial, and have more services, you’ll hopefully have more oppor‐ tunity to get the good stuff out of microservices.*

## Ownership at Scale
Martin Fowler has previously differentiated different types of ownership from the point of view of generic code ownership, and the author find that, broadly speaking, they work within the context of microservice ownership too.
1. Strong code ownership
- All services have owners. If someone outside that ownership group wants to make a change, they have to submit that change to the owners, who decide whether it is allowed. The use of a pull request for people outside the ownership group is one example of how this could be handled.
3. Weak code ownership
- Most, if not all, services are owned by someone, but anyone can still directly change their modules without resorting to the need for things like pull requests. Effectively, source control is set up to still allow anyone to change anything, but there is the expectation that if you change someone else’s service, you’ll speak to them first.
5. Collective code ownership
- No one owns anything, and anyone can change anything they want.
### How Can This Problem Show Itself?
- I’ve seen collective code ownership be disastrous for a microser‐ vice architecture. One fintech company I spoke to shared stories of a small team experiencing rapid growth, moving from 30–40 developers to over 100, but without any assigned responsibilities for different parts of the system or any concept of own‐ ership other than “people know what is right.”
- What emerged was no clear vision for the system architecture as it evolved, and a horribly tangled “distributed monolith.” One of the developers there referred to their architecture as “colander architecture” because it was so full of holes—people would just “punch a new hole” whenever they felt like it by exposing data or just making lots of point-to-point calls.1 The reality is these sorts of challenges are easier to fix with a monolithic system, but far harder with a distributed system—the cost of detangling a distributed monolith is much higher.
### When Might This Problem Occur?
- For many teams starting out small, a collective code ownership model makes sense.
- For teams experiencing fast growth, a collective ownership model is problematic. The issue is that for collective ownership to work, you need time and space for the con‐ sensus to emerge, and be updated as new things are learned. This becomes harder with more people in general, and really hard if you’re hiring new people at a rapid pace
### Potential Solutions
**Strong code ownership**
- It becomes easier for the rules of what consti‐ tutes a good change to be decided by each team; you can view each team as adopting collective code ownership locally
- This model also allows for product-oriented teams; if your team owns some services, and those services are oriented around the business domain, then your team becomes more focused on one area of the business domain.
## Breaking Changes
A microservice exists as part of a wider system. It either consumes functionality pro‐ vided by other microservices, exposes its own functionality to other microservice consumers, or possibly does both. With a microservice architecture, we are striving for independent deployability, but for that to happen, we need to make sure that when we make a change to a microservice we don’t break our consumers.
### How Can This Problem Show Itself?
- The worst occurrence of this issue is when you see production outages caused by new microservices being sent live which break compatibility with existing services
- Orchestrate simultaneous deploy‐ ments of multiple services together
### When Might This Problem Occur?
**Development is spread across more than one team**
- Within a single team, people tend to be a bit more aware when they make breaking changes, partly because there is a good chance the developers work on both the service being changed and the consum‐ ing service
- When you get into situations where one team is changing a service that is then consumed by other teams, this problem can come up more often.
### Potential Solutions
**Don’t break contracts.**
- Eliminate accidental breaking changes.
- Do not break the formal structure and semantic
- Think twice before making a breaking change
- Trying to support old methods, resources, topics, .. when adding a new one
- Give your consumers time to migrate.