using a service bus for microservice communication
TRANSCRIPT
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
Copyright 2017 Cameron
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
Copyright 2017 Cameron
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
Copyright 2017 Cameron
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
Copyright 2017 Cameron
Vetter
Tooling
This talk is not tooling
specific, these architectural
patterns fit in most modern
developments stacks.
7
Copyright 2017 Cameron
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
Copyright 2017 Cameron
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
Copyright 2017 Cameron
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
Copyright 2017 Cameron
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
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
Copyright 2017 Cameron
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
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
Copyright 2017 Cameron
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
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
Copyright 2017 Cameron
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
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
Copyright 2017 Cameron
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
Copyright 2017 Cameron
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
Copyright 2017 Cameron
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
Copyright 2017 Cameron
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
Copyright 2017 Cameron
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.
21
Copyright 2017 Cameron
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
C O N S I S T E N C Y
The system is guaranteed
to eventually become
consistent, but not
guaranteed when it will
become consistent
22
Copyright 2017 Cameron
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
Copyright 2017 Cameron
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
Copyright 2017 Cameron
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.
26
Copyright 2017 Cameron
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
Copyright 2017 Cameron
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
Copyright 2017 Cameron
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
Copyright 2017 Cameron
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
31
Copyright 2017 Cameron
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
Copyright 2017 Cameron
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
Copyright 2017 Cameron
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
Copyright 2017 Cameron
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
Copyright 2017 Cameron
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
Copyright 2017 Cameron
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.
38
Copyright 2017 Cameron
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
Copyright 2017 Cameron
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
41
Copyright 2017 Cameron
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
IN SUMMARY
42
Copyright 2017 Cameron
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