Download - Microservices 101 - The Big Why?
![Page 1: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/1.jpg)
Microservices 101
The Big Why?
![Page 2: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/2.jpg)
Yamen Sader
Sixtree Co-‐Founder
Principal Consultant Hacker !
@yaamehn #microservices
![Page 3: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/3.jpg)
We Are Here
![Page 4: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/4.jpg)
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
![Page 5: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/5.jpg)
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
![Page 6: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/6.jpg)
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
![Page 7: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/7.jpg)
Woah
Independent
Limited
Independent
High Cohesion
Low Coupling
High Cohesion
![Page 8: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/8.jpg)
Horizontal layering (alone) is evil
![Page 9: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/9.jpg)
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
![Page 10: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/10.jpg)
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
![Page 11: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/11.jpg)
UI
Logic
Data
MUD
UI
Logic
Data
![Page 12: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/12.jpg)
CONGRATULATIONS!You have a Monolith
![Page 13: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/13.jpg)
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
![Page 14: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/14.jpg)
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
![Page 15: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/15.jpg)
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
![Page 16: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/16.jpg)
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
![Page 17: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/17.jpg)
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
![Page 18: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/18.jpg)
System
Billin
g
The PrerequisiteCustom
er
Produc
tUI
Can you design your system without sharing the
database?
(This is the hardest part)
![Page 19: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/19.jpg)
And now, for my next trick…
![Page 20: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/20.jpg)
Billin
g
Custom
er
Produc
t
UI
![Page 21: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/21.jpg)
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
![Page 22: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/22.jpg)
UI
DistribuHon & Scale Becomes Possible
But not necessarily desirable…
Custom
er
Produc
t
Billin
g
![Page 23: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/23.jpg)
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
![Page 24: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/24.jpg)
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)
![Page 25: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/25.jpg)
Microservices Defined
The confluence of boundaries between the Domain Architecture, the System and OrganisaHonal
Structure
This is the only new thing
![Page 26: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/26.jpg)
Microservices LandDomain System Organisation
This is the basis of alignment between Microservices and DevOps maturity
![Page 27: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/27.jpg)
Drawing the rest of the owl
![Page 28: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/28.jpg)
Let’s Take a Ride
![Page 29: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/29.jpg)
First Law of DistribuHon
Don’t
![Page 30: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/30.jpg)
Domain Architecture
Customer Product Billing
Draw the boxes Low rate of change
![Page 31: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/31.jpg)
Micro Architecture
AngularJS MongoDB
JEE Oracle
NodeJS Ninjas
Build the boxes High rate of change
![Page 32: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/32.jpg)
Macro Architecture
Monitoring
Data ReplicaHon ProtocolsMessaging
UI IntegraHon
?Service Discovery
Deployment
ReporHng
Distributed Tracing & ExcepHon Handling
![Page 33: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/33.jpg)
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!
![Page 34: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/34.jpg)
The (micro) elephant in the room
![Page 35: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/35.jpg)
![Page 36: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/36.jpg)
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??!???!?
![Page 37: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/37.jpg)
This is not a microservice
![Page 38: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/38.jpg)
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
![Page 39: Microservices 101 - The Big Why?](https://reader034.vdocument.in/reader034/viewer/2022052700/55b503c3bb61eb41768b483d/html5/thumbnails/39.jpg)
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