mucon 2017: a not so(a) trivial question by tareq abedrabbo

A Not SO(A) Trivial Question!

Tareq Abedrabbo - MuCon 7/11/2017

Agenda

• Motivation

• SOA vs Microservices

• Design: anti-patterns and recommendations

About Me• CEO/Consultant at OpenCredo

• Background

• SOA

• Spring-WS

• Microservices

Motivation

Background

• Some organisations are starting greenfield microservices projects

• A few are trying to evolve preexisting platforms

• Many of these organisations have a SOA heritage

Microservices =

SOA done right ?

What is SOA?

“A service has four properties according to one of many definitions of SOA:

1.It logically represents a business activity with a specified outcome. 2. It is self-contained. 3. It is a black box for its consumers. 4. It may consist of other underlying services.”

In reality SOA is also….

➡ An architectural style and design patterns

➡ Data models and patterns

➡ Technology and tools (ESBs, GUIs)

➡ A collection of specifications (SOAP, WS-*)

The SOA Heritage

✓ Approach & design

✓ Technology selection

✓ Team organisation

“Those who cannot remember the past are condemned to repeat it”

SOA vs

Microservices

Reuse vs

Managing change

Vendor-driven viewvs

Broad system view

Integrationvs

Composition

Technical reusevs

Functional reuse

Staticvs

Dynamic

Organisational silosvs

Collaborative teams

Design

Some anti-patterns

Example 1: The Distributed Monolith

Example 2: The Revenge of the ESB

• Using ESBs (or similar)

• Ignoring delivery guarantees/expecting transactions

• Excessive marshalling/unmarshalling

• Canonical data models/complex schema

• Distributed monolith (based on lack of understanding of boundaries)

• Minilith (proliferation of technology, databases)

• lack of automation in infrastructure/testing

Recommendation• No canonical data model (services do not need to

understand every aspect of the service)

• canonical data model vs schemas

• Separate data from meta-data

• Data orientated modelling/schemas

• Normalise meta-data

Some Recommendations

Keep it domain-driven

Replace canonical data models with data views

Normalise metadata (and separate it from the rest of the data)

Use the right tool for the job

(and use common sense!)

Thank you!