SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez nos Conditions d’utilisation et notre Politique de confidentialité.
SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez notre Politique de confidentialité et nos Conditions d’utilisation pour en savoir plus.
Top 9 patterns of
Highlights from Martin Fowler, Sam Newman and James Lewis’s articles, talks and
What’s Microservices Architecture ?
In short, the microservice architectural style is an approach to developing a single application as a suite
of small services, each running in its own process and communicating with lightweight mechanisms, often
an HTTP resource API. These services are built around business capabilities and independently
deployable by fully automated deployment machinery.
There is a bare minimum of centralized management of these services, which may be written in different
programming languages and use different data storage technologies.
-- James Lewis and Martin Fowler
#1 Componentization via Services
● Independently deployable
● More explicit component interface.
● Remote calls are more expensive than
GraphiQL and Swagger vs. requirements.txt
● Team A develops a package that wraps the
super important external API (SAPI).
● Teams B,C and D depends on this package
whenever Team A releases a new version of
the package the other *depndent* teams
should at least should change
requirements.txt and rebuild.
● Team A develops a RESTful API and Teams
B,C and D consumes this API.
● Team A is making whenever a new change
happens the swagger gets changed
automatically and end-point as backward
compatible as possible.
● Teams B,C and D should be tolerant about
#2 Organized around business capabilities.
● Siloed functional team leads
to siloed application
● Simple changes will lead to
huge time and budget loss.
● Different priorities.
● With monolithic it’s very hard
#2 Organized around business capabilities.
● Cross-functional teams organized
● End-to-end responsibility.
● Challenging to implement.
How big/small is a microservice ?
● The largest sizes reported follow Amazon's notion of the Two Pizza Team (i.e. the whole team can
be fed by two pizzas), meaning no more than a dozen people.
● The smaller size scale we've seen setups where a team of half-a-dozen would support half-a-dozen
● Bottom-line it should be micro-sized responsibility.
● Check spotify’s squad, chapter tribe formation.
#3 Products not Projects
● You build it, you run it
● Devops culture is adopted by Facebook, spoitfy and others.
● Projects are time bounded. Products are continuous activity including but not limited to
developing features, deploying, fixing and up to getting 3AM support calls.
#4 Smart endpoints and dumb pipes
● Unlike ESB simple messaging queues are prefered RabbitMQ, 0MQ and ActiveMQ.
● Choreographed using simple RESTish protocols rather than complex protocols such as
WS-Choreography or BPEL or orchestration by a central tool.
● Changing messaging protocol / rpcing in monolithic may led to more complex/chatty application
● This may be one of the main differences between SOA and microservices architecture.
#5 Decentralized Governance
● Not every problem is a nail and not every solution a hammer.
● Prefer using the right tool for the job and while monolithic applications can take advantage of
different languages to a certain extent, it isn't that common.
● Internal opensource model.
● Consumer Driven Contracts. << This is where GraphQL plays a great role.
● Tolerant Reading.
● Postel's law (Conservative about what you send. Tolerant about what your receive.)*
*=Also called the robustness principle by Jon Postel who wrote an early specification of TCP
#6 Decentralized Data Management
Different perspectives of same entity.
● Campaign has like 10 meaning in our
● Polyglot persistence
● A huge problem is data consistency and
updates (distributed transactions)
● As long as the cost of fixing mistakes is
less than the cost of lost business under
#7 Infrastructure Automation
● Make it easy to do the right thing.
● If deployment is boring there isn't that
much difference between monoliths and
● Difference between CI/CD in
monolithic and microservices
#8 Design for failure
● Applications need to be designed so that they can tolerate the
failure of services.
● Netflix's Simian Army induced failures of services and even
datacenters during the working day to test both the
application's resilience and monitoring.
● Blackout drills.
● The Circuit Breaker
● Choreography and event collaboration. The RX Era.
● sophisticated monitoring, logging setups and dashboards for
each individual service.
This tree is having a hard time? Good because your legacy services will be migrated the same way!
#9 Evolutionary design
● Usually it’ll never be microservices from day1.
● Many microservice groups expects many services to be scrapped rather than evolved in the longer
term (2 weeks replaceability).
● The Guardian website Monolith to Microservices [add new features by building microservices that
use the monolith's API]
● StranglerApplication Pattern (Killing Softly!)
● Versioning of APIs and consistency.
● Evolutionary replaceability is another organic design.