Engineer @
@francmichal
www.mfranc.com
Michal Franc
ENGINEER | LEADER | SPEAKER
MicroServices!
\o/
SOA- Hey why everyone forgot about me?
Microservices are on the rise
SOA
Microservices
Microsevices are not the silver bullet
SOA was not the silver bullet
https://setandbma.files.wordpress.com/2012/05/technology-adoption.png
here
Sharing
Experience
Failures & Antipatterns
Adoption
The Monolith
Monolith in Numbers
-
120+ projects
-
Multiple products
-
one repository
-
one DB 1TB+
-
60 min deploy time
-
2-3 week release ( complex )
Transformation
More Agility
More Scale
More Availability
Monolith
Monolith
Monolith
Monolith
Microservices
Microservices
Microservices
Microservice
Microservices
in Numbers
-
120+ microservices
-
repository per service
-
5-10 minutes deploy time
-
Daily releases ( simple process )
Antipatterns
-
MicroMonolith
-
Synchronous Integration
-
One DB to rule them all
MicroMonolith
The Big Ball Of Mud
Functional
Beautiful
Mess
The Road to
Monolith
-
Complex
-
Development / Exploration
-
Changes
-
Pressure, Good Enough
- A computer program that is used will be modified
- When a program is modified, its complexity will increase, provided that one does not actively work against this.
Code Entropy
https://en.wikipedia.org/wiki/Software_entropy
Distributed - Ball of Mud
First iteration
MicroMonolith
Micromonolith was natural effect of existing habits and experience bias
"Organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations"
M. Conway
Adopting microservices requires changes in the team structure and culture
Distributed system require 'distributed' teams
Micromonolith was just part of our learning process
Fail fast but learn
Monolith First
Don't waste the opportunity
Synchronous Integration
HTTP / REST
Synchronous Problem
Underestimated
Network Layer
-
latency
-
complexity
-
debbuging
-
security
-
connectivity
Assume that there will be problems
You can't beat the nature of the network
Defensive design and coding
"Occasionally connected apps" @gregyoung
Asynchronous HTTP
Messaging
Middleman
Push
What about pull ?
Distributed Data
Denormalized snapshot
of state per service
Eventual Consistency
Transactions ?
Bringing It Together
A brief history of one product
Cached data
Static Page
No Interaction
External Dependancies
Introducing Message Bus
Be Pragmatic
Where do you need scalability?
Where do you need availability?
One DB
to rule them all
Monolithic DB
-
business logic
-
complex reports
-
business transactions
First Iteration
... Single point of failure
Natural step from monolithic DB
-
data storage type bias
-
tightly coupled services
-
non-distributed data model
Maintaining existing requirements ...
Code structure follows data model
Distributed data model will encourage distributed code
What else then ?
Good Idea?
Database per service
Multiple Databases
problems
-
data aggregation
-
joins
-
transactions
-
increased maintenance
Pragmatism
start simple
-
table per service
-
schema per service
forcing relational :(
Start Introducing
Slowly
-
Database per service
-
Database per product
-
Application Joins
Application Side Join
Summary
Microservices
Tool
Monolith
Tool
The first rule of distributed systems is don’t distribute your system until you have an observable reason to
Questions?
Thank you
@francmichal
www.mfranc.com
Micro Amsterdam
By Michal Franc
