Date post: | 26-Jul-2015 |
Category: |
Technology |
Upload: | yamen-sader |
View: | 235 times |
Download: | 1 times |
Microservices 101
The Big Why?
Yamen Sader
Sixtree Co-‐Founder
Principal Consultant Hacker !
@yaamehn #microservices
We Are Here
System
Why Are We Here?
• TradiHonal 3-‐Her ‘architecture’ to build ‘systems’
• But what is an architecture?
• And what is a system?
UI
Logic
Data
Architecture
• Defining the boundaries between components (modularisaHon) to
• minimise dependencies between components (coupling) and
• maximise cohesiveness within components
!
• Equips us to deal with CHANGE
High Cohesion
Low Coupling
High Cohesion
System• A unit of deployment and/or development and/or (most likely) purchase or commissioning
• Independent of other systems
• UI and persistence
• Development and evoluHon
• OperaHons
• Frameworks and languages
• Underlying runHme ‘process’
• Limited interacHon with other systems
Independent
Limited
Independent
Woah
Independent
Limited
Independent
High Cohesion
Low Coupling
High Cohesion
Horizontal layering (alone) is evil
System
Early ObjecHves
• This is the natural way to start building systems
• Easy to develop
• Homogenous
• Small number of concerns, so highly cohesive
• ‘Simple’
UI
Logic
Data
System
Over Time• New funcHonal concepts and concerns are added
• Has no concept of the ‘funcHonal separaHon’ of concerns
• Only decouples technical concerns
• But technical concerns change the least o^en!
• How does this architecture evolve as a ‘system’ grows over Hme?
UI
Logic
Data
UI
Logic
Data
MUD
UI
Logic
Data
CONGRATULATIONS!You have a Monolith
System
Please Don’t Ever Change• You know you have a monolith if change is slow and terrifying
• It’s slow and terrifying because:
• Each layer has very low cohesion (covers many concerns)
• Each layer depends on the layer below it (albeit abstracted) very significantly
• The ‘unit of change’ requires too big of a ‘unit of understanding’ (doesn’t fit in your head)
UI
Logic
Data
Other Concerns• Long term commitment to technology stack
• Difficult to onboard new developers
• Slow and overloaded development environment
• Slow applicaHon startup
• Difficult to conHnuously test and deploy
• Very difficult to scale applicaHon horizontally
• Difficult to scale development
• Difficult to idenHfy boelenecks and issues
• Very difficult to cleanly integrate with other systems
System
The First Step
• Admit that this horizontal layering is insufficient past a certain scale (mulHple funcHonal concerns in a fast-‐changing environment)
• The layers must create boundaries that meet the principles of architecture (modules with high cohesion and low coupling)
UI
Logic
Data
VerHcal (Domain) Slices
• This is MUCH beeer
• A change is much more likely to affect a single slice
• This can be VERY difficult to do correctly
Custom
er
Produc
t
Billin
g
System
System
Billin
g
The TrapCustom
er
Produc
tUI
Data
Yes! Great benefit to having a single, cohesive user interface
OK, let’s trust everyone to respect these boundaries
ReferenHal integrity and transacHons reintroduce coupling
System
Billin
g
The PrerequisiteCustom
er
Produc
tUI
Can you design your system without sharing the
database?
(This is the hardest part)
And now, for my next trick…
Billin
g
Custom
er
Produc
t
UI
Once reliance on a shared database between
components is removed, the system boundary becomes
arbitrary !
i.e., you can choose the most appropriate system boundary
UI
DistribuHon & Scale Becomes Possible
But not necessarily desirable…
Custom
er
Produc
t
Billin
g
Conway’s Law
OrganizaHons which design systems … are constrained to produce designs which are copies of the communicaHon structures of these organizaHons
— M Conway
Boundary
Boundary
Monolith
Monolith
No Man’s LandDomain System Organisation
Note: Organisational boundaries tend to be far more complex (domains align with business, systems align with IT, organisations cut across both)
Microservices Defined
The confluence of boundaries between the Domain Architecture, the System and OrganisaHonal
Structure
This is the only new thing
Microservices LandDomain System Organisation
This is the basis of alignment between Microservices and DevOps maturity
Drawing the rest of the owl
Let’s Take a Ride
First Law of DistribuHon
Don’t
Domain Architecture
Customer Product Billing
Draw the boxes Low rate of change
Micro Architecture
AngularJS MongoDB
JEE Oracle
NodeJS Ninjas
Build the boxes High rate of change
Macro Architecture
Monitoring
Data ReplicaHon ProtocolsMessaging
UI IntegraHon
?Service Discovery
Deployment
ReporHng
Distributed Tracing & ExcepHon Handling
The Hard Bits• UI IntegraHon & SSO
• Data IntegraHon & DuplicaHon
• Monitoring
• Deployment & Management
• Service RegistraHon & Discovery
• Developer Tooling
• Distributed ParHHoning
• (No) TransacHons
• ReporHng
• Data MigraHon
• Protocols & Standards
• Distributed Tracing & Error Handling
• Resiliency
And many more!
The (micro) elephant in the room
My Opinion
hep://www.sixtree.com.au/arHcles/2014/microservices-‐characterised/
Services with uniform interfaces
Small with a single responsibility Containerless
Organised “verHcally” along business capabiliHes
Loose coupling, favouring choreography over
orchestraHon Decentralised governance where only the interfaces
are agreedDecentralised data
management
Infrastructure is automated
Design for failure
100 to 1000 lines to code
EssenHal Why? Why??!???!?
This is not a microservice
I guess it is easier to use a new name (Microservices) rather than say that this is what SOA actually meant – re hep://t.co/gvhxDfDWLG — Arnon Rotem-‐Gal-‐Oz (@arnonrgo) March 16, 2014
Further Reading• Master Reading List: hep://www.maesHne.com/microservices
• The Big MoHvaHon: hep://www.infoq.com/presentaHons/Breaking-‐the-‐Monolith
• Asking Why: hep://genehughson.wordpress.com/2012/07/15/most_important_quesHon/
• On Architecture: hep://genehughson.wordpress.com/2012/04/04/architecture-‐versus-‐design/
• Great Series: hep://www.Hgerteam.dk/category/soa/microservices/
• Life Beyond Distributed TransacHons: hep://www.ics.uci.edu/~cs223/papers/cidr07p15.pdf
• Distributed Big Balls of Mud: hep://www.codingthearchitecture.com/2014/07/06/distributed_big_balls_of_mud.html
• Reality: heps://rclayton.silvrback.com/failing-‐at-‐microservices
• Our Thoughts: hep://www.sixtree.com.au/arHcles/tag/microservices.html