Building Microservices: Designing Fine-Grained Systems

by Sam Newman

your service, and avoids the duplication of code required to consume the service itself.

One of the key advantages of this approach is that the same team that makes changes to the services can also be in charge of making changes to those parts of the UI.

Backends for Frontends

A common solution to the problem of chatty interfaces with backend services,

the need to vary content for different types of devices, is to have a server-side aggregation endpoint, or API gateway.

A model I prefer and that I’ve seen work well is to restrict the use of these backends to one specific user interface or application, as we see in Figure 4-10.

This pattern is sometimes referred to as backends for frontends (BFFs).

My clients often struggle with the question “Should I build, or should I buy?” In general, the advice I and my colleagues give when having this conversation with the average enterprise organization boils down to “Build if it is unique to what you do, and can be considered a strategic asset;

Many tools that enterprise organizations purchase sell themselves on their ability to be heavily customized just for you. Beware!

with your own service that provides the website to the outside world, as shown in Figure 4-11. Treat the CMS as

Most CMSes also provide APIs to allow for content creation, so you also have the ability to front that with your own service façade.

Figure 4-11. Hiding a CMS using your

Many implementations of CRM tools I have seen are among the best examples of adhesive (as opposed to cohesive) services.

The Strangler Pattern

A useful pattern here is the Strangler Application Pattern. Much like with our example of fronting the CMS system with our own code, with a strangler you capture and intercept calls to the old system.

Capturing and redirecting the original calls can become more complex in this situation, and you may require the use of a proxy to do this for you.

Avoid database integration at all costs.

Understand the trade-offs between REST and RPC, but strongly consider REST as a good starting point for request/response integration.

Prefer choreography over orc...

and the need to version by understanding Postel’s Law and usi...

Effectively with Legacy Code (Prentice-Hall), Michael Feathers defines the concept of a seam — that is, a portion of the code that can be treated in isolation and worked on without impacting the rest of the codebase.

But I would strongly advise you to chip away at these systems. An incremental approach will help you learn about microservices as you go, and will also limit the impact of getting something wrong (and you will get things wrong!).

Pace of Change

Team Structure

Security

Tangled Dependencies

This brings us to what is often the mother of all tangled dependencies: the database.

The Database

Handling problems like these is not easy, and there are many answers, but it is doable.

Example: Breaking Foreign Key Relationships

The problems around the consistency of data remain, although experience has shown that it is far easier to push out changes to configuration files than alter

I’d try to push for keeping this data in configuration files or directly in code, as it is the

Refactoring Databases by Scott J. Ambler and Pramod J. Sadalage (Addison-Wesley).

Staging the Break

Abort the Entire Operation

Then we’d also need to report back via the UI that the operation failed. Our application could handle both aspects within a monolithic

consider what we could do when we split up the application code. Does the logic to handle the compensating transaction live in the customer service, the order service, or somewhere else?

for handling distributed transactions — especially short-lived transactions, as in the case of handling our customer order — is to use a two-phase commit. With a two-phase commit, first comes the voting phase.

Data Retrieval via Service Calls

At this point you’ll be saying, “But Sam, you said having lots of programs integrating on the same database is a bad idea!” At least I hope you’ll be saying that, given how firmly I made the point earlier! This approach, if implemented properly, is a notable exception,

To start with, the data pump should be built and managed by the same team that manages the service. This can be something as simple as a command-line program triggered via Cron.

We decompose our system by finding seams along which service boundaries can emerge, and this can be an incremental approach.

that they inevitably constrain technology choice. You have to buy into a technology stack. This can limit not only the technology choices for the implementation of the service

Single Service Per Host

Platform as a Service

At the time of writing, most of the best, most polished PaaS solutions are hosted. Heroku comes to mind as being probably the gold class of PaaS.

Vagrant is a very useful deployment platform, which is normally used for dev and test rather than production.

Terraform is a very new tool from Hashicorp, which works in this space.

First, focus on maintaining the ability to release one service independently from another, and make sure that whatever

I greatly prefer having a single repository per microservice, but am firmer still that you need one CI build per microservice if you want to deploy them separately.