Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our User Agreement and Privacy Policy.

Slideshare uses cookies to improve functionality and performance, and to provide you with relevant advertising. If you continue browsing the site, you agree to the use of cookies on this website. See our Privacy Policy and User Agreement for details.

9 patterns of microservices

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

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

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.

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.

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.

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.