Een andere kijk op Microservices

in a Microservices Architecture

Dennis van der SteltSoftware Architect

v a n d e r s t e l t

2Your presenter

Dennis van der Stelt

http://dennis.bloggingabout.net/

Software Architect

About Dennis

Innovative software architect

Almost 20 years of experience in development ofdistributed systems. Has a continuous drive tolearn and improve knowledge in differentarchitectural styles, including quality in softwaredevelopment. Highly motivated to share hisknowledge via articles, presentations and his blog.

Awards

NServiceBus Champ

Typemock MVP

Certified Trainer

Professional Services

Provides coaching & training

• Presentations

• Software & Architecture audits

• SOA & Microservices advice

• Unit Testing training

• NServiceBus training

Presentations

October 15th at Blaak Selectie / BetabitReliable systems using messaging


3

AgendaIn a polyglot architectural landscape with a lot of business logic, data and information, how can we build solid loosely coupled systems?

Let’s have a look at the differences between those opposites

Monolithic vs Microservices

Dividing your system’s business logic over logical boundaries

Service Boundaries

Why duplicating data is a bad practice, but replicating data is perfectly fine

Replicating vs Duplicating


Monolithic application

Wikipedia : large, powerful, and intractably indivisible and uniform.

A monolithic application is build and deployed as a single unit.

WordPress is a successful & scalable monolithic application used by millions!

Monolith is therefor not by default a badly designed system

4


5Microservices

a software architectural style for complex applications of small, independent processes.

services are small, highly decoupled and focus on a single task

communicate via language agnostic APIs

boundaries are explicitservices are autonomous

share schema & contract, not classescompatibility is based on policy


Monolithic application 6

single deployment unit


Microservices 7

multiple deployable services


Authentication

8Coupling

OSS

ViewModel

Change

Product

Database

Razor


9

First law

“My First Law of Distributed Object Design: Don't distribute your objects”

Martin Fowler in Patterns of Enterprise Application Architecture


10Monolithic application problems

Problem Analysis

of all monolithic systems are buildwith high time constraints, resultingin big balls of mud in which nodeveloper can find their way.

42%

MaintenanceThe coupling makes it hard to change anything

Documentation

Cost to add new featuresBuilding the 100th feature as fast as the 1st

Project Ownership


Monolithic application 11


12


13

Microservices“don't even consider microservices unless you have a system that's too complex to manage as a monolith”

Martin Fowler

BOUNDED CONTEXTDividing your system’s business logic over logical boundaries


15Microservices architecture

DeploymentDon’t necessarily need to separately deploy every single service

Bounded ContextDefine boundaries around logical business processes

MonitoringDocument message flows and monitor them with great tools

MessagingAsynchronous communication

via messaging & publish/subscribe


Any organization that designs a system will produce a design whose structure is a

copy of the organization's communication structure.“

”Conway’s law – 1968


Service boundaries 17

Ship

pin

gFin

ance

Sale

sM

arketing


Deployment 18

Ship

pin

gFin

ance

Sale

sM

arketing

SQL

SQL

{ }


Architectural style 19

Ship

pin

gFin

ance

Sale

sM

arketing

CQRS

Event SourcingCRUD

there is no

top level

architecture


Coupling aspects 20

SpatialTemporalPlatform


21

-Alan Kay-Creator of SmallTalk, Adjunct Professor at MIT & University of California

At Utah sometime after Nov 66 when, influenced by Sketchpad, Simula, the design for the ARPAnet, the Burroughs B5000, and my

background in Biology and Mathematics, I thought of an architecture for programming. It was probably in 1967 when someone asked me

what I was doing, and I said: "It's object-oriented programming".


22


Messaging

23

Ship

pin

gFin

ance

Sale

sM

arketing

SQL


Messaging

24

Ship

pin

gFin

ance

Sale

sM

arketing

SQL


Messaging

25

Ship

pin

gFin

ance

Sale

sM

arketing

SQLPublish / Subscribe


26

Messaging

Handle business events through

Inversion of communication

by supplementing SOA with EDA

“”


27Resume

Service BoundariesTry to see if your organizational communication structure can be the model for your logical service boundaries.

MessagingAvoid RPC style communication between services. Use messaging with an event driven architecture.

DeploymentDon’t necessarily see every microservice as a deployable unit. Do keep an eye out for coupling. Avoid joins in your database between entities.

DUPLICATION vs REPLICATIONWhy you shouldn’t duplicate, but replicate data


29

Do not duplicate

across service boundaries

You can share…

some information

Publish / Subscribe

to notify in advance


30Duplicating data

What event just took placebusiness process related

events that other services require to properly function

and take action on

Status changes Identifiers Date Time Info

Who was the subjectthe triggered event has a

specific subject in our domain

When does the status expirewhen status updates expire or

are no longer relevant at a point in time, we provide

expiration information


Sales

Messaging 31

Taxi

CustomersTaxiRequested

TaxiRequested

RequestTaxi


Sales

Messaging 32

TaxiTaxiRequested

RequestTaxi

FinanceTaxiAssigned

Customers


Sales

Messaging 33

TaxiRequestCancelled

Finance

RequestCancelled

CancelRequest


34Replicating vs Duplicating data

So duplication of data is not good But what about this

replicating data?


35Replicating vs Duplicating data

So duplication of data is not good But what about this

replicating data?

Replicating within a service boundary is okay

for performance or connectivity issues


36Replicating data options

Performance optimization

Suitable for all categories business and personal presentation

In memory cache

Prepare for optimal querying

Prepare data for querying, for example into a specific readmodel / viewmodel

Resolve latency issues

Replicating data across physical machines does not break service boundaries

Resolve network issues

Different sites across the globe, or a moving site without connection,

like a large container ship

Viewmodels

Different machines

Different sites


37Composite UI; little micro views

SalesLists requests made by

customer

CustomerDisplays customer information such as name and current location

TaxiShows where taxi drivers are and at what time they arrive at your location

FinanceDisplays status of all

financial transactions and outstanding bills

IMPLEMENTINGinto your own system

39

Implementation

Find edge casesNew features that are added (not

integrated) into your system

Publish messages to itStart using messaging and

publish/subscribe for communication

Add small databasesDo not integrate into your big ball of

mud database; keep it seperate

Pay attention to logical boundariesA service is the technical authority of

a specific business capability

MONITORINGyour services


41Monitoring


42Monitoring


43Monitoring


44Resume; how we build microservices

Define BoundariesDefine boundaries of your services. Your organizationalstructure may help. Do not duplicate data across services.Share status changes, identifiers and date-times.

ImplementImplement your microservices that handle a single task.Use publish/subscribe to notify other services with statuschanges.

Composite UIEverything from data up until the user interface shouldbelong in a service, resulting in a composite ui thatretrieves data based on the mentioned identifiers.

DeployDeploy your microservices, but not necessarily as singleunits. A possibility is a deployment unit per serviceboundary.


45

Microservices can be hard to build, deploy & monitor. Get help from people with experience

Think about temporal coupling between services and how to solve this, possibly with messaging

Do not duplicate data between services, as at some point business logic will follow

Conclusion


46


48Contact Me

AddressRotterdam, The Netherlands

[email protected]

Twitter@dvdstelt

Websitehttp://dennis.bloggingabout.net

Thank you for your time…

Een andere kijk op Microservices

Technology

Transcript of Een andere kijk op Microservices