Building Microservices: Designing Fine-Grained Systems

by Sam Newman

The concept of continuous delivery showed how we can more effectively and efficiently get our software into production,

Domain-driven design. Continuous delivery. On-demand virtualization. Infrastructure automation. Small autonomous teams.

Microservices are small, autonomous services that work together.

Cohesion — the drive to have related code grouped together

“Gather together those things that change for the same reason, and separate those things that change for different reasons.”

Jon Eaves at RealEstate.com.au in Australia characterizes a microservice as something that could

be rewritten in two weeks, a rule of thumb that makes sense for his particular context.

the smaller the service, the more you maximize the benefits and downsides of microservice architecture. As

These services need to be able to change independently of each other, and be deployed by themselves without requiring consumers to change.

The golden rule: can you make a change to a service and deploy it by itself without changing anything else?

For example, for a social network, we might store our users’ interactions in a graph-oriented database to reflect the highly interconnected

nature of a social graph, but perhaps the posts the users make could be stored in a document-oriented data store,

with microservices, we can build systems that handle the total failure of services and degrade functionality accordingly.

Organizational Alignment

orgnaztion algnmennt owner of microservixe

We also know that smaller teams working on smaller codebases tend to be more productive.

We can also shift ownership of services between teams to try to keep people working on one service colocated.

Optimizing for Replaceability

there is a lack of good consensus on how to do SOA well. In

So you should instead think of microservices as a specific approach for SOA in the same way that XP or Scrum are specific approaches for Agile software development.

No Silver Bullet

as we know so little about what good looks

like.

Thus, our architects need to shift their thinking away from creating the perfect end product, and instead focus on helping create a framework in which the right systems can emerge, and continue to grow as we learn more.

we should think of our role more as town planners than architects for the built environment.

He does not say, “build this specific building there”; instead, he zones a city.

We cannot foresee everything that will happen, and so rather than plan for any eventuality, we should plan to allow for change by avoiding the urge to overspecify every last thing.

They need to ensure that the system is

fit for purpose now, but also a platform for the future.

As architects, we need to worry much less about what happens inside the zone than what happens between the zones.

Your inclination to let teams pick the right tool for the job may be tempered by the fact that it becomes harder to hire people or move them between teams if you have 10 different technology stacks to support.

Netflix is an extreme example, where scale is likely the strongest overriding factor, but you get the idea.

“be worried about what happens between the boxes, and be liberal in what happens inside.”

Making decisions in system design is all about trade-offs,

Strategic goals should speak to where your company is going, and how it sees itself as best making its customers happy. These will be high-level goals, and may not include technology at all. They

Principles are rules you have made in order to align what you are doing to some larger goal, and will sometimes change.

Our practices are how we ensure our principles are being carried out.

They are a set of detailed, practical guidance for performing tasks.

You might choose to adopt a push mechanism, where each service needs to push this data into a central location. For your metrics this might be Graphite, and for your health it might be Nagios.

For example, you might want to mandate the use of circuit breakers.

Our technical vision exists for a reason. If we deviate from this reason, it might have a short-term benefit but a long-term cost.

If you are working in an organization that places lots of restrictions on how developers can do their work, then microservices may not be for you.

Part of what architects need to handle is governance.

governance is about ensuring what we are building matches this vision, and evolving the vision if needed.

They need to make sure as well that these principles don’t require working practices that make developers miserable.

With microservices, on the other hand, we have multiple autonomous codebases that will have their own independent lifecycles.

Governance Ensure that the system being implemented fits the technical vision

the win! What Makes a Good Service?

want you to focus on two key concepts: loose coupling and high cohesion. We’ll

When services are loosely coupled, a change to one service should not require a change to another.

This also means we probably want to limit the number of