Building Microservices


What are Microservices?

independently releaseble services

Microservices avoid the use of a shared databases in most circumstance. Instead, each microservice encapsulate it's own database where required.

Microservice embrace the concept of information hiding. (expose only what is necessary)

Goal is to enable independent releasability of functionality

Key concepts
Independent deployability

the most important concept: deploying and releasing changes to a single microservice into production shouldn't imply to deploy anything else. Independent deployability is a forcing function to good design → help to define boudaries of microservices.

Modeled around a business domain

make cross-service change as infrequente as possible.

making services end to end slices of business fucntionality.

prioritize high cohesion of business functionality of high cohesion of technical functionality

Owning there own state

Avoid the use of shared databases at all cost

clean delimitation between internal implementation detail and external contract for a microservice.

Analog to object oriented programing and encapsulation of data

need to be easy to understand and manegable
as small interface as possible
decoupling is more important that small size

Microservices buys you options. they have a cost

Strongly advocate for an incremental adoption of microservices

Alignement of architecture and organisation
organisation witch design systems are constrained to produce designs witch are copies of the communication structures of theses organisation.
Bad organisation: frontend team ; backend team ; database team
Good organisation: Stock team; purchase flow team ; customer profile team.
In short, structure your teams per user benefit not based on technical boundaries.
Microservices can help that
A stream aligned team is a team aligned to a single, valuable stream of work, empowered to build and deliver customer value as quickly, safly and independently as possible. without requiring hand offs to other teams to perform parts of the work.
The monoliths

Microservice is the oposite of a monolith: a monolith is when all functionality in a system must be deployed together.

The single process monolith

All the code is deployed as a single process. Can be distributed systems

Good for small team/organisation

The modular monolith

Each module can be worked on independntly but all still need to be combined together for deployement.

Good when module boundaries are well defined, it allows some paralel work.

The distributed monolith

Multiple services, but for whatever reason, the entire system must be deployed together.

They have the disadventages of a distrubuted system, AND the disadvanteages of a single process monolith.

Seemingly innocent changes that appear to be local in scope, break other parts of the system.

Monoliths and delivery contention

delivering a feature should be contain to a single team, system, service

Monolith advantage
single process monolith great huge benefit:
much easier to deploy, control workflow, monitoring, troubleshoot and end to end testing
Simplify code reuse withing the boudary of the monolith
Monolith is not a bad thing, and should be the default option.
Look for a reason to use microservices rather than for reason not to use them
Enabling technology
Log aggregation and distributed tracing

At a bare minimum I strongly advocate the implementation of a log aggregation system as a prerequisite for adopting a microservice architecture.

Container and kubernetes

Container help to run each microservice in isolation

Running your own kubernetes cluster can be a significant amount of work!


We still need to find ways to share data between microservices

Apache Kafka has become the de facto choice for streaming dat in a microservice environement for good reason.

Public Cloud and serverless

GCP, AWS, Azure, offer a huge array of managed services.

The best part of it is Serverless

Advantage of microservices
Technology heterogenity

can use the best stack for each service

some compagny decide to restrain that to avoid overhead


Bulkhead: A component of the system may fail, but failure doesn't cascade

Be carefull: need to understand the new sources of faillure that distributed system have to deal with. (network faillure, machine faillure) Microservice can be more fragile.

Large monolith: everything as to scale together.
Smaller service, allow to scale sub part independently
Ease of deployment

one line change of a million line monolithic application requires the entire application to be deployed in order to release the change.

With microservice: you can deploy a feature independently of of the rest of the system

Organizational Alignement

small codebase and small team can be more productive

microservice helps to align between architecture and organisation


microservices can be consumed by different ways: web, native, mobile, goal is to work on user engagment

Microservices pain points
Developer experience

difficult to deploy everything on a laptop

extreme solution: developing in the cloud, feedback cycle can suffer greatly

Limiting the scope of wht a developper is supose to work with is a simplier approach, but problematic if distributed ownership

Technology overload

It gives options, but you don't have to use them all!

Time spent on tech is not time spent on something else

most of time you should understand data consitency, latency, service modeling


Are microservice a way to drive more profit? perhaps

Are microservice a way to reduce costs? Not so much


With a monolithic system, you typically have amonolithic database witch make things easier for reporting

you might simply need to publish data from your microservice into a central reporting database

Monitoring and trouble shooting

less easy than in a monolithic app

See "Distributed system observability" by cindy sridharan to addess that


potentialy more surface for data to be observed in transit


The larger the scope of the test, the longer it run, the harder it is to understand what is broken when it fail

end to end test are more problematic to write and maintain than smaller scope user unit test, but often this is worth it, because we want the confidence that comes from having an end to end test use our systems in the same way a user might.

diminuing return on testing in microservice architecture

need new kind of test, like contract testing and in production testing, paralel run and canary testing.


Information that previously flowed within only a single process now needs to be serialized, transmitted and desirialized over networks. All of this can result in worsening latency of your system.

It is difficult to measure the exact impact on latency of operations at the design and coding pahse

migrate to microservice in an incremental fashion

make small change and measure impact, test end to end.

Distributed tracing tools like jaeger can help

Data consistency

the use of distributed transactions in most cases proves to be hightly problematic in coordinating state change.

instead use concepts like sagas

Should I use microservice?
Whom they might not work for

often a bad choice for brand new products or startups

the domain you are working with is changing fast as you iterate. the shift in domain model will turn in more change being made to service boudaries and coordinate changes between services boudaries is expensive

microservice allow to scale, but often startup will pivot before scaling

the small the team, the more the cost of microservice will be.

I'm very hesitant to suggest microservices for teams with just a handful of developers.

for a small team a microservice architechture can be difficult to justify because there is work required just ot handle the deployment and management of the microservice themselves. (the microservices tax)

Much easier to move to microservice later when you know what the pains points are.

Make things harder to deploy somewhere else

Where they work well

it allows more developer to work on the same system without getting in each other way

Get your architecture and organizational boundaries right and you allow more people to work independently

SaaS app are a good fit in general. Theses product are supposed to run 24-7 witch create challenges when it comes to rolling out changes. Independant releasability of microservice is a huge releif in this case. Can scale up and down easily

Tech agnostic, so you can get the most out of cloud plateform.

FaaS platform can drastically reduce the amount of operational overhead

easier when goal is to create user experience thru lot of various interactions mecanisms

Above all, a microservice architecture is one that can give you a lot of flexibility. it as a cost, but if you want to keep your options open regarding changes you might want to make in the future.