Download - Microservice Architecture
October 30, 2014
Page 1
February 11, 2015
Page 2
Why a shift in Architectural Paradigm?
February 11, 2015
Page 4
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
February 11, 2015
Page 6
We deploy as a ‘MONOLITH’
Huge Java EE Container
Page 7
In a ‘MONOLITHIC’ application – where is the memory leak?
Supportability Challenges
February 11, 2015
Page 8
Q – In a monolithic application - what fails when you see OutOfMemoryException?
Do you see isolated or catastrophic cascading failure?
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
Page 10
MONOLITHIC application may take ages to build & deploy
Serviceability Challenges
Availability Challenges
Page 11Impedes productivity of teamTOO many COOKS
SPOIL the BROTH
What is a Micro-Service & its implications ?
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
Page 14
SmallReplaceable Independent
Runs in its own O/S process (daemon)
Easily consumable (HTTP + JSON)
Upgradeable
EncapsulationSingle Responsibility Principle
Forever Young
Testable
Free of temporal coupling
Fast and Easy to startup What is a
micro-service?
Page 15Complexity Displacement
Many processes to manage
Operational Complexity
More moving parts
What are the costs of micro-services?
Increase in overall memory consumption
Latency
How ?
Page 17
Design Considerations
“Good OO Design principles are equally applicable for the
design of micro-services”
Page 18
Domain Driven Design (DDD)is complementary toMicro-Service based architectures
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”
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?
Page 21
Contd.
If you still feel you need to do this, then consider a circuit breaker (Netflix Hystrix)
Page 22
Contd.
Prefer async pub/sub – Why?
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
Execution Considerations
Page 25
POLYGLOT – Be aware of polyglut
For brown field projects – carve off micro services incrementally
Page 26
What ? Why ?
When ? How ?
27Thank You !
@dhaval201279
https://in.linkedin.com/in/dhavalshah201279
