THE REAL VALUE OF MICROSERVICES Simon Martinelli, 72 Services LLC

@simas_ch

ABOUT ME @simas_ch

2

2000 1995

Java

COBOL

2009 2007 2012 2011

JSR-352

Batch

2013

JSR-354 Money

/Currency

1972

The effectiveness of a “modularization” is dependent upon the criteria used in dividing the system into modules.

On the criteria to be used

in decomposing systems

into modules - David L. Parnas

Published in Communications of the ACM

Volume 15 Issue 12, Dec. 1972

3

IT’S ALL ABOUT MODULARITY

Module

A self-contained component of a system, often interchangeable, which has a well-defined interface to the other components.

Source: https://en.wiktionary.org/wiki/module

4

DOES THE SIZE MATTER?

• The term MICRO is misleading

• Scope matters • Bounded Contexts

• Design for Maintenance • 3 to 10 developers per Microservice during project

development

• But how many developers will

maintain the system?

5

WHAT ABOUT SERVICES?

• Service-Oriented Architecture (SOA) is an architectural style that supports service-orientation

• Service-orientation is a way of thinking in terms of services and service-based development and the outcomes of services

• Service • Is a logical representation of a repeatable business

activity that has a specified outcome (e.g., check customer credit, provide weather data)

• Is self-contained • May be composed of other services • Is a black box to consumers of the service

6

Source: http://www.opengroup.org/soa/source-book/soa/p1.htm

ARE THEY REALLY THE SAME?

7

MODULARITY AND DISTRIBUTION

8

Distribution

Modula

rity

Modular monolith

Monolithic big ball of mud Distributed big ball of mud

Microservices

DISTRIBUTED BIG BALL OF MUD

If you can't build a modular monolith, what makes you think microservices are the answer? - Simon Brown

9

Customer Order Catalog

BEWARE OF THE N+1 SELECT PROBLEM

• Use Case: Select orders of customers

• 1 request to get all customers

• n requests to get customers orders

10

Customer

Order

Client

1

1

…

n

DISTRUBUTION AND COMMUNICATION

First Law of Distributed Object Design: Don't distribute your objects - Martin Fowler

11

Synchronous Asynchronous Event based

SUBSYSTEMS (AKA GARTNERS MINISERVICES)

12

Backend A

Database

A

Database

B

Backend D

Database

D

Frontend

A

Frontend

B Frontend C

Backend B Backend C

Self-contained

System

Monolithic frontend

Integration Database

HOW TO BREAK THE MONOLITH? A Real World Example

13

SYSTEM ISSUES

• Cyclic dependencies

• No component structure

• Meaningless names

14

3 STEP REFACTORING

• Step 1: Define target architecture

• Define bounded contexts

• Introduce pattern language

• Separate infrastructure code from business code

• Step 2: Move existing code to newly defined subsystems

• Step 3 (optional): Distribute the subsystems

15

DEFINE BOUNDED CONTEXTS

16

Monitoring Analytics Testing

Device

Alarm

Update

Device

KPI

Profile

Job

Device

Measure-

ment

TARGET SYSTEMS ARCHITECTURE

17

Local Server

Device(s

)

Monitor

Message

Bridge

Remote Server

Monitor Analytic

s Testing

Message Broker Message

Broker

MIGRATION SCENARIO

18

Backend

Database

Frontend

Monolith

Backend

Database

Frontend

Step 1

Database

Frontend

Step 2..n

Backend

1

Database

1

Backend

Frontend

1

Backend

n

Database

n

Backend

1

Database

1

Subsystems

Frontend

n

DECOUPLING THROUGH MESSAGING

• Messaging enables modularity

• Messaging enforces independence

• Events not Request/Response

19

Monitor Analytic

s Testing

Message Broker Device(s

)

THE REAL VALUES

• A microservices architecture leads to modularity

• Developers are forced to follow

the structure

• It’s easier to replace a microservice instead of the whole system in the future

20

Thank You

72 Services LLC

2028 E Ben White Blvd 240-7272 | Austin, TX 78741 | 512-333-4412

Moosentli 7 | 3235 Erlach, Switzerland | 032 544 88 88

info@72.services | https:// 72.services