Micro Services - Neither Micro Nor Service

Micro Services Neither Micro nor Service?

Eberhard Wolff Freelancer

Head Technology Advisory Board adesso AG

http://ewolff.com

Eberhard Wolff - @ewolff

Architecture of Enterprise

Java Apps




How can I implement a

new feature???

Eberhard Wolff - @ewolff L


ECommerce System

Spring & OSGi

New Stuff


New Stuff Spring & OSGi

New Stuff

ECommerce System


HTTP

New Stuff

Links

No legacy code Any technology

J Small code base

Little programs are delightful to write in

isolation, but the process of

maintaining large-scale software is always

miserable.

Jaron Lanier

Friedenspreis des deutschen Buchhandels


Micro Services: Definition •  Small •  Independent deployment units •  i.e. processes

•  Any technology •  Any infrastructure

Micro Service

Server

Micro Service

Server


Components Collaborate

Micro Service

Micro Service

Link

Data Replication

REST Messaging


Why Micro Services? •  Strong modularization •  Small deployment units •  Faster & easier deployment •  Continuous Delivery •  Less risk in deployment •  Choose best technology for each

service


Micro Service =

Micro?


10-100LOChttp://yobriefca.se/blog/ 2013/04/28/micro-service-architecture/

Smaller modules =better


10-100LOChttp://yobriefca.se/blog/ 2013/04/28/micro-service-architecture/

Smaller modules =better


Game of Life


life←{ ⍝ John Conway's "Game of Life". ↑1 ⍵∨.∧3 4=+/,¯1 0 1∘.⊖¯1 0 1∘.⌽⊂⍵ ⍝ Expression for next generation. }

Game of Life in one line of APL

dyalog.com LOC is really a bad metric


Larger? •  Micro Services have an overhead

•  Build & deployment pipeline

•  Version control


1st Law of Distributed Objects •  Don’t Distribute Your Objects! •  Too much remote communication &

overhead •  Lesson learned from CORBA etc

•  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 & Micro Services

•  Small Micro Services 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

Eberhard Wolff - @ewolff L


Again: Why Micro Services?


The main reason


How to scale agile?

Implement more feature


Conways Law

Architecture copies

communication structures of the organization


Conway’s Law as a Limit •  Won’t be able to create an

architecture different from your organization

•  I.e. mobile, GUI & database team •  Three technical artifacts


Conway’s Law as an Enabler •  Desired architecture =

project structure •  Team for each Micro Service •  Team should be responsible for

meaningful features •  Ideal: Independent features


On team can build and

deploy features –

independently!


Micro Services must provide a sensible set of functionality


Conway’s Law & Size •  Upper limit: What a (small) team

can handle

•  …and a meaningful set of features •  Probably not too small •  Lower limit: Depends on overhead /

technology


Micro Service = Micro? •  Size doesn’t matter too much

•  Teams must be able to work independently

•  Small enough for one team •  Not too much overhead


Micro Service =

Service?


Micro Services=

SOA?


Service? unassociated

loosely coupled units of functionality

that are self-contained (Wikipedia, SOA)


SOA

CRM Order

Service

Service

Service

Service

Service

Service

Service

Service

Portal / Web

Integration


SOA •  Enterprise wide effort •  Services provided by different

organizational units •  Large monolithic deployments •  …offer multiple services •  Enterprise-wide integration •  Portal / Web as universal GUI for all

services


SOA Service •  Just one interface of a large

monolith

•  No GUI

•  Different projects for different services


Micro Services CRM

Forecast

Mass EMailing

Reporting

Web Tracking

Integration


SOA vs. Micro Services •  Technology: Similar •  i.e. integration

•  But: Smaller deployment units


Micro Services just structure the application

Like JARs etc.


GUI for Micro Services •  Meaningful features will need a GUI •  Customer talks to one team for GUI

& logic •  Less communication •  1st Law of Distributed Objects


SOA •  Enterprise wide

effort •  Services provided

by different organizational units

•  Large monolithic deployments

•  …offer multiple services

•  Just one project

•  Services provided by one team

•  Small deployments •  …offer one service

each

Micro Services


SOA •  Enterprise wide

integration

•  Portal / Web as universal GUI for all services

•  Just one project •  Each

component has its own GUI

Micro Services


Conclusion


Conclusion: Micro Services •  Micro Services are a new way of

modularization •  More technological freedom •  Easier, faster and less risky

deployment


Conclusion: Micro •  Size not too important

•  Meaningful set of features

•  Smaller than SOA services


Conclusion: Service •  Modules of an application •  Include GUI •  Provide not just an interface to call

•  Structure one project •  …not the Enterprise IT


Thank You!