Learn more about message-based architecture in the cloud including implementation details, real-world examples, insights from leading experts in NServiceBus and Microsoft Azure.

1. Cloud Messaging with
NServiceBus and Microsoft Azure
Particular Webinar

2. Who we are
Mauro Servienti
CTO & Architect at Managed Designs, an IT company based in Italy. He is a
Microsoft MVP for Visual C# and a Particular Support engineer.
Sean Feldman
has been developing software professionally since 2001. He is Director of
Development at Travel Alberta and a Particular Support engineer.
Yves Goeleven
has been shipping enterprise and cloud software since 2001. He is a
Windows Azure MVP (4 years running), a developer at Particular Software
and founder of MessageHandler.net and a Particular Support engineer.

3. Agenda
• Introduction to Microsoft Azure;
• Moving to Microsoft Azure;
• The problems we need to face moving to the cloud;
• Introduction to messaging;
• NServiceBus and Microsoft Azure;
• Azure Transports Deep Dive;
• Particular Platform overview;

4. Introduction to Microsoft Azure

5. Microsoft Azure: concepts
• SaaS - Software as a Service: pay-as-you-go managed services to be consumed;
• Our responsibility: the configuration of the service;
• Scalability and availability: automatically handled by the infrastructure;
• Samples: Windows Media Services, Mobile Services, ServiceBus;
• PaaS - Platform as a Service: Managed stateless platform, abstracts the OS;
• Our responsibility: the business application development;
• Scalability and availability: on demand or automatic;
• Samples: Web Sites, Web Roles, Worker Roles;
• IaaS - Infrastructure as a Service: Managed state full VMs, abstracts the HW;
• Our responsibility: OS maintenance and business application installation, updates, backup;
• Scalability and availability: on demand, the installed application need to support it;

6. Microsoft Azure Data centers
• Azure data centers are huge:
• Lots of physical machines;
• Each physical machine hosting several Virtual Machine(s);
• Each Virtual machine hosting at least 1 «SaaS like service»;
• Each service is connected to the outside world and internally:
• Virtual Load Balancers
• Virtual Networks;
• We cannot rely on:
• Network reliability and availability;
• Low latency;
• Network topology being known and stable over time;
• «instances» are moved around by the Azure infrastructure;

7. Microsoft Azure SLA
• Hardware fails all the time: Physical servers fails;
• It’s something we don’t need to handle;
• It is something we need to care about;
• We need at least 2 instances of everything:
• Instance «1» fails, e.g. due to hardware failure, instance «1» is lost;
• Instance «2» is still servicing requests;
• Azure infrastructure will take care of re-imaging instance «1» for us;
• With at least 2 instances we have a highly available system;

8. Why Microsoft Azure
• Horizontal Scaling with Scale on demand:
• No need to be prepared to scale upfront from the infrastructure point of
view;
• No worries about hardware management:
• and long term costs;
• In general no worries about the infrastructure:
• from the Ops point of view;
• Pay as you go;

9. The problem we need to face

10. Moving to the cloud #1
Given that we have occasionally connected moving parts:
Web Frontend
Shipping
WCF Service
Standard RPC call to WCF
If the «Shipping» service fails, because the Azure instance fails:
• We can lose information;
• We need to handle failures and retries manually;

11. Moving to the cloud #2
Given that we have network with medium to high latency:
Web Frontend
Shipping
WCF Service
Standard RPC call to WCF
If the connection with «Shipping» service fails, is slow or timeouts:
• We can lose information;
• We slow down the whole system;

12. Introduction to messaging

13. A new scenario: async and distributed
• We have:
• occasionally connected systems;
• Moving and distributed parts;
• Non-reliable networks;
• We should not rely on RPC calls to drive the system;

14. Messages
A message can be shipped to a remote service via a queue
• Azure ServiceBus or Azure Queues
Web Frontend #1 Shipping Endpoint #1
Azure
ServiceBus
Web Frontend #2 Shipping Endpoint #2
competingconsumers
• If one endpoint fails messages will be picked by the other(s);
• On slow connections endpoints do not slow down the entire system;

15. Zoom in: Azure ServiceBus / Queues
• If the endpoint connects to another resource that fails we need to:
• Handle the failure;
• Handle the retry logic;
• Handle the retry count and decide what to after n failing retries;
• Handle how to reply back to the original sender to provide feedback;
Shipping EndpointAzure
ServiceBus
DB

16. NServiceBus and Microsoft Azure

17. We want to focus on business challenges, not Azure infrastructure
• NServiceBus will handle transport details for us
• Sending and receiving messages over
Azure Storage Queues and Azure ServiceBus
• Handling large/binary data with Azure Storage Blobs
• NServiceBus will handle retries and failures
• First Level Retries
• Second Level Retries
• Error queue
• NServiceBus will provide auditing
• Create audit messages
Why NServiceBus on Microsoft Azure?
Focus on What, not on How

18. Why NServiceBus on Microsoft Azure?
Long Running Processes in real life
Check-out
Order Items
Pick up
Ensure Items
In Stock
Bill customer
credit card
3rd party
billing service
Setup Order
cancellation
Timeout
Start item
collection
Order ready
to be shipped
Customer
credit card
billed
cancellation
Timeout
Elapsed
Order
Cancelled? yes
No
Cancel &
Complete
The order
Ship &
Complete
The order
UserRequest

19. Why NServiceBus on Microsoft Azure?
Long Running Processes
We want to focus on the processes, not Azure technicalities
• NServiceBus will implement Sagas on top of Azure:
• Azure closest equivalent would be a complex Worker Role;
• NServiceBus Saga Timeouts feature on Azure:
• Azure has no equivalent for Worker Role, custom timer operation;
• NServiceBus Saga Persistence is handled automatically:
• Azure has no equivalent for Worker Role, custom persistence code;

20. Why NServiceBus on Microsoft Azure?
Endpoints
We want Azure scaling model with NServiceBus easy hosting
• NServiceBus will provide endpoint hosting over Azure:
• For Web and Worker Roles;
• NServiceBus will allow to debug endpoints locally:
• With or without emulator;
• NServiceBus can host multiple endpoints in a single Role:
• Azure has no equivalent;
• Significant money saving;

21. Why NServiceBus on Microsoft Azure?
Meaningful Messaging
We want meaningful domain messages
• NServiceBus will decouple messages from infrastructure:
• Azure messages are transport / technical;
• NServiceBus will provide Commands and Events:
• Azure has generalized transport message only;

22. Case Study:
TRAVEL ALBERTA

23. Email Signup Service
Business Requirements
• Allow visitors signup / modify interest subscription / unsubscribe
• Never lose visitor information
Technical Requirements
• Integration with 3rd parties
• ExactTarget
• Support desk
• Account for service disruption that always happens
• Highly Available
• Minimal IT involvement
Lessons Learned
• Gradual learning curve (vs steep learning curve)
• Tooling for raw Azure is a challenge, possible solution Particular Platform

24. Azure Transports Deep Dive

25. 2 Native transports
• Azure Storage Queues
• Azure ServiceBus
• Queue Peek Lock for retries instead of transactions;
• How to choose?

26. Azure Storage Queues
• Construct in storage system;
• Highly reliable (Cross DC);
• Very cheap;
• 500TB capacity limit;
• HTTP(s) based;
• TTL max 7 days;

27. Azure ServiceBus
• Real broker service;
• Reliable (within DC);
• Supports queues, topics, subscriptions;
• Loads of additional features;
• Dedupe, session, partitioning, deferral, dead-lettering, ordering, batching…
• 5GB capacity limit;
• TCP based (SBMP, AMQP), lower latency;
• TTL no limit;
• Relatively expensive*;

28. Persistence: What maps to what
• Subscriptions
• Table storage (for storage queues transport)
• Native subscriptions on topics (for azure ServiceBus transport)
• Sagas
• Table storage, 1 table per saga type
• Timeouts
• 2 tables, 2 queues & blob container for state
• Data bus
• Blob storage container

29. Crossing data centers boundaries
• We should be as near as possible to where the service is used;
• services in different Azure data centers;
• communication across data centers boundaries;
• Every endpoint instance can only listen to:
• 1 ServiceBus namespace or storage account;
• 1 queue;
• Message mappings:
• Allow us to specify “connection string”;
• Per assembly, namespace or per message
• We can send & subscribe across DC’s;
<add Assembly="VideoStore.Messages”
Namespace="VideoStore.Messages.Events”
Endpoint="VideoStore.Sales@otherconnectionstring" />

30. Particular Platform
Overview

31. Async & Distributed: monitoring
• When dealing with async and distributed messages monitoring is a
must have:
• we need to understand what is where;
• we need to understand what is going on;
• Monitoring must-have:
• Endpoints heartbeat;
• Message tracking;
• Sagas progress and tracking;

32. Particular Platform
ServicePulse
• Heartbeat;
• Custom Checks;
• Alerts;
• Failed endpoints
• Failed Messages;
ServiceInsight
• Message tracking;
• Message details;
• Sagas progress;

33. Q&A
Thanks to everyone