Microservices

Shopend has five services. The commerce service is large: it holds the catalog, the carts, and the orders.

Suppose we take the idea of SOA to its extreme. We split a system into many small services, each focused on one narrow job. We also make each service as independent of the others as we can. This design is called microservices, and each small service is a microservice. The “micro” refers to the size of each service.

What independent means

A microservice is independent in two ways.

• It is deployed on its own.
• It is owned by one small team, which writes it, releases it, and runs it.

Independence also changes how the data is kept. Shopend’s services share one database, so a change to how one service stores its data can force a change to another service that reads it. A microservice keeps its own data, and no other service can reach it. A service that needs the data asks the microservice for it, by calling one of its operations. The microservice’s team can then change how the data is stored without telling any other team, as long as the operations stay the same.

In practice, the line between SOA and microservices is blurry. There is no size at which a service becomes small enough, and many systems described as microservices still share a database.

What microservices gain

Recall the four consequences of a deployment boundary: failure, change, capacity, and ownership. Change and ownership are the two kinds of independence above. The other two also apply to each microservice separately. A bug takes down one microservice, not the whole system, as long as the services that call it are written for the case where it does not respond. And we can add instances of a busy microservice without adding instances of the others.

What microservices cost

The costs come from the same independence.

• Many more calls go over the network. One request from a client can pass through many services, and each call can be slow or fail.
• One operation can change data that belongs to several microservices, and no single transaction can cover all of them.
• To run hundreds of services, we need more tools: a way for one service to find another, a way to follow one request across many services, and a way to deploy and watch them all.
• If adding one feature means changing and releasing five microservices together, the system has the costs of microservices without their independence. This is called a distributed monolith.