microservices: different from what you think...microservices = soa done right certainly true for...

Microservices: Different From What

You ThinkEberhard Wolff

@ewolffFellow

http://continuous-delivery-buch.de/

http://microservices-buch.de/ http://microservices-book.com/

http://microservices-book.com/primer.html

FREE!!!!

Microservices =SOA done right

Certainly true for some definitions…

SOA or Microservices?

?

Network traffic mightbe the same

SOA

Orchestration

UI - Portal

ServicesCRM ERP …

> Service / GUI separate

> Goal: Flexibility by service composition

> Orchestration layer

> Strategic / enterprise level

SOA

Microservices

CRM ERP

> Service / GUI might be in one microservice

> Goal: Flexibility by small service

> …and quick deployment

> Avoid layers (IMHO)

> Microservices? Decision per project

Microservices

SOA vs. Microservices

Orchestration

Portal

Services

CRM

Layer vs. Verticals?

So what are microservices?

Server Server

MicroService

MicroService

MicroService

MicroService

Link

Data Replication

RESTMessaging

Microservices areindividually deployable

modules

We know deploymentWe know modules.

There is nothing left to say.

Thank You!

Questions?

So what are modules?

Microservices make us ask fundamental

questions.

> Pretty old concept

> Modules by flow?Not ideal

Modules

1972https://blog.acolyer.org/

2016/09/05/on-the-criteria-to-be-used-in-decomposing-systems-into-modules/

> Independent development

> Comprehensibility

> Efficiency?

Modules

1972https://blog.acolyer.org/

2016/09/05/on-the-criteria-to-be-used-in-decomposing-systems-into-modules/

> By design decisions

> Encapsulating data

> Small interfaces

Modules

1972https://blog.acolyer.org/

2016/09/05/on-the-criteria-to-be-used-in-decomposing-systems-into-modules/

> By design decisions

> Small interfaces

> Encapsulating data

Modules

> Modula-2

> Algebraic Data Types

> OO classes

> …

Modules?

> Enterprise System: 1.000.000 LoC

> Class <1.000 LoC

> So >1.000 modules

Using Modules

My Brain Hurts.

Coarse-grained Modules

> By design decisions

> Small interfaces

> Encapsulating data

Coarse-grained Modules

> Example Parnas: Module for line storage

> Design decisions are fine-grained

> Probably not a good choice for coarse-grained modules

By Design Decision

Layered

iOS Android Web

Order Search Catalog

BillingCustomer

Backend Backend Backend

> Encapsulate design decision

> E.g. how orders are stored

> How Mobile client / Web App are implemented

> Backend for frontend (BFF): Custom backend services

> ...to implement frontend specific logic

> E.g. Netflix, Twitter, Zalando …

Layered

> BFF might contain the same logic –same processes

> Processes are the most relevant logic

> Changing a business process cause many changes

> …in BFF, Frontend, backend

> Lots of communication between teams and components

Layered: Issues

> Good way to build an API

> E.g. for mobile

> Might be easier to migrate into

> …if existing architecture is similar

Layered: Benefits

Self-contained Systems

Checkout Search BrowsingInvoicing

Web Web Web Web

> SCS: Autonomous web application

> Optional service API (e.g. for mobile clients)

> Includes data & logic

> No shared UI

> E.g. Otto, Kaufhof, Kühne + Nagel ...

Self-contained Systems (SCS)

> Business logic for one domain in one SCS

> Independent development: Change usually local to one SCS

> Small interfaces: Less communication between SCS

> Comprehensibility

> See http://scs-architecture.org

SCS: Benefits

> By design decisions

> Small interfaces

> Encapsulating data

Coarse-grained Modules

✓

✓

Encapsulating Data:Fine-grained Modules

Module Module

Data

Don’t allow direct access to instance variables!

Encapsulating Data

Module Module

Database

Encapsulating Data

Module Module

Database

Module Module

Database Database

Coarse-grained modules don’t share

databases.

> By design decisions

> Small interfaces

> Encapsulating data

Coarse-grained Modules

✓

✓

✓

> https://blog.acolyer.org/2016/10/17/information-distribution-aspects-of-design-methodology/

> Information distribution connections:Assumptions modules make about each other

> Changes must not violate assumptions

> Don‘t distribute too much information to keep system changeable.

> A.k.a. Information Hiding

Modules

> Don’t distribute too much information.

> It’ll be used in other modules.

> …and make software less changeable.

> How much information can we hide?

> What shall we share?

Information Hiding

Shall we share code?

> Hide code behind interfaces

> Use the module

> Not code sharing (copy/paste)

Code: Fine-grained Modules

> Fix bugs in many different place

> Decisions implemented in many places

> ...and hard to change

Redundant code:The ultimate sin

DRYDon’t

RepeatYourself

DRY in fine-grained modules?Great!

DRY in coarse-grained modules?DRY is a trade-off

Module Module Module Module

common common common common

Module Module Module Module

common abstraction

Reuse:The Holy Grailof the nineties

So where are all the reusable internal frameworks?

Using code is hard.

Reusing code is almost impossible.

But we are reusing Open Source all the time!

Create an Open Source project!

> Good code quality

> Documentation

> Model to accept contributions

Open Source

“But high quality Open Source is hard.

We just share code!”

“You only provide high quality as Open Source…

...but for colleagues low quality is OK?”

Parnas: Don’t share code!

Share interfaces

See Adrian Colyer’sblog.

Shall we share microservices?

> Shares interfaces

> Code reuse

> …enforces same technology

> ...enforces same version of dependent library

> …might cause deployment of several services

Code vs Service Reuse

Let’s assume it’s possible to reuse.

e.g. reuse a microservices

Reuse is still a tradeoff.

Module Module Module Module

common common common common

Module Module Module Module

abstraction

Module Module Module Module

abstraction

Change!

Module Module Module Module

abstractionChange!

Module Module Module Module

abstractionChange!

Impact Impact Impact

Module Module Module Module

abstractionChange!

Impact Impact Impact

Now we have reuse

…and a dependency.

Dependency not just in software!

Module Module Module Module

common abstractionChange!

Impact Impact Impact

Dependency between teams

Coordination

Meetings

Getting no real work done

Reuse is a tradeoff:

Reuse vs.Independence

Independence=Easy to change=Maintainability

> Independent development

> Comprehensibility

> Efficiency?

Modules

1972https://blog.acolyer.org/

2016/09/05/on-the-criteria-to-be-used-in-decomposing-systems-into-modules/

Shall we share deployment pipelines?

Order Process

Billing

Registration

Commit!Stage!

Automated!Acceptance!Testing!

Automated!Capacity!Testing!

Manual!Explorative!Testing!

Release!

> Independent development

> Comprehensibility

> Efficiency?

Modules

1972https://blog.acolyer.org/

2016/09/05/on-the-criteria-to-be-used-in-decomposing-systems-into-modules/

Order Process

Billing

Registration

Commit!Stage!

Automated!Acceptance!Testing!

Automated!Capacity!Testing!

Manual!Explorative!Testing!

Release!

Commit!Stage!

Automated!Acceptance!Testing!

Automated!Capacity!Testing!

Manual!Explorative!Testing!

Release!

Commit!Stage!

Automated!Acceptance!Testing!

Automated!Capacity!Testing!

Manual!Explorative!Testing!

Release!

Tests

> It is not enough to separate modules

> Independent deployment =separated tests

Order Process

Billing

Registration

ModuleContinuous

DeliveryPipeline

IntegrationTests

…

ModuleContinuous

DeliveryPipeline

ModuleContinuous

DeliveryPipeline

Production

Independent Deployment

> Not just separated tests

> Also: independent interface evolution

> Separate infrastructures (Docker containers)

> …

How Much Information is Distributed?

Distributed Information

> Interface definition

> Interface=UIREST/messagingor data replication

Hidden Information

> Technology

> Deployments

> Downtimes

> Internal architecture

Result?

> Potentially their own…

> Technologies

> Functionalities

> Architecture

> Deployment

> Release schedule

Truly independent teams

> Netflix: No

> My experience: Probably not

> Just need to understand parts of a system

> i.e. for one Use Case

Understand the Complete System?

> System /360 development

> Brooks: Give every access to the full documentation

> 10.000+ pages

> Parnas: Don’t

> Brooks 1995: Parnas was right

Not a New Idea

> Manages dependencies

> Which service/team does what?

> Defines common communication infrastructure

> Optional: Common Ops

> Very different from usual architecture

Global Architecture?

Conclusion

> SOA and Microservice:Similar on the technical level…

> ...very different on the architectural

Conclusion

Microservices areindividually deployable

modules

> …don‘t use a shared database or database schema

> …are separated by domains

Coarse-grained Modules…

> No shared code (except maybe Open Source)

> No shared database

> Independent deployment (optional)

> Independent tests (optional)

> Independent functionalities

Information Hiding

Modules - IndependenceImproved

Classic ModulesMicroservices

No shared Database � �

Separate domains � �

Deployment �

Test �

Technology �

Downtime �

Release Scheulde �

It’s really aboutdefining modules.

Microservices areindividually deployable

modules

You can also implement coarse-grained modules

differently.

> Independent development

> Comprehensibility

> Efficiency?

Modules

1972https://blog.acolyer.org/

2016/09/05/on-the-criteria-to-be-used-in-decomposing-systems-into-modules/

Thank You!

Questions?

EMail oop2017@ewolff.com to get:Slides+ Microservices Primer+ Sample Microservices Book+ Sample of Continuous Delivery Book

Powered by Amazon Lambda & Microservices