Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Using a Service Bus for Microservice Communication

632 views

Published on

Choosing a microservice architecture isn’t a silver bullet. With microservices you’ve exchanged the problems of monolithic applications for a new set of problems. One of the biggest problems is effective, concise communication between services without accidental coupling. In this talk I will show how a Service Bus can be used to solve this problem.

This talk will use Mass Transit, RabbitMQ, Azure Service Bus, and C# to cover:

• Service Bus Design Patterns
• Message Transports
• Why not REST?
• Eventual Consistency
• Scalability and Reliability

You’ll leave with an understanding of how to effectively use a Service Bus for Microservice communication to avoid tight coupling between services and see demos of these concepts.

Published in: Software
  • Be the first to comment

Using a Service Bus for Microservice Communication

  1. 1. 1 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
  2. 2. 2 Copyright 2017 Cameron 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. 3. 3 Copyright 2017 Cameron 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
  4. 4. 4 Copyright 2017 Cameron 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. 5. 5 Copyright 2017 Cameron Tooling This talk is not tooling specific, these architectural patterns fit in most modern developments stacks.
  6. 6. 6 Copyright 2017 Cameron 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. 7. 7 Copyright 2017 Cameron 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. 8. 8 Copyright 2017 Cameron 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. 9. 9 Copyright 2017 Cameron 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. 10. 10 Copyright 2017 Cameron MICROSERVICE ARCHITECTUR 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. 11. 11 Copyright 2017 Cameron 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. 12. 12 Copyright 2017 Cameron MICROSERVICE ARCHITECTUR 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. 13. 13 Copyright 2017 Cameron 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
  14. 14. 14 Copyright 2017 Cameron M E S S A G E T R A N S P O R T S
  15. 15. 15 Copyright 2017 Cameron 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.
  16. 16. 16 Copyright 2017 Cameron 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.
  17. 17. 17 Copyright 2017 Cameron 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.
  18. 18. 18 Copyright 2017 Cameron 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.
  19. 19. 19 Copyright 2017 Cameron 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.
  20. 20. 20 Copyright 2017 Cameron E V E N T U A L C O N S I S T E N C Y
  21. 21. 21 Copyright 2017 Cameron 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 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. 22. 22 Copyright 2017 Cameron 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.
  23. 23. 23 Copyright 2017 Cameron 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
  24. 24. 24 Copyright 2017 Cameron • 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.
  25. 25. 25 Copyright 2017 Cameron 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. 26. 26 Copyright 2017 Cameron 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 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. 27. 27 Copyright 2017 Cameron 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 {…}
  28. 28. 28 Copyright 2017 Cameron C O D E Next Version How 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. 29. 29 Copyright 2017 Cameron 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. 30. 30 Copyright 2017 Cameron S E R V I C E B U S D E S I G N PAT T E R N S
  31. 31. 31 Copyright 2017 Cameron Publish / Subscr ibe Each published message is received by all current subscribers of that message type. Publisher Bus Subscribe r Subscribe r Subscribe r
  32. 32. 32 Copyright 2017 Cameron 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
  33. 33. 33 Copyright 2017 Cameron 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
  34. 34. 34 Copyright 2017 Cameron 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.
  35. 35. 35 Copyright 2017 Cameron 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.
  36. 36. 36 Copyright 2017 Cameron 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.
  37. 37. 37 Copyright 2017 Cameron T h e E x a m p l e
  38. 38. 38 Copyright 2017 Cameron 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
  39. 39. 39 Copyright 2017 Cameron 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
  40. 40. 40 Copyright 2017 Cameron P a s s T h e P o t a t o
  41. 41. 41 Copyright 2017 Cameron 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. 42. 42 Copyright 2017 Cameron 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

×