Microservices architecture is still a hot topic but many do not do it right. Challenges like cross-service dependencies, orchestration and load balancing require more and more bike-shedding instead of concentrating on the business capabilities. Using asynchronous messages, many of technical issues can be solved. Learn how to use advanced messaging patterns in your services. Slides are from a workshop given at Progressive .NET Tutorials 2017. Repository is on Github: https://github.com/alexeyzimarev/ProgNet2017.MassTransit

1. Give your (micro)services
a bus ride with MassTransit
Alexey Zimarev - @Zimareff

2. Who I am
• My name is Alexey Zimarev
• I am programming since I was 14
• First languages were Focal and
Assembler for PDP11
• Work as software architect as ABAX
AS in Norway
• Specialise in Domain-driven design,
event-sourcing, reactive and event-
driven systems
• Contribute to MassTransit and
RestSharp
• Twitter: @Zimareff

3. Quick Recap

4. Microservices
• Individually deployed
• Loosely coupled
• Highly cohesive
• Organised around business capabilities
• Autonomous

5. Now some diagrams

6. Huh? Shared database?
Source: nginx.com

7. Let it REST
Synchronously
Source: nginx.com

8. Another major challenge with the
Microservices Architecture pattern
is implementing changes that
span multiple services.
For example, let’s imagine that
you are implementing a story that
requires changes to services A,
B, and C, where A depends upon
B and B depends upon C.

9. Temporal coupling
Synchronous requests

10. Failures
Data loss

11. Temporal coupling
• Requestor and responder need to be alive
at the same time
• Requestor must wait for the response
• When responder is down, requestor is
effectively down as well
• Autonomy is gone

12. Spatial coupling

13. Spatial coupling
• Requestor needs to know the responder’s address
• Centralised configuration or service discovery

14. Load balancing
Is lying to you, essentially
Source: nginx.com
Push

15. Asynchronous
Messaging

16. Published in 2004
Gregor Hohpe
Bobby Woolf

17. Problem Statement
An enterprise has multiple applications that are
being built independently, with different languages
and platforms. The enterprise needs to share data
and processes in a responsive way.
How can I integrate multiple applications so that
they work together and can exchange
information?

18. Pattern
Use Messaging to transfer packets of data frequently,
immediately, reliably, and asynchronously, using
customizable formats.
Asynchronous messaging is fundamentally a pragmatic
reaction to the problems of distributed systems. Sending a
message does not require both systems to be up and ready
at the same time.

19. Furthermore, thinking about the communication in an
asynchronous manner forces developers to
recognize that working with a remote application is
slower, which encourages design of components
with high cohesion (lots of work locally) and low
adhesion (selective work remotely).

20. Message broker
• Reliable infrastructure
• Guarantees message delivery
• Different types of routing
• Scalability
• Fault tolerance

21. MassTransit
• Messaging framework for .NET
• Open Source
• Type-based routing
• Middleware support
• Lifecycle management
• Battle tested

22. No temporal coupling
Almost…

23. No spatial coupling
Using channels

24. Competing consumers
Real load balancing

25. Resilience

26. Basic patterns
• Fire and Forget
commands
• Request - Reply
commands with response and queries
• Publish - Subscribe
events, sometimes commands too

27. Fire and forget

28. Request - reply

29. Event-driven architecture
• Publish domain events
• Subscribers have their own concerns
• Publisher does not know subscribers
(and how many)
• Separation of concerns
• Reactive systems

30. Publish - subscribe

31. Retries
• Network is not reliable
• Infrastructure is not reliable
• Immediate retry can help with issues like deadlocks
• Delayed retries can solve race conditions

32. Scheduling
• Something to be done later
• Recurrent operations
• Batch job 2.0

33. Diagnostics
• Logging
• Audit
• Performance monitoring
• Error queue

35. Processes aka Sagas

36. Starbucks does
not use
two-phase
commit
Gregor Hohpe
http://www.enterpriseintegrationpatterns.com/rambli
ngs/18_starbucks.html

37. Orchestration
Microsoft CQRS Journey: Saga on Sagas

38. Saga
• Message-driven process manager
• Get started by a message
• Sends other messages
• Collects responses
• Keeps own persisted state
• Correlated by identity (CorrelationId)

39. Workflows with messages

40. Persistence
• SQL
• Entity Framework
• NHibernate

41. Persistence
• Document
• MongoDb
• Marten (PostgreSQL JSONB storage)
• RavenDb (external package)

42. Persistence
• Key-value store
• Redis

43. Persistence
• Event-sourcing
• EventStore (external package)

45. Transaction
uence of activities that complete together or no

46. Routing slip
• Activity as part of a transaction
• Itinerary describes the sequence of activities
• Itinerary is executed using a routing slip
• Failed activities need compensation

47. http://www.masstransit-project.com