Microservice - All is Small, All is Well?

Microservices –
All is Small, All is Well?
Eberhard Wolff
Freelancer

Eberhard Wolff - @ewolff
Leseprobe:
http://bit.ly/CD-Buch

Microservice
Definition

Microservices: Definition
•  Small
•  Independent deployment units
•  i.e. processes / VM
•  Including GUI
•  Any technology
•  Any infrastructure
Micro
Service
Server
Micro
Service
Server

Components Collaborate
Micro-
service
Micro-
service
Link
Data Replication
REST
Messaging

Online Shop
Order
Catalog
Search
Billing
Customer
HTML /
HTTP

Microservice
to scale Agile

Define
architecture to
limit
communication

Microservice
Conway’s Law

Conway‘s Law
Architecture
copies
communication structures
of the organization

Order Billing Search Catalog
Order CatalogSearchBilling
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

One team can
build and
deploy features
independently!

Team must be
responsible for
a sensible set
of functionality

Microservice
Bounded
Context

DDD
•  Domain Driven Design
•  By Eric Evans
•  UBIQUITOUS LANGUAGE
•  Code / database / user should use
the same terms for the domain
model

Bounded Context
•  Domain model is only valid for one
context
•  There is no universal data model!
•  See all failed SOA attempts

Order Shipping Billing
Customer
Loyalty
program #
Customer
Shipping
address
Customer
Credit
Card #

Bounded Context &
Microservice
•  Microservice = Bounded Context
•  Changes: local
•  Even for data model
•  Independent development
•  Relationship = team collaboration

Sustainable
Development

Monoliths
•  Architecture rot
•  …not maintainable any more
•  …and can’t be rewritten / replaced

Microservices
•  Distributed system of small units
•  Architecture violations harder
•  Small units
•  Easy to replace

Free choice of
technology

Online Shop
Elasticsearch
Spring Batch
Oracle
Spring MVC
MongoDB
Order
Catalog
Search
Billing

Free Choice of Technology
•  Use the best tool for the job
•  Very hard with a monolith
•  Option
•  Can increase motivation

Refactoring &
Code Reuse

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

Code Reuse 
is an issue,
not a goal

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

Functional Architecture
•  Teams should be independent
•  i.e. one team = one functionality
•  Otherwise: Coordination hard
•  Functional architecture much more
important

Refactoring &
Code Reuse
Individual
Technology Stacks

Refactoring hard
Functional
architecture much
more important

Need to get
architecture
right first time
Architecture
evolves

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!

Distributed
System

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

Request
Response
Processing
Latency Round Trip:
0,2-0,5 ms
= 600.000-1.500.000
instructions@3GHz

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

Too small = 
too much
communication

Resilience
•  Failures must not propagate
•  Timeouts
•  Bulkheads
•  Circuit Breaker
•  Michael T. Nygard: Release It!
•  Implementation: Hystrix (Netflix)
•  More robust than monoliths!

Authentication & Authorization
•  Centralized authentication
•  Service must authorize user
•  More complex than monolith
•  E.g. OAuth2

Deploy &
Operate?

Component Model
•  No restriction on language etc
•  Individual processes
•  + infrastructure (database etc)
•  JARs, WARs, EARs: No good fit
•  Standardized Monitoring
•  Standardized Logging

Possible Component Models
•  Virtual machine
•  Docker container
•  Installable software (RPM, deb)
•  + deployment / config scripts

Operation
•  Common standards must be
enforced
•  Templates simplify creating new
Microservices
•  …avoid too large Microservices
•  …and support common standards

Conclusion

Conclusion: Microservices
•  Microservices are a new way of
modularization
•  More technological freedom
•  Architecture to enable scaling agile
•  Easier, faster and less risky
deployment

Issues
•  Refactoring and reuse hard
•  Distributed systems
•  More sources of failures

Use If…
•  Time to market is important
•  Sustained development speed
•  Large enough project

Don’t Use If…
•  Infrastructure complexity cannot be
handled
•  Architectural complexity cannot be
handled

Thank You!

Microservice - All is Small, All is Well?

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie Microservice - All is Small, All is Well?

Ähnlich wie Microservice - All is Small, All is Well? (20)

Mehr von Eberhard Wolff

Mehr von Eberhard Wolff (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Microservice - All is Small, All is Well?