Most common 9 patterns of microservices architecture

1. Top 9 patterns of
microservices architecture
Highlights from Martin Fowler, Sam Newman and James Lewis’s articles, talks and
Book

2. 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

3. Monolith vs microservices

4. #1 Componentization via Services
Pros
● Independently deployable
● More explicit component interface.
Cons
● Remote calls are more expensive than
in-process calls.

5. GraphiQL and Swagger vs. requirements.txt
(python example)
Components Scenario:
● 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.
Services Scenario:
● 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
response

6. #2 Organized around business capabilities.

7. #2 Organized around business capabilities.
● Siloed functional team leads
to siloed application
architecture.
● Simple changes will lead to
huge time and budget loss.
● Different priorities.
● With monolithic it’s very hard
for individuals.

8. #2 Organized around business capabilities.
● Cross-functional teams organized
around capabilities.
● End-to-end responsibility.
● Challenging to implement.

9. 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
services.
● Bottom-line it should be micro-sized responsibility.
● Check spotify’s squad, chapter tribe formation.

10. #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.

11. Challenging at scale? Not for spotify!

12. #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.

13. #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

14. #6 Decentralized Data Management
Different perspectives of same entity.
● Campaign has like 10 meaning in our
current system.
● 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
greater consistency.

15. #7 Infrastructure Automation

16. #7 Infrastructure Automation
● CI/CD
● Make it easy to do the right thing.
● If deployment is boring there isn't that
much difference between monoliths and
microservices.
● Difference between CI/CD in
monolithic and microservices
applications

17. #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.

18. This tree is having a hard time? Good because your legacy services will be migrated the same way!

19. #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.

20. Sources
https://martinfowler.com/articles/microservices.html
https://martinfowler.com/eaaDev/EventCollaboration.html
http://netflix.github.io/
https://martinfowler.com/bliki/PolyglotPersistence.html
https://martinfowler.com/microservices/
https://martinfowler.com/articles/consumerDrivenContracts.html

21. Thank you!