Explaining the 'What', 'Why' & 'How' of Microservice Architecture

1. October 30, 2014
Page 1

2. February 11, 2015
Page 2

3. Why a shift in
Architectural Paradigm?

4. February 11, 2015
Page 4

5. February 11, 2015
Page 5
Decomposing big
things into smaller
more manageable
chunks
Subroutines, classes,
packages, functions
are programming
constructs that help
us in providing
solutions

6. February 11, 2015
Page 6
We deploy as a
‘MONOLITH’
Huge Java EE
Container

7. Page 7
In a ‘MONOLITHIC’
application – where
is the memory leak?
Supportability
Challenges

8. February 11, 2015
Page 8
Q – In a monolithic
application - what fails
when you see
OutOfMemoryException?
Do you see isolated
or catastrophic
cascading failure?

9. February 11, 2015
Page 9
It all starts out
GREAT – but what
an entangled web
of classes we weave
?
Too BIG to fit
in developer’s
brain
Hard to ADD /
MODIFY
dependencies –
Leading to stale
stacks
Functional areas to
be regression
tested when a class
/ component
changes?
Release cycles
Maintainability
Challenges

10. Page 10
MONOLITHIC
application may
take ages to build
& deploy
Serviceability
Challenges
Availability
Challenges

11. Page 11
Impedes productivity
of teamTOO many COOKS
SPOIL the BROTH

12. What is a Micro-Service
& its implications ?

13. Page 13
The UNIX philosophy?
Write programs that
do ONE thing . . . And
does it Extremely
WELL !
Write programs that
work together
> # ! /bin/sh
> cat test.txt | tr ‘ ’ ‘n’ | sort | uniq –c | sort -rn

14. Page 14
Small
Replaceable Independent
Runs in its
own O/S
process
(daemon)
Easily
consumable
(HTTP + JSON)
Upgradeable
Encapsulation
Single
Responsibility
Principle
Forever
Young
Testable
Free of
temporal
coupling
Fast and Easy
to startup
What is a
micro-service?

15. Page 15
Complexity
Displacement
Many
processes to
manage
Operational
Complexity
More moving
parts
What are the costs of
micro-services?
Increase in
overall
memory
consumption
Latency

16. How ?

17. Page 17
Design Considerations
“Good OO Design principles are
equally applicable for the design
of micro-services”

18. Page 18
Domain Driven Design (DDD)
is complementary to
Micro-Service based architectures

19. Page 19
For brown field projects
“The hardest part is going to be
finding the seams in a monolithic
application to form the boundaries
of the micro-services”

20. Page 20
µServices working together
Avoid synchronous
RPC calls – Why?
If you still feel you
need to do this, first
ask – did I get the
BOUNDARIES right?

21. Page 21
Contd.
If you still feel you need
to do this, then consider
a circuit breaker (Netflix
Hystrix)

22. Page 22
Contd.
Prefer async
pub/sub – Why?

23. Page 23
Blueprint
Circuit Breakers
to avoid
cascading
failures
Each service
has its own
config. set and
log location
Async messaging
backbone provides
loosely coupled way
for services to work
together – Like PIPE
Each service can be
- TESTED
- VERSIONED
- RELEASED
independently
Eliminate side
effects – each
service may have
its own db
Services with a
SR providing
integration
point
Services tuned
individually –
allocate only
what they need
Each service
has its own
automated
test suite
Each service has
built in diagnostic
and performance
monitoring
capabilities
Cross Cutting
Concerns

24. Execution Considerations

25. Page 25
POLYGLOT – Be
aware of polyglut
For brown field
projects – carve off
micro services
incrementally

26. Page 26
What ? Why ?
When ? How ?

27. 27
Thank You !
shah_d_p@yahoo.com
@dhaval201279
https://in.linkedin.com/in/dhavalshah201279