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 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


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 Reuseis 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?

Technology

ewolff team

fine eberhard wolff

organization eberhard

motivation eberhard

replaced eberhard wolff

goaleberhard wolff

communicationeberhard

agileeberhard wolff