Upload
eberhard-wolff
View
368
Download
0
Tags:
Embed Size (px)
Citation preview
Eberhard Wolff - @ewolff
Microservices: Definition • Small • Independent deployment units • i.e. processes / VM • Including GUI
• Any technology • Any infrastructure
Micro Service
Server
Micro Service
Server
Eberhard Wolff - @ewolff
Components Collaborate
Micro- service
Micro- service
Link
Data Replication
REST Messaging
Eberhard Wolff - @ewolff
Conway‘s Law
Architecture copies
communication structures of the organization
Eberhard Wolff - @ewolff
Order Billing Search Catalog
Order Catalog Search Billing
Team can deploy without integration Changes can be deployed independently & quickly
Strong & enforced modularization
Technology stack per Microservice One or many Microservices per Team
Synergy Microservices / Conway’s Law
Eberhard Wolff - @ewolff
DDD • Domain Driven Design • By Eric Evans
• UBIQUITOUS LANGUAGE • Code / database / user should use
the same terms for the domain model
Eberhard Wolff - @ewolff
Bounded Context • Domain model is only valid for one
context
• There is no universal data model! • See all failed SOA attempts
Eberhard Wolff - @ewolff
Order Shipping Billing
Customer
Loyalty program #
Customer
Shipping address
Customer
Credit Card #
Eberhard Wolff - @ewolff
Bounded Context & Microservice
• Microservice = Bounded Context
• Changes: local • Even for data model • Independent development
• Relationship = team collaboration
Eberhard Wolff - @ewolff
Monoliths • Architecture rot • …not maintainable any more • …and can’t be rewritten / replaced
Eberhard Wolff - @ewolff
Microservices • Distributed system of small units • Architecture violations harder
• Small units • Easy to replace
Eberhard Wolff - @ewolff
Online Shop
Elasticsearch
Spring Batch Oracle
Spring MVC MongoDB
Order
Catalog
Search
Billing
Eberhard Wolff - @ewolff
Free Choice of Technology • Use the best tool for the job
• Very hard with a monolith
• Option
• Can increase motivation
Eberhard Wolff - @ewolff
Code Reuse • Reuse across technology stacks hard • Code dependencies are evil! • Deployment dependency • No more independent deployment • Update hell
• Avoid code reuse! • Or make it Open Source projects (Netflix) • Service reuse is fine
Eberhard Wolff - @ewolff
Global Refactorings? • Move code from service to service • Might be a port to a different
language • Separate in a new service? • More services = more complex
• Hard
Eberhard Wolff - @ewolff
Functional Architecture • Teams should be independent • i.e. one team = one functionality • Otherwise: Coordination hard
• Functional architecture much more important
Eberhard Wolff - @ewolff
Start BIG • Won’t have too much code at the
start anyway • Refactoring easier • Can build architecture as you go
• Let the functional architecture grow!
Eberhard Wolff - @ewolff
1st Law of Distributed Objects • Don’t Distribute Your Objects! • Too much remote communication &
overhead • Lesson learned from CORBA etc • Microservice should include a GUI
• http://martinfowler.com/bliki/FirstLaw.html
Eberhard Wolff - @ewolff
Request
Response
Processing
Latency Round Trip: 0,2-0,5 ms = 600.000-1.500.000 instructions@3GHz
Eberhard Wolff - @ewolff
1st Law of Distributed Objects & Microservices
• Small Microservices mean a lot of communication
• Violate the 1st Law • Seems to work, though
• http://martinfowler.com/articles/distributed-objects-microservices.html
Eberhard Wolff - @ewolff
Resilience • Failures must not propagate • Timeouts • Bulkheads • Circuit Breaker • Michael T. Nygard: Release It! • Implementation: Hystrix (Netflix) • More robust than monoliths!
Eberhard Wolff - @ewolff
Authentication & Authorization • Centralized authentication • Service must authorize user • More complex than monolith
• E.g. OAuth2
Eberhard Wolff - @ewolff
Component Model • No restriction on language etc • Individual processes • + infrastructure (database etc) • JARs, WARs, EARs: No good fit
• Standardized Monitoring • Standardized Logging
Eberhard Wolff - @ewolff
Possible Component Models • Virtual machine
• Docker container
• Installable software (RPM, deb) • + deployment / config scripts
Eberhard Wolff - @ewolff
Operation • Common standards must be
enforced • Templates simplify creating new
Microservices • …avoid too large Microservices • …and support common standards
Eberhard Wolff - @ewolff
Conclusion: Microservices • Microservices are a new way of
modularization • More technological freedom • Architecture to enable scaling agile • Easier, faster and less risky
deployment
Eberhard Wolff - @ewolff
Issues • Refactoring and reuse hard
• Distributed systems
• More sources of failures
Eberhard Wolff - @ewolff
Use If… • Time to market is important • Sustained development speed • Large enough project
Eberhard Wolff - @ewolff
Don’t Use If… • Infrastructure complexity cannot be
handled • Architectural complexity cannot be
handled