using a service bus for microservice communication

1

Copyright 2017 Cameron

Vetter

U S I N G A S E R V I C E B U S F O R

M I C R O S E R V I C E C O M M U N I C A T I O N

2


Vetter

P R E S E N TAT I O N

You’ll leave with an understanding of how to effectively use a

Service Bus for Microservice communication to avoid tight coupling

between services.

Goal

3


Vetter

Cameron VetterSoftware Development is my passion. I have over 15 years of

experience using Microsoft tools to develop software. Currently I

am a Senior Software Architect at SafeNet Consulting,

where I get to do what I love... Architect, Design, and Develop

great software! I currently focus on Microservices, SOA, Azure,

IOT, and HoloLens.

@Poshporcupine

linkedin.com/in/cameronvetter

www.cameronvetter.com

4


Vetter

D E F I N E

M I C R O S E R V I C E S

S E R V I C E B U S

D E S I G N PAT T E R N S

M E S S A G E

T R A N S P O R T S

E V E N T U A L

C O N S I S T E N C Y

D E C O U P L I N G

T H R O U G H C O N T R A C T S

T H E

D E M O

ROADMAP

5


Vetter

Tooling

This talk is not tooling

specific, these architectural

patterns fit in most modern

developments stacks.

6


Vetter

W H AT D O I

M E A N B Y

M I C R O S E R V I C E S ?

7


Vetter

TRAITS OF

SERVICES

SERVICE

CONFUSION • Each is a software component

• Each service runs in its own process

• They use interprocess communication

• No coupling to other services except by

service contracts

• Windows Services

• Web Services (REST, SOAP, etc)

• Cloud Services

8


Vetter

M A R T I N F O W L E R

“Any fool can write code

that a computer can

understand. Good

programmers write code

that humans can

understand."

9


Vetter

MICROSERVICE ARCHITECTURE

CHARACTERISTICS

S o u r c e : m a r t i n f o w l e r . c o m / a r t i c l e s / m i c r o s e r v i c e s . h t m l

C o m p o n e n t i z a t i o n

v i a S e r v i c e s

• Independently Replaceable

• Independently Upgradeable

• Independent Dependencies

O r g a n i z e d A r o u n d

B u s i n e s s C a p a b i l i t i e s

• Not Organized Around

Technology

• Each Service (Team)

Focuses on One Business

Capability

10


Vetter


CHARACTERISTICS


P r o d u c t s

N o t P r o j e c t s

• No Longer Build A Project,

Disband, and Move On

• Team Owns the Service(s)

They Build

• Continue to Add Services

or Functionality to

Services

S m a r t E n d p o i n t s

a n d D u m b P i p e s

• Exact Opposite of an

ESB

• Smarts of A System

Moves Out of the Bus

and Into the Endpoints

11


Vetter


CHARACTERISTICS


D e c e n t r a l i z e d

G o v e r n a n c e

• No Longer Force

Everyone to Same

Technology Stack

D e c e n t r a l i z e d

D a t a M a n a g e m e n t

• Not Stuffing all Data in One

Huge Relational Database

• Services NEVER Connect to

Another Service’s Data

Store

• Prevents Integration

Through the Database

12


Vetter


CHARACTERISTICS


I n f r a s t r u c t u r e

A u t o m a t i o n

• Mandatory to Succeed

With MicroServices

• Continuous Delivery

• Ability to Deliver Fast

• Continuous Monitoring

D e s i g n

f o r f a i l u r e

• They Will Fail!

13


Vetter


CHARACTERISTICS


E v o l u t i o n a r y

d e s i g n

• Overall System Rapidly

Changes

• Allows More Granular Release

Planning

• Create Fault Tolerant

Contracts and Avoid

Versioning

14


Vetter

M E S S A G E

T R A N S P O R T S

15


Vetter

SERVICE BUS TRANSPORTSPROVIDES PLUMBING

Responsible for getting a message from point A to point B

and dealing with the underlying network.

PROVIDES RELIABILITY

Queueing mechanism to make sure messages are not

lost, handles retries, and handles failures.

PROVIDES SCALABILITY

Responsible for providing the scalability for the service

bus.

16


Vetter

Rabbit MQWORLD CLASS MESSAGE QUEUING

Built on erlang to provide unmatched performance,

feature set and community support.

ON PREMISE SOLUTION

In my opinion nothing comes close for power,

performance, or reliability.

MONITORING

The best built in monitoring solution available for a

transport.

17


Vetter

AZURE SERVICE BUSNOT QUITE A SERVICE BUS

Don’t let the title fool you, Azure Service Bus is no more a

complete service bus than Rabbit MQ.

CLOUD SOLUTION

PAAS solution that scales, and is maintained for you,

creating a great cloud solution.

WELL INTEGRATED

Azure Service Bus is well integrated into the Microsoft

stack, and cross platform compatible.

18


Vetter

RESTCOUPLING

REST interface used to talk to other services, every

service must be rebuilt when the interface changes.

COUPLING

Every service must know about and understand what

every other service is for and when to use it.

TURNS YOUR ARCHITECTURE TO

SPAGHETTI

Every architectural pattern degenerates into spaghetti

with the right antipattern.

19


Vetter

ENTERPRISE SERVICE BUSPUSHES LOGIC TO THE CENTER

Goal is to create smart endpoints and dumb pipes, an

ESB turns that upside down.

KITCHEN SINK

It slices, it dices… Security, Mediation, Protocols,

Transformations, Business Logic…

DON’T MAKE THE MONOLITH

The coupling created by an ESB will turn your

microservice architecture back into a monolith.

20


Vetter

E V E N T U A L


21


Vetter

BASEBASE data stores value availability and scale over consistency of replicated data.

B A S I C A L LY

AVA I L A B L E

Guaranteed availability of

data.

S O F T

S TAT E

The system could change

over time, even without

user interaction due to

eventual consistency

E V E N T U A L


The system is guaranteed

to eventually become

consistent, but not

guaranteed when it will

become consistent

22


Vetter

ACIDACID data stores value consistency over availability and scale

AT O M I C

All operations must

succeed or the entire

operation is rolled back.

C O N S I S T E N T

After each transaction the

database, its rules, and

relationships are intact.

I S O L AT E D

Each transaction runs

independently so there is

not transaction contention.

D U R A B L E

Once a transaction is

completed it is permanent

regardless of other

failures.

23


Vetter

E X A M P L E

EVENTUAL CONSISTENCYWhat does it mean to be eventually consistent?

Service A – 1

Florence

Service A – 2

Florence

Client Client

Florence

FloFlo

Florence

Flo

Flo

24


Vetter

• More complex to develop for

• Must have a strategy for stale data

• Must have a strategy for inconsistent data

• Allows for cost effective horizontal scaling

• Allows for live updates of a service without

taking the system down

• Able to deal with large quantities of data and

huge scale

PROS CONS

USE BASE INSTEAD OF ACIDA Microservice Architecture MUST plan for BASE as a consistency model between

services. ACID consistency quickly cripples a microservice architecture.

25


Vetter

D e c o u p l i n g

T h r o u g h

C o n t r a c t s

26


Vetter

S u b s c r i b e t o t h e

i n t e r f a c e n o t t h e c l a s s

N e v e r e x c h a n g e

c l a s s e s d i r e c t l y

P u b l i s h t h e i n t e r f a c e

n o t t h e c l a s s

E a c h s e r v i c e i m p l e m e n t s

t h e i n t e r f a c e a s a c l a s s

P r e v e n t s s e r v i c e

v e r s i o n i n g h e l l

SERVICE COMMUNICATION CONTRACTSEffective Use of Contracts Allows you to Remain Loosely Coupled

A l w a y s u s e c o n t r a c t s

e s t a b l i s h e d t h r o u g h

i n t e r f a c e s

27


Vetter

C O D E

Interface Versioning ExampleHow Do I Future Proof My Contracts?

public interface IWhoCanYouPassTo{

Guid RequestorId { get; }Guid LeftId { get; }Guid RightId { get; }

}

public class WhoCanYouPassTo : IWhoCanYouPassTo {…}

28


Vetter

C O D E

Next VersionHow Do I Future Proof My Contracts?

public interface IWhoCanYouPassTo{

Guid RequestorId { get; }Guid LeftId { get; }Guid RightId { get; }

}

public interface IWhoCanYouPassToV2{

Guid RequestorId { get; }Guid LeftId { get; }String LeftName { get; }Guid RightId { get; }String RightName { get; }

}

public class WhoCanYouPassTo : IWhoCanYouPassTo, IWhoCanYouPassToV2 {…}

29


Vetter

HOW ARE WE LOOSLY COUPLED?

• Any subscriber or publisher can independently change with no contract

changes required

• If a service changes a contract, new contracts are published, old

contracts remain valid

30


Vetter

S E R V I C E

B U S

D E S I G N

PAT T E R N S

31


Vetter

P u b l i s h / S u b s c r i b e

Each published message is received by all current

subscribers of that message type.

Publisher Bus

Subscribe

r

Subscribe

r

Subscribe

r

32


Vetter

C o m p e t i n g C o n s u m e r

Only one subscriber receives each message,

they take turns, typically in a round robin fashion.

Publisher Bus

Subscribe

r

Subscribe

r

Subscribe

r

33


Vetter

D e a d L e t t e r C h a n n e l

The bus is unable to deliver a message to a subscriber

and is placed in a dead letter queue.

Publisher Bus

Subscribe

r

Dead

Letter

34


Vetter

D o g P i l e s

If a service is overloaded or malfunctioning, the retries

compound the problem causing an outage which

causes a cascade of failures across many or all

services.

35


Vetter

S h a r e d D a t a b a s e

Multiple services sharing the same database creates

tight coupling between them. When one service changes the database all services must be updated

for the new schema.

36


Vetter

F l y i n g B l i n d

With a microservice architecture the need for

metrics and a view into the system is even greater than

in other architectures, without that view you are

flying blind and your results will be predicatable.

37


Vetter

T h e

E x a m p l e

38


Vetter

Pass the PotatoInspired by the Children’s Game Hot Potato, but only

where it was convenient for my demo.

M U LT I P L AY E R

Each player added to a

virtual circle

C R O S S P L AT F O R M

Works on any modern

web browser

D A S H B O A R D

View the big picture of the

game

S TAT S

Collect statistics for what I

can only assume will

make for compelling

reports

39


Vetter

A r c h i t e c t u r e

Pass The Potato consists of

two Apps, three

Microservices and a Service

Bus

Mass Transit / Azure Service Bus

Distributor ServiceStats Service

Dash

Board

WPF App

Web Page

App

Sessions Service

Service Contracts

40


Vetter

P a s s

T h e

P o t a t o

41


Vetter

D E F I N E

M I C R O S E R V I C E S

S E R V I C E B U S

D E S I G N PAT T E R N S

M E S S A G E

T R A N S P O R T S

E V E N T U A L


D E C O U P L I N G

T H R O U G H C O N T R A C T S

T H E

D E M O

IN SUMMARY

42


Vetter

Any Questions

w w w . c a m e r o n v e t t e r . c o m

All Software Development

Related, Tutorials, Talks,

and More

l i n k e d i n . c o m / i n / c a m e r o n v e t t e r

Contact Me Directly

@ p o s h p o r c u p i n e

Mostly Development and

Gaming Related, but

whatever I find interesting