MicroservicesSOA reminded of what it

was supposed to deliver?

Jeppe Cramon - @jeppec

µService Conference London

2014

SOA or Microservices?

Better ROI, More Security, Fewer Defects, Reusable assets, Better Maintainability, More reuse, Better parallelism in development, Better scalability, Higher availability….

… building blocks that can be reused and tweaked as needed. There’s also a redundancybenefit: Should one … fail the other ones will work in the app.

Higher reusability, significant reduction of development cost, increased reliability, improved maintainability, enhanced quality…

For years no one talked about

SOAMostly because of the many failures…

Example:I've used service-oriented architecture for the better part of a decade, and I can honestly report the following …

Source: http://www.techrepublic.com/blog/tech-decision-maker/the-unfulfilled-promise-of-soa/

• I have never seen the "contract" feature of any service I've written or designed be leveraged to enable its re-use

• I have never seen a service from one system be recoupled to another• I have never seen encapsulated logic used in multiple applications

In my opinion SOA is not to

blame for the dissapointment

I believe that Microservices is a

welcome opportunity to brush off

the dust, learn form the past and

perhaps improve

Beware of

sales pitches

The fine-grained, stateless, self-

contained nature of

microservices creates decoupling

between different parts of a code

base and is what makes them

easy to update, replace, remove,

or augment.

Microservices: The resurgence of SOA principles and an alternative to the monolith

Trying hard to pretend it’s not difficult to develop distributed systems

It seems the argument is that just

by making things fine grained

We by magic achieve decoupling

Decoupled?

Source: https://qconsf.com/system/files/presentation-slides/QConSF-MicroServices-IPC-Netflix-Sudhir-2014.pptx

Monoliths are often blamed for being

the lasagna of software due to

coupling

Spaghetti in layers

So if we keep up the same

habits that resulted in messy

monolithsWhat’s makes us think that we

won’t end up with

Microservice spaghetti?

Most “Services” today are built

on top of Monoliths

Monolith A Monolith B

Monolith C Monolith D

Service A.1

Service A.2

Service A.3

Service A.4

Service B.1

Service B.2

Service B.3

Service B.4

Service D.1

Service D.4

Service D.3

Service D.2

Service C.4

Service C.3

Service C.2

Service C.1

DB DB

DB DB

Monolith A Monolith B

Monolith C Monolith D

If we create naïve

microservices

Service A.1

Service A.2

Service A.3

Service A.4

Service B.1

Service B.2

Service B.3

Service B.4

Service D.1

Service D.4

Service D.3

Service D.2

Service C.4

Service C.3

Service C.2

Service C.1

DB

DB

DBDB

DB

DB DB DB

DBDBDB

DB

DB DB

DB

DB

DB DB

DB DB

Then we’ve IMO just gone from

bad

To Worse

So does that mean that

breaking things apart is a bad

thing?

Definitely NOT!

But we need some guidelines to

avoid things becoming messy

(once again)

So how do we get there?

Let’s look at some of the

characteristics of Microservices

(that most seem to agree upon)

Microservice characteristics

• Single Responsibility Principle (SRP)

• Small

• Own process

• Valuable

• Replaceable

• Upgradeable

• Independent

• Encapsulated

• Composable

• Testable

• Fast startup/shutdown

• Client friendly

Single Responsibility Principle

(SRP)

Billing

DB

Order Fulfillment

DB

SMS Gateway

Shipping

DB

Management Reporting

DB

A Service should have a single responsibility

and

this responsibility should be entirely encapsulated within the service

Does a Microservice own its

data?• Remember layered SOA?

• IMO a service that only deals with data persistence is best called a database/datastore

• It already has a nice API– We don’t need to bubble wrap it with REST or

Async messages

• Don’t split the atom – we need cohesion as well as decoupling!

• If we want datastore abstraction (so we can swap out Postgresql with Mongo or Redis) there this little pattern called Respository.

So how big/small should a

microservice/responsibility be?

But I’ve heard that a

“Microservice should be no larger

than 100 Lines of Code!?”

Enough already!

When did we get away from solving business problems and start

talking technology, JSON over XML, REST, LoC’s, Frameworks again?

It reminds me of the early SOA

daysAll that was talked about then was which ESB

to purchase, to how set it up, etc.

No body discussed the problems that the

ESB was supposed to solve (or when it was

appropriate) or what services to build.

We were caught in technology silver bullet

again!

We kind of forgot that

SOA was about business

agilityIt was too much

“Build it and they will come”

There is value in making

things smaller

For one thing it easier to reason

about them in isolation

Going small has its advantages

Source: @aviranm

SRP

This sounds really good but what

about cross Service relationships?

Customer Orders

Products

Beware…

When we break up big things

into small pieces we invariably

push the complexity to their

interaction. Michael Feathershttps://michaelfeathers.silvrback.com/microservices-until-macro-complexity

Should we replace joins with

RPC?

Change Address Response

ConsumerChange Address Request

Provider

RPC or Request/Response - Synchronous 2 way communication

Remote Procedure Call

Request/Reply – Asynchronous 2 way communication

Consumer Provider

Change Address RequestChange Address

Request

Change Address

Reply

Change Address

Reply

Request

Channel

Reply

Channel

VS.

Size this and Size that!

Be Careful

If Microservices are good, then

Nanoservices must be even

better?

Why not one-liner services?

Nano Services

Unless we have a very reason for doing so,

we risk building services

that are so fine-grained

that their costs outweigh their utility*

*Read Arnon Rotem-Gal-Oz’s Nano Services Anti Pattern:http://arnon.me/wp-content/uploads/2010/10/Nanoservices.pdf

Microservices are valuable

The value of a microservice must

exceed the cost of building &

operating it.

Microservices entail costs for serializations, deserializations, security, communication, maintenance, configuration, deployment, monitoring,

etc.

Too small services

With too small services there’s a big risk that what’s left

of coherence goes out the window and we get:

• Communication-related and Layered coupling– E.g. Logic and persistence are not the same service

• Temporal coupling – Our service can not operate if it is unable to communicate with the

services it depends upon

• Behavioral coupling– Our services assume behaviors with regards to what and who.

– The sender/client determines what to do and knows something about

how the receiver/server should satisfy the request

Microservices == distributed

objects?

Service star chart

Service Dependencies

Source: https://qconsf.com/system/files/presentation-slides/QConSF-MicroServices-IPC-Netflix-Sudhir-2014.pptx

All these services needs to be

integrated

And often in the form of

Request/Response calls

(and often over the network – aka

RPC)

Synchronous Remote Calls

can lower our Fault tolerance• When servers crashes

• When databases are down

• When deadlocks occurs in the database– Do you retry?

With synchronous RPC style Services interaction we can easily loose business data unless we use an Orchestration engine or find another way to achieve call/retry semantics, combined with compensations and lifecycle handling.

Note: Automatic retry of calls only works if our Service operations are idempotent.

Also remember: REST isn’t

magic!

What’s less fat – XML or JSON?

• They’re equally slim and fast!

• http://balisage.net/Proceedings/vol10/html/

Lee01/BalisageVol10-Lee01.html

RPC and Distributed computing

• As soon as a service request/response

calls to another service across the

network we must adhere to the laws of

distributed computing*.

– Reliability, Latency, Bandwidth,

Transportation costs, Security

• If the other services is not available then

my service cannot conduct its business,

which minimizes my services autonomy

* See http://www.rgoarchitects.com/Files/fallacies.pdf for a walkthrough of the 8 fallacies of distributed computing

Service autonomy

Service

B

Service

C

Service

A

System X

Service

A

System Y

Service

B

Service

C

System X

Slow/unreliable network

Different SLA

Slow system

A distributed system is one where

a machine I’ve never heard of

can cause my program to fail.— Leslie Lamport

Availability goes down(without additional instances of each service)

Service A

Service B

Service C

Availability: 99% Availability: 99% Availability: 99%

Combined availability: 97%

Decide if you can live with the

consequences of coupling

services to each other using

Request/Response

Different situations – different tradeoffs

SOA was about business

agility through IT/Business

alignment

Which require maturity

• Organizational maturity

Be aware of Conways Law

“organizations which design systems ... are

constrained to produce designs which are

copies of the communication structures of

these organizations”

Teams are typically aligned with Systems/Projects and NOT with Services as I

believe they should

Which require maturity

• Organizational maturity

• Technical/operations maturity* – DevOps

– Build

– Test

– Deployment

– Monitoring

– Etc.

* See: http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html

We need a strong foundation for development to

achieve thisA

lign

me

nt

Hig

hly

alig

ned

Less

alig

ned

EffciencyLess effective Highly effective

”Maintenance Zone” ”Well-Oiled IT”

”Alignment Trap”

11%

74%

7%

8%

+13

-14

-2 -15

+11

-6

+35

”IT enabled Growth”

% of the 504 respondents % difference compared to the overall averages IT spending

Combined yearly growth-rate over a 3 year period

Sou

rce

: Bai

n A

nal

ysis

+0

To break things up

We need to understand our business and its processes

-

How is data flowing?

In order to build the right

boundaries

Claim

Most of us are trained to think in Entities and Structural models and this is where we get our selves

into trouble.

We create big entangled models and forget

about model boundaries and different consistency level requirements!

The mental capacity required to

understand big domain models

is huge

Many perspectives on data

Online Retail System

Product

Unit PricePromotional PricePromotion End Date

Stock Keeping Unit (SKU)Quantity On Hand (QOH)Location Code

PriceQuantity OrderedName

The lifecycle of the data is VERY important!

Customer

Pricing

Inventory

Sales

Management Reporting

Different perspectives on

entitiesWith in a given Domain, e.g. Retail, there will exist multiple bounded contexts/sub-domains/business capabilities such as:

– Product management– Purchase– Sales– Pricing– Inventory– Shipping– Support– Accounting– Management

Each of these lines of business have very specific and unique needs which are relevant for them alone in order to conduct their business. They might use the same name for the entities they’re interested in or they might use different names for the same logical entity.

BillingBounded

Context

Product

CatalogueBounded

Context

Shipping Bounded

Context

Sales

Bounded

Context

Inventory Bounded Context

PricingBounded

Context

Retail domain split into a

Macro architecture

What’s a macro architecture

• It’s the static/stable(r) parts of your

architecture

– Which are very costly to refactor and change

• Closely aligns business capabilities /

bounded contexts with services

DDD doesn’t enforce

problem domain and solution

domain alignment for Bounded

Contexts

Which is why I prefer to use the

term Business Capability

Service and Business Capability

alignment“The advantage of business capabilities is their remarkable level of stability. If we take a typical insurance organisation, it will likely have sales, marketing, policy administration, claims management, risk assessment, billing, payments, customer service, human resource management, rate management, document management, channel management, commissions management, compliance, IT support and human task management capabilities. In fact, any insurance organisation will very likely have many of these capabilities.”

See http://bill-poole.blogspot.dk/2008/07/business-capabilities.html

Don’t split into services too

early

Cross boundary refactoring is

costly

A Service is

• The technical authority for a given businesscapability

• It is the owner of all the data and business rules that support this business capability –everywhere

• It forms a single source of truth for that capability

• This form of business and IT alignment ensures that we can maintain service Autonomy & Encapsulation

So where does that leave

microservices?

Service and deployment

• A Service represents a logical boundary

• Logical responsibility and physical deployment of a service DOES NOT have to be 1-to-1

– It’s too constraining

– We need more degrees of freedom

– Philippe Krutchen 4+1 views of architecture: Logical and Physical designs should be independent of each other

A service needs to be deployed everywhere its data is needed

Service

Service Microservice

1..*

Is implemented by

A Service is the technical authorityof a specific Business Capabilitye.g. Sales, Shipping, Billing

Services are the implementation of business processes.Business processes can span multiple services, but there will always be a single service that is the actual authority on the business process.

Service

Service Microservice

1..*

Is implemented by

Microservices are a division of Services along Transactional boundaries (a transaction stays within the boundary of a Microservice)

Microservices are the individually logical deployable units of a Service with their own Endpoints. Could e.g. be the split between Read and Write models (CQRS) - each would be their own Microservice

Also known as Autonomous Components

Microservices are logical

deployable units

That doesn’t mean they HAVE to be deployed individually.

Design for Distribution

But take advantage of locality

Services are the corner stone

• We talk in terms of services, business capabilities and the processes/usecases they support

• Microservices are an implementation detail

• Microservices are much less stable (which is a good thing – it means they’re easier to replace)

• A microservice in one service can subscribeto events from another Service or calloperations on another Service (which again is implemented/supported by an internal microservice)

Coupling matrix*

* Modified version of Ian Robinson’s matrix: http://iansrobinson.com/2009/04/27/temporal-and-behavioural-coupling/

Behavioral

coupling

Temporal

coupling

Low High

Low

High

Event oriented Command oriented

Emergency services Distributed 3 layer

Using Business Events to drive

Business Processes

Sales Service

Shipping

Billing

Sales

CustomersB

us

Online Ordering System

Web Shop

(Composite UI)

Billing Service

Shipping ServiceOrder

Accepted

Event

AcceptOrder

Command

The sales

fulfillment

processing

can now

begin…

Cascading events give rise to

business processes

Event driven process

Sales ServiceOrder

Accepted

Billing Service

Orderfulfilment ServiceProcess Manager/

Saga/

Orchestration-Engine

Shipping Service

Online Ordering System

Bu

s

Order

Accepted

Order

Accepted

Customer

Billed

Customer

Billed

Order

Authorize

d

Order

Authorize

d

Works as a Finite

State Machine

(WorkFlow)

handling the life

cycle of Shipping

and thereby forms

a very central new

Aggregate in the

System

This form of architecture is called

an

Event Driven Architecture (EDA)

SOA and EDA are two sides of

the same coin

So are Microservices the

future?Gartners Pace layered Application strategy:

• Systems of Record — Established packaged applications or legacy home-grown

systems that support core transaction processing and manage the organization's

critical master data. The rate of change is low, because the processes are well-

established, common to most organizations, and often are subject to regulatory

requirements.

• Systems of Differentiation — Applications that enable unique company processes

or industry-specific capabilities. They have a medium lifecycle (one to three years),

but need to be reconfigured frequently to accommodate changing business practices

or customer requirements.

• Systems of Innovation — New applications that are built on an ad hoc basis to

address new business requirements or opportunities. These are typically short

lifecycle projects (zero to 12 months) using departmental or outside resources and

consumer-grade technologies.

• "These layers correspond to the notion of business leaders having common ideas,

different ideas, and new ideas,"

Conclusions

• In my opinion Microservices is one SOA delivery model

• Focus should be on aligning Services to Business Capabilities

– Make service as small as possible and as big as

necessary

• Beware of the coupling matrix – avoid synchronous

communication between services unless you’re ready to pay

the price

• Implement Services as a set of Microservices that are

logically deployable and divide them along transactional

boundaries

• Be aware of the requirements for organizational, business and

technical maturity

• If we can get there then I believe Microservices will be able to

help us achieve a some of what SOA promised, but due to

different factors rarely delivered

Thank you

Jeppe Cramon

TigerTeam

www.tigerteam.dk

www.tigerteam.dk/category/soa/

www.tigerteam.dk/category/soa/microservices/

Twitter: @tigerteamdk and @jeppec