Using a service bus for microservice communication v2

2
Copyright 2017 Cameron
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

3
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

4
Cameron Vetter
Software 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

5
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

6
Tooling
This talk is not tooling
specific, these architectural
patterns fit in most modern
developments stacks.

7
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 ?

8
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

9
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."

10
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

11
MICROSERVICE ARCHITECTUR
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

12
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

13
MICROSERVICE ARCHITECTUR
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!

14
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

15
M E S S A G E
T R A N S P O R T S

16
SERVICE BUS TRANSPORT
PROVIDES 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.

17
Rabbit MQ
WORLD 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.

18
AZURE SERVICE BUS
NOT 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.

19
REST
COUPLING
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.

20
ENTERPRISE SERVICE BUS
PUSHES 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.

21
E V E N T U A L

22
Brewer’s (CAP) Theorem
Consistency
All users see the same data at the same moment.
Partition Tolerance
System continues to function as expected despite a
malfunction of connections between servers.
Availability
System continues to function as expected despite a
malfunction of servers.
Consistency
Partition
Tolerance
Availabilit
y
BASE

23
ACID
ACID 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.

24
ACID
ACID 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.

25
BASE
BASE 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

26
E X A M P L E
EVENTUAL CONSISTENCY
What does it mean to be eventually consistent?
Service A – 1
Florence
Service A – 2
Florence
Client Client
Florence
FloFlo
Florence
Flo
Flo

27
• 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 ACID
A Microservice Architecture MUST plan for BASE as a consistency model between
services. ACID consistency quickly cripples a microservice architecture.

28
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

29
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 CONTRACTS
Effective Use of Contracts Allow 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

30
C O D E
Interface Versioning Example
How Do I Future Proof My Contracts?
public interface IWhoCanYouPassTo
{
Guid RequestorId { get; }
Guid LeftId { get; }
Guid RightId { get; }
}
public class WhoCanYouPassTo : IWhoCanYouPassTo {…}

31
C O D E
Next Version
How Do I Future Proof My Contracts?
public interface IWhoCanYouPassTo
{
}
public interface IWhoCanYouPassToV2
{
String LeftName { get; }
String RightName { get; }
}
public class WhoCanYouPassTo : IWhoCanYouPassTo, IWhoCanYouPassToV2 {…}

32
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

33
S E R V I C E
B U S
D E S I G N
PAT T E R N S

34
Publish / Subscr ibe
Each published message is
received by all current
subscribers of that message
type.
Publisher Bus
Subscribe
r
Subscribe
r
Subscribe
r

35
Competing Consumer
Only one subscriber
receives each message,
they take turns, typically in a
round robin fashion.
Publisher Bus
Subscribe
r
Subscribe
r
Subscribe
r

36
Dead Letter Channel
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

37
Dog Piles
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.

38
Shar ed Database
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.

39
Flying Blind
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.

40
T h e
E x a m p l e

41
Pass the Potato
Inspired 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

42
P a s s
T h e
P o t a t o

43
Ar chitectur 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

44
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

45
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

Using a service bus for microservice communication v2

Recommended

Recommended

More Related Content

More from Cameron Vetter

More from Cameron Vetter (6)

Recently uploaded

Recently uploaded (20)

Using a service bus for microservice communication v2

Editor's Notes