About ME
❖ Python Dev @ tinyclues
❖ DevOps
❖ @lothiraldan
Slide 3
Slide 3 text
No content
Slide 4
Slide 4 text
From monolith…
Slide 5
Slide 5 text
To microservices
Slide 6
Slide 6 text
History
❖ Starts in ~2012 / 2013
❖ A synchronized evolution
❖ Helped by cloud evolution
❖ Pioneers: James Lewis from ThoughtWorks and Adrian
Cockcroft from Netflix
❖ Advocators like Martin Fowler from ThoughtWorks
Slide 7
Slide 7 text
Who uses it
❖ Heavy user
❖ Unknown number of services
❖ ~100-150 service called/page
❖ Pioneer
❖ Open-Source and blog a lot!
❖ ~800 services
❖ ~6 service called/api call
Slide 8
Slide 8 text
Example
User management service
Slide 9
Slide 9 text
Small
Simple composant Easy to understand
Easy to maintain
Small team
Slide 10
Slide 10 text
Single Responsibility
Do one thing Do it well
Easy to test
Unix way
Slide 11
Slide 11 text
Black-box
Expose a contract What it does
What it returns And the format
Slide 12
Slide 12 text
Isolation
Communicate over
Network
No data leak through
layers
Slide 13
Slide 13 text
Scaling
Easier to scale IF STATELESS
Slide 14
Slide 14 text
Best language
Choose the best tool And change it later
Slide 15
Slide 15 text
Best datastore
Polyglot persistence Easier to change
Slide 16
Slide 16 text
Microservices
❖ Fight against two inhibitors:
❖ Coupling
❖ Entropy
❖ To ease innovation and agility
Slide 17
Slide 17 text
Challenges Not so fast
Slide 18
Slide 18 text
Challenges
❖ Service discovery
❖ Performance overhead
❖ ACID, availability
❖ Links
❖ Asynchronism
❖ Value by service composition
❖ Distributed system
Slide 19
Slide 19 text
Communication
?
Slide 20
Slide 20 text
Two patterns
❖ Request / Response
❖ Publish / Subscribe
Slide 21
Slide 21 text
Request / Response
Slide 22
Slide 22 text
Publish / Subscribe
EVENT
Slide 23
Slide 23 text
HTTP
REST
Slide 24
Slide 24 text
HTTP
❖ Simple
❖ Knowledge of scaling, load-balancing and securing
❖ Support for every language
❖ Basic protocol, so REST is often used
Slide 25
Slide 25 text
MQ
MQ
Slide 26
Slide 26 text
Message Queue
❖ Simplify the architecture
❖ Middleware for every message
❖ Need to be made High Available
Slide 27
Slide 27 text
Choice
❖ Internal competences
❖ Needs for performance
❖ One choice per pattern
❖ Starts with HTTP, use MQ for events
❖ P2P vs centralized
Slide 28
Slide 28 text
Service discovery
?
Slide 29
Slide 29 text
Service discovery
❖ How to find a peer?
❖ How to detect new peer or leaving peers?
Slide 30
Slide 30 text
Service discovery solution
❖ ZooKeeper
❖ Consul
❖ Etcd
❖ Eureka
Slide 31
Slide 31 text
ACID / Availability
❖ ACID is hard to ensure in a distributed system
❖ Occasion to define which service need ACID or not
❖ The number of view might not, the billing yes definitely
Slide 32
Slide 32 text
Links
❖ No more DB joins
❖ Need to switch to applications links
❖ Think about graph
❖ Links are explicitly costly
❖ Play with services boundaries
Slide 33
Slide 33 text
Asynchronism
❖ With more communication, harder to stay synchronous
❖ For a query, may require collaboration of severals micro-
services
❖ Difficulties with HTTP
❖ Mandatory for event-driven reactions
Slide 34
Slide 34 text
Value by composition
❖ « dumb-pipe, smart endpoint »
❖ Some value is made by service composition
❖ Harder to visualize and think about
❖ Need tooling and design upfront
Slide 35
Slide 35 text
Distributed system
❖ Everything is a distributed system
❖ In monolith, easy to forget
❖ Network is not resilient
❖ Design for failure
❖ https://blogs.oracle.com/jag/resource/Fallacies.html
Slide 36
Slide 36 text
-Conway’s law
« organizations which design systems ... are
constrained to produce designs which are copies of
the communication structures of these
organizations »
Slide 37
Slide 37 text
Traditional organisation
Slide 38
Slide 38 text
Cross-Functionial organisation
Slide 39
Slide 39 text
Organisation
❖ Each team should manage the service lifetime from
value definition to production and maintenance, « you
build it, you run it »
❖ Require cross-functional teams
❖ Amazon’s Two Pizza Team (i.e. the whole team can be
fed by two pizzas)
Slide 40
Slide 40 text
Prerequisites Don’t shoot
yourself
Slide 41
Slide 41 text
Prerequisites
❖ Infrastructure
❖ Deployment, monitoring, reporting, debugging
❖ Feature re-splitting or refactoring is hard
❖ New design methods, DDD, bounded contexts
Slide 42
Slide 42 text
MicroServices VS
Monolith Fight!
Slide 43
Slide 43 text
Monolith defenders
❖ Most companies don’t need micro-services
❖ Etsy, Facebook architecture are monolith at scale
❖ Focus on internal architecture first
Slide 44
Slide 44 text
Why not both?
Slide 45
Slide 45 text
When to micro-services
Slide 46
Slide 46 text
MicroServices & Monolith
❖ How to evolve?
❖ Keep legacy monolith
❖ New features as services
❖ Static, safe and legacy core
❖ Update on just one micro-service
Slide 47
Slide 47 text
Micro-services VS SOA
❖ « dumb-pipe, smart endpoint »
❖ Micro-Services = SOA + DevOPS
❖ MicroServices done right
❖ Share service orientation
Slide 48
Slide 48 text
Community
❖ More and more literature
❖ More and more open-source projects
❖ Document and explicit traps and challenges.
Slide 49
Slide 49 text
To continue
❖ API / Rest interface
❖ Container based deployment
❖ Good companion of DevOps / Lean / Agile
Slide 50
Slide 50 text
Conclusion
❖ Micro-services offer new leads to beat entropy
❖ But it’s not free
❖ Requires discipline and maturity