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
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.
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
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
Microservices buys you options. they have a cost
Strongly advocate for an incremental adoption of microservices
Microservice is the oposite of a monolith: a monolith is when all functionality in a system must be deployed together.
All the code is deployed as a single process. Can be distributed systems
Good for small team/organisation
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.
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.
delivering a feature should be contain to a single team, system, service
At a bare minimum I strongly advocate the implementation of a log aggregation system as a prerequisite for adopting a microservice architecture.
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.
GCP, AWS, Azure, offer a huge array of managed services.
The best part of it is Serverless
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.
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
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
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
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
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
the use of distributed transactions in most cases proves to be hightly problematic in coordinating state change.
instead use concepts like sagas
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
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.
