Skip to main content

Azure Container Instances and Azure Service Fabric - what to use when?

1 min read

Azure Service Fabric

Service Fabric is Microsoft’s orchestration platform powering many Tier-1 Microsoft services such as Azure SQL Database, Azure Document DB, Cortana, Windows Intune, and Skype for Business. 

Service fabric is an E2E PaaS platform, integrating many critical capabilities (e.g. container orchestration, service discovery, etc.) that allows you to develop, deploy and operate your applications (containerized or not). Service Fabric is a Windows environment with Linux and container support being added. Service Fabric is an ideal solution for Windows customers who may have some Linux workloads.

Azure Container Service

Azure Container Service is focused on deploying, scaling and managing Linux containers first, with Windows Server Containers being added. Customers using Linux container technologies should consider Azure Container Service.  ACS is an ideal solution for Linux customers who may have some Windows workloads.  

 

Go Go Azure Functions!

11 min read

 

 Azure Functions are cool.  Functions are conceptually similar to WebJobs in that they are event-driven (triggered) and can be easily integrated with other Azure resources.  Functions are a lightweight alternative to rapidly building and deploying event-driven microservices (several jump start templates are available - see the list at the bottom of this post).  Like most microservices, Functions should be stateless and idempotent.

 With Azure Functions, your applications scale based on demand and you pay only for the resources you consume (e.g. "serverless"). It’s important to note here that the Consumption Pricing Tier (which is the default) imposes a 5 minute time limit on your Functions. If your Function needs more than 5 min to execute you’ll need to host your Function on an App Service VM (although you probably shouldn’t be using Functions if your process needs more than 5 minutes to execute - check out Functions Best Practices).  

 Azure Functions can be implemented in multiple programming lanugages and all the code is available on GitHub:

 To learn more about Azure Functions, see the Azure Functions Overview.

 Function Proxies

 Azure Function Proxies were announced as a preview last week.  Function Proxies enable you to define a single API across multiple Functions. You can learn more about Azure Function Proxies here.

Function Proxies vs. API Management - What to Use When?

I've had a few people express confusion about what to use when: Azure Proxies vs. Azure API Management (APIM).  Azure Function Proxies and APIM can both be used to map a single API to one or more endpoints. Function Proxies make it easier to manage and expose multiple Functions through a simple API while APIM is a full service gateway for documenting, securing, logging and governing the use of your APIs.

 

 

A List of all Function Templates

These templates are available in the Azure Functions Portal.

Core Templates:

BlobTrigger-CSharp - A C# function that will be run whenever a blob is added to a specified container

BlobTrigger-FSharp - An F# function that will be run whenever a blob is added to a specified container

BlobTrigger-JavaScript - A JavaScript function that will be run whenever a blob is added to a specified container

EventHubTrigger-CSharp - A C# function that will be run whenever an event hub receives a new event

EventHubTrigger-FSharp - An F# function that will be run whenever an event hub receives a new event

EventHubTrigger-JavaScript - A JavaScript function that will be run whenever an event hub receives a new event

GenericWebHook-CSharp - A C# function that will be run whenever it receives a webhook request

GenericWebHook-FSharp - An F# function that will be run whenever it receives a webhook request

GenericWebHook-JavaScript - A JavaScript function that will be run whenever it receives a webhook request

GitHubWebHook-CSharp - A C# function that will be run whenever it receives a GitHub webhook request

GitHubWebHook-FSharp - An F# function that will be run whenever it receives a GitHub webhook request

GitHubWebHook-JavaScript - A JavaScript function that will be run whenever it receives a GitHub webhook request

HttpTrigger-CSharp - A C# function that will be run whenever it receives an HTTP request

HttpTrigger-FSharp - An F# function that will be run whenever it receives an HTTP request

HttpTrigger-JavaScript - A JavaScript function that will be run whenever it receives an HTTP request

ManualTrigger-CSharp - A C# function that is triggered manually via the portal "Run" button

ManualTrigger-FSharp - An F# function that is triggered manually via the portal "Run" button

ManualTrigger-JavaScript - A JavaScript function that is triggered manually via the portal "Run" button

QueueTrigger-CSharp - A C# function that will be run whenever a message is added to a specified Azure Queue Storage

QueueTrigger-FSharp - An F# function that will be run whenever a message is added to a specified Azure Queue Storage

QueueTrigger-JavaScript - A JavaScript function that will be run whenever a message is added to a specified Azure Queue Storage

ServiceBusQueueTrigger-CSharp - A C# function that will be run whenever a message is added to a specified Service Bus queue

ServiceBusQueueTrigger-FSharp - An F# function that will be run whenever a message is added to a specified Service Bus queue

ServiceBusQueueTrigger-JavaScript - A JavaScript function that will be run whenever a message is added to a specified Service Bus queue

ServiceBusTopicTrigger-CSharp - A C# function that will be run whenever a message is added to the specified Service Bus topic

ServiceBusTopicTrigger-FSharp - An F# function that will be run whenever a message is added to the specified Service Bus topic

ServiceBusTopicTrigger-JavaScript - A JavaScript function that will be run whenever a message is added to the specified Service Bus topic

TimerTrigger-CSharp - A C# function that will be run on a specified schedule

TimerTrigger-FSharp - An F# function that will be run on a specified schedule

TimerTrigger-JavaScript - A JavaScript function that will be run on a specified schedule

API and Webhooks Templates:

GenericWebHook-CSharp - A C# function that will be run whenever it receives a webhook request

GenericWebHook-FSharp - An F# function that will be run whenever it receives a webhook request

GenericWebHook-JavaScript - A JavaScript function that will be run whenever it receives a webhook request

GitHubWebHook-CSharp - A C# function that will be run whenever it receives a GitHub webhook request

GitHubWebHook-FSharp - An F# function that will be run whenever it receives a GitHub webhook request

GitHubWebHook-JavaScript - A JavaScript function that will be run whenever it receives a GitHub webhook request

HttpTrigger-CSharp - A C# function that will be run whenever it receives an HTTP request

HttpTrigger-FSharp - An F# function that will be run whenever it receives an HTTP request

HttpTrigger-JavaScript - A JavaScript function that will be run whenever it receives an HTTP request

Data Processing Templates:

BlobTrigger-CSharp  - A C# function that will be run whenever a blob is added to a specified container

BlobTrigger-FSharp - An F# function that will be run whenever a blob is added to a specified container

BlobTrigger-JavaScript - A JavaScript function that will be run whenever a blob is added to a specified container

EventHubTrigger-CSharp - A C# function that will be run whenever an event hub receives a new event

EventHubTrigger-FSharp - An F# function that will be run whenever an event hub receives a new event

EventHubTrigger-JavaScript - A JavaScript function that will be run whenever an event hub receives a new event

QueueTrigger-CSharp - A C# function that will be run whenever a message is added to a specified Azure Queue Storage

QueueTrigger-FSharp - An F# function that will be run whenever a message is added to a specified Azure Queue Storage

QueueTrigger-JavaScript - A JavaScript function that will be run whenever a message is added to a specified Azure Queue Storage

SendGrid-CSharp - (Preview) A C# function that sends a confirmation e-mail when a new item is added to a particular queue

SendGrid-JavaScript - (Preview) A JavaScript function that sends a confirmation e-mail when a new item is added to a particular queue

ServiceBusQueueTrigger-CSharp - A C# function that will be run whenever a message is added to a specified Service Bus queue

ServiceBusQueueTrigger-FSharp - An F# function that will be run whenever a message is added to a specified Service Bus queue

ServiceBusQueueTrigger-JavaScript - A JavaScript function that will be run whenever a message is added to a specified Service Bus queue

ServiceBusTopicTrigger-CSharp - A C# function that will be run whenever a message is added to the specified Service Bus topic

ServiceBusTopicTrigger-FSharp - An F# function that will be run whenever a message is added to the specified Service Bus topic

ServiceBusTopicTrigger-JavaScript - A JavaScript function that will be run whenever a message is added to the specified Service Bus topic

TimerTrigger-CSharp - A C# function that will be run on a specified schedule

TimerTrigger-FSharp - An F# function that will be run on a specified schedule

TimerTrigger-JavaScript - A JavaScript function that will be run on a specified schedule

Sample Templates:

FaceLocator-CSharp - A C# function that processes images and outputs the bounding rectangle of faces

FaceLocator-FSharp - An F# function that processes images and outputs the bounding rectangle of faces

FaceLocator-JavaScript - A JavaScript function that processes images and outputs the bounding rectangle of faces

GitHubCommenter-CSharp - A C# function that will be run whenever it receives a GitHub webhook request

GitHubCommenter-FSharp - An F# function that will be run whenever it receives a GitHub webhook request

GitHubCommenter-JavaScript - A JavaScript function that will be run whenever it receives a GitHub webhook request

HttpGET(CRUD)-CSharp - A C# function that fetches entities from a Storage Table when it receives an HTTP request

HttpGET(CRUD)-FSharp - An F# function that fetches entities from a Storage Table when it receives an HTTP request

HttpGET(CRUD)-JavaScript - A JavaScript function that fetches entities from a Storage Table when it receives an HTTP request

HttpGET(CRUD)-PHP - (Experimental) A PHP function that fetches entities from a Storage Table when it receives an HTTP request

HttpPOST(CRUD)-CSharp - A C# function that adds entities to a Storage Table when it receives an HTTP request

HttpPOST(CRUD)-FSharp - An F# function that adds entities to a Storage Table when it receives an HTTP request

HttpPOST(CRUD)-JavaScript - A JavaScript function that adds entities to a Storage Table when it receives an HTTP request

HttpPUT(CRUD)-CSharp - A C# function that updates entity in a Storage Table when it receives an HTTP request

HttpPUT(CRUD)-FSharp - An F# function that updates entity in a Storage Table when it receives an HTTP request

ImageResizer-CSharp - A C# function that creates resized images whenever a blob is added to a specified container

ImageResizer-FSharp - An F# function that creates resized images whenever a blob is added to a specified container

SasToken-CSharp - A C# function that generates a SAS token for Azure Storage for a given container and blob name

SasToken-FSharp - An F# function that generates a SAS token for Azure Storage for a given container and blob name.

SasToken-JavaScript - (Preview) A JavaScript function that will be run whenever a file is added to a External File provider.

ScheduledMail-CSharp - (Preview) A C# function that will periodically send emails

SendGrid-CSharp - (Preview) A C# function that sends a confirmation e-mail when a new item is added to a particular queue

SendGrid-FSharp - (Preview) An F# function that sends a confirmation e-mail when a new item is added to a particular queue

SendGrid-JavaScript - (Preview) A JavaScript function that sends a confirmation e-mail when a new item is added to a particular queue

Experimental Templates:

BlobTrigger-Batch - (Experimental) A Batch function that will be run whenever a blob is added to a specified container

ExternalFileTrigger-Batch - (Experimental) A Batch function that will be run whenever a file is added to a External File provider.

ExternalFileTrigger-CSharp - (Preview) A C# function that will be run whenever a file is added to a External File provider.

ExternalFileTrigger-FSharp - (Preview) An F# function that will be run whenever a file is added to a External File provider.

ExternalFileTrigger-JavaScript - (Preview) A JavaScript function that will be run whenever a file is added to a External File provider.

ExternalTable-CSharp - (Experimental) A C# function that fetches entities from a External Table when it receives an HTTP request.

ExternalTable-FSharp - (Experimental) An F# function that fetches entities from a External Table when it receives an HTTP request.

HttpTrigger-Batch - (Experimental) A Batch function that will be run whenever it receives an HTTP request

HttpTrigger-Powershell - (Preview) A PowerShell function that will be run whenever it receives an HTTP request

QueueTrigger-Bash - (Experimental) A bash function that will be run whenever a message is added to a specified Azure Queue Storage

QueueTrigger-Batch - (Experimental) A Batch function that will be run whenever a message is added to a specified Azure Queue Storage

QueueTrigger-Php - (Experimental) A PHP function that will be run whenever a message is added to a specified Azure Queue Storage

QueueTrigger-Powershell - (Preview) A PowerShell function that will be run whenever a message is added to a specified Azure Queue Storage

QueueTrigger-Python - (Experimental) A Python function that will be run whenever a message is added to a specified Azure Queue Storage

TimerTrigger-Powershell - (Preview) A PowerShell function that will be run on a specified schedule

 

Service Bus Refresher

12 min read

Re-post of an earlier blog entry, testing integration of my blog with Medium. Feedback/flames always welcome.

 

tldr;

Service Bus is a general term for an integration infrastructure that enables different systems or components to communicate through a shared interface, traditionally implemented as event-driven message queues.   Microsoft supports the service bus pattern across a number of products but this entry will only focus on two of them: Azure Service Bus and Service Bus for Windows Server.  These two products are sometimes simply referred to as "Service Bus" but it's important to realize their differences:

 

  • Azure Service Bus is a generic, cloud-based messaging system for connecting just about anything—applications, services, and devices—wherever they are. Connect apps running on Azure, on-premises—or both. You can even use Azure Service Bus to connect household appliances, sensors, and other devices like tablets or phones to a central application or to each other. 

 

  • Service Bus for Windows Server (SBWS) is a set of installable components that provides the messaging capabilities of Azure Service Bus on-premises. Service Bus for Windows Server enables you to build, test, and run loosely-coupled, message-driven applications in self-managed environments and on developer computers. 

 

Azure Service Bus and Service Bus for Windows Server are wire compatible via BrokeredMessages - this means messages generated by Azure Service Bus can be routed over Service Bus for Windows Server or Service Bus for Windows Server over Azure Service Bus.

 

Azure Service Bus and Service Bus for Windows Server share some common capabilities but also have fundamental differences.  See the sections below for more details on the differences and scenarios on which to use when.

 

Important Note: Service Bus for Windows Server lags behind the SDK support for Azure Service Bus due to the product team's "cloud first" approach. At the time this guidance was written Service Bus for Windows Server SDK was several releases behind the Azure SDK.  See the "Service Bus Releases" section of the Service Bus for Windows Release Notes for more information.  

 

Comparison of Azure Service Bus (ASB) and Service Bus for Windows Server (SBWS)

BrokeredMessages, Queues and Topics

  • ASB and SBWS both support BrokeredMessages.
  • ASB and SBWS both support a publish and subscribe pattern usingqueues andtopics.
    • With queues, each message sent to the queue is consumed by a single receiver.
    • With topics, messages are made available to each subscription registered with the topic. Each subscription logically maintains its own queue of messages. Subscriptions can also be configured with filter rules that restrict the set of messages passed to the subscription queue to those that match the filter.

Installation and support

  • ASB: Since ASB is a cloud-based service there is no software to install and support is provided by the Azure Team. OS and application patching and updating is also handled by the Azure Team. Storage is provided by and managed by the Azure Team. Backups and business continuity of ASB itself is managed by the Azure Team.
  • SBWS: SBWS runs on-premises and must be installed and configured on a Server 2013 or Server 2008 R2 machine (you can also install it on Win7 or Win8 for individual developer usage). SQL Server 2012 or 2008 is also required (Enterprise or Express versions). OS and application patching and updating must be handled by a local support team. Storage is provided by SQL Server and must be managed by a local support team. Backups and business continuity must be managed by a local support team.

Message Relays

  • ASB: ASB’s relay service supports direct one-way messaging, request/response messaging, and peer-to-peer messaging.  The Service Bus relay service enables you to build hybrid applications that run in both an Azure datacenter and your own on-premises enterprise environment.
  • SBWS: SBWS does not support relayed messaging.

Security

  • ASB: Shared Access Signature authentication (SAS) is the preferred way to implement authentication in Azure Service Bus.  SAS enables applications to authenticate to ASB using an access key configured on the namespace or the entity with which specific rights are associated. You can then use this key to generate a SAS token that clients use to authenticate to Service Bus.  See MSDN for more information on SAS tokens
  • SBWS: Solutions deployed on-premises using SBWS can use either Shared Access Signature authentication (SAS) or  Windows integrated security (Active Directory).  Applications can use SAS in scenarios in which they do not need to manage the notion of an authorized "user".  SBWS includes a Service Bus Security Token Service (SBSTS) which is fully integrated with the Windows security model. SBSTS can issue self-signed Simple Web Tokens (SWTs) using Windows identities. 

Quotas/runtime settings

  • ASB: Options regarding message and queue sizes are fixed due to the multi-tenant nature of ASB.  ASB Queue/Topic sizes can be up to 5 GB.  Messages can be up to 256K.  See here for specifics on ASB quotas.
  • SBWS: SBWS provides much greater freedom for configuring runtime settings and message and queue sizes.   SBWS Queue/Topic sizes can be up to 10 GB.  Messages can be up to 50MB.    See here for specifics on SBWS quotas.

Network latency

  • ASB: Network and security latencies may impact performance, especially when moving messages from on-premises to cloud or cloud to on-premises. Throughput could also be impacted by unexpected spikes in unrelated internet traffic.
  • SBWS: Administrators have much more control over their own network’s traffic and routing, thereby enabling more efficient bandwidth usage and throughput.

Addressing schemas

  • ASB: ASB Namespaces are fixed – all endpoints have a Service Bus postfix added to the URL to ensure uniqueness.
  • SBWS: SBWS uses fully qualified domain names (FQDN) or a mapped DNS entry to represent service namespaces.

Instances

  • ASB: In ASB there is only one "instance" of the service available and it is managed by Microsoft.
  • SBWS: With SBWS it is possible to have several on-premises SBWS servers via self-hosted servers or third-party providers.

Notification Hubs

  • ASB: Azure Notification Hubs provide an easy-to-use infrastructure that enables you to send mobile push notifications from any backend (in the cloud or on-premises) to any mobile platform.

 

  • SBWS: SBWS doesn't support Notification Hubs (although Notifications can be sent over SBWS).

Event Hubs

  • ASB: Event Hubs are highly scalable publish-subscribe event ingestors that can intake millions of events per second so that you can process and analyze the massive amounts of data produced by your connected devices and applications.
  • SBWS: SBWS doesn't support Event Hubs (although Events can be sent over SBWS).

 

What to Use When:

 

Use Azure Service Bus when:

  • Building cloud applications or services and requiring a scalable messaging system between components
  • Crossing cloud and on-premises boundary
  • Message transformation or service orchestration are not required
  • Support for B2B integration is not required (AS2, X12, EDIFACT, …)
  • Relaying small messages (256 KB or less), which may contain the payload itself or may be notifications for the availability of larger payloads to process from Azure Storage Blob (see http://msdn.microsoft.com/en-us/library/hh690942.aspx)
  • You need to support AQMP in a cloud or hybrid architecture
  • Distributed Transactions (DTC) is not required
  • You need to build hybrid applications that run in Azure datacenter and on-premises without having to open a firewall connection or require intrusive changes to a corporate network infrastructure. (See note below regarding Service Relay vs. Hybrid Connections)
  • You need to support mobile push notifications from any backend (in the cloud or on-premises) to any mobile platform.
  • You need to integrate with and analyze large volumes of events on a near real-time basis (e.g. IOT, RFID and similar scenarios)

 

Use Service Bus for Windows Server when:

  • Publishers and Subscribers are all on premises.
  • Message transformation or service orchestration are not required
  • Support for B2B integration is not required (AS2, X12, EDIFACT, …)
  • You need to support large Queues/Topics or (up to 50 MB) or Messages (up to 10 GB)
  • You need to support AQMP on-premises
  • Distributed Transactions (DTC) are not required

Use BizTalk (on-premises BizTalk Server or Azure BizTalk Services) when:

  • Brokered application-to-application message-based integration with data mapping and diverse communication mechanisms are required
  • You need to support service orchestration (on-premises) or workflows (cloud)
  • You need to support Content-Based Routing (CBR)
  • Dealing with long-running processes or configurable business rules
  • Implementing B2B standards (e.g. EDI, AS2, X12, EDIFACT others) for multiple trading partners
  • Integration with popular LOB systems (such as SAP) is required 
  • Visibility into integrated processes via BAM is required
  • You need simple, configurable business rules implemented by a broker

Use MSMQ when: 

  • You need to support simple asynchronous communications between on-premises Windows applications
  • Senders and receivers are not running at the same time
  • Message level logging is required
    • MSMQ makes a useful lightweight local transactional queue to support durable messaging when on-prem (especially if you’re using HTTP)
  • You aren't deploying into Azure (MSMQ isn't available in Azure)

 

A note on Service Bus Relays and Hybrid Connections

When connecting from Azure to on-premises Azure Service Bus Relays and Hybrid Connections initially seem to provide similar capabilities.  Service Bus Relay relies upon Service Bus and WCF while Hybrid Connections relies upon BizTalk Services. Here are some simple guidelines on when to use one over the other. 

 

Use Service Bus Relay when:   

  • You need to build hybrid applications that run both in Azure and on-premises
  • You need to enable a hybrid architecture at a lower cost than using BizTalk Services
  • You need to connect to a WCF service using WCF relay bindings
  • You need support for ACS security
  • You need to configure your own listening component or a WCF Service to use a relay binding
  • You need to avoid installing or using a special "agent" to configure and connect to on-premises web services
  • You can only support web service integrations via ACS
  • You need to consume web services from on-premises (not within Azure)

 

Use Hybrid Connections when:   

  • You need to consume on-premises resources (not just web services) from Azure, not from on-premises
  • You need to connect via any port
  • You need to connect to something other than a WCF service (e.g. an application or a database)
  • You need to support Shared Access Signatures
  • You need to integrate with non-.NET technologies in a hybrid architecture 
  • You need to connect to on-premises resources from Azure using BizTalk Services 

 

Scenarios

Service Bus for Windows Server

 

Azure Service Bus

Performance and Scaling

Azure Service Bus (ASB)

 

Service Bus for Windows Server (SBWS)

  • SBWS supports both scale out (add more compute nodes and databases) as well as scale up (add more memory and CPU to the existing nodes). These two main scenarios lead to different approaches: When a Service Bus farm is planned to support many topics and queues each with low\medium throughput, a scale out approach is recommended as you can keep adding databases and nodes. However, when high throughput of small numbers of topics and queues is expected, it is recommended to add more CPU and memory to your existing hosts and database servers.
  • For more details see MSDN for SBWS Performance Considerations

Business continuity   

Azure Service Bus (ASB)

 

 

Service Bus for Windows Server (SBWS)

 

Security

 

Manage

  • Deployment:
    • Azure Service Bus:
    • Service Bus for Windows Server:
      • SBWS runs on-premises and must be installed and configured on a Server 2013 or Server 2008 R2 machine (you can also install it on Win7 or Win8 for individual developer usage). SQL Server 2012 or 2008 is also required (Enterprise or Express versions). OS and application patching and updating must be handled by a local support team. Storage is provided by SQL Server and must be managed by a local support team. Backups and business continuity must be managed by a local support team.
      • See MSDN documentation on Planning and Configuring SBWS
      • See MSDN documentation on Managing Service Bus for Windows Server
      • See MSDN documentation on using Service Bus Explorer with Service Bus for Windows Server

 

 

 

Troubleshooting:

 

Tools and Scripts

 

References and Resources

 

A Service Bus Refresher

12 min read

tldr;

Service Bus is a general term for an integration infrastructure that enables different systems or components to communicate through a shared interface, traditionally implemented as event-driven message queues.   Microsoft supports the service bus pattern across a number of products but this entry will only focus on two of them: Azure Service Bus and Service Bus for Windows Server.  These two products are sometimes simply referred to as "Service Bus" but it's important to realize their differences:

 

  • Azure Service Bus is a generic, cloud-based messaging system for connecting just about anything—applications, services, and devices—wherever they are. Connect apps running on Azure, on-premises—or both. You can even use Azure Service Bus to connect household appliances, sensors, and other devices like tablets or phones to a central application or to each other. 

 

  • Service Bus for Windows Server (SBWS) is a set of installable components that provides the messaging capabilities of Azure Service Bus on-premises. Service Bus for Windows Server enables you to build, test, and run loosely-coupled, message-driven applications in self-managed environments and on developer computers. 

 

Azure Service Bus and Service Bus for Windows Server are wire compatible via BrokeredMessages - this means messages generated by Azure Service Bus can be routed over Service Bus for Windows Server or Service Bus for Windows Server over Azure Service Bus.

 

Azure Service Bus and Service Bus for Windows Server share some common capabilities but also have fundamental differences.  See the sections below for more details on the differences and scenarios on which to use when.

 

Important Note: Service Bus for Windows Server lags behind the SDK support for Azure Service Bus due to the product team's "cloud first" approach. At the time this guidance was written Service Bus for Windows Server SDK was several releases behind the Azure SDK.  See the "Service Bus Releases" section of the Service Bus for Windows Release Notes for more information.  

 

Comparison of Azure Service Bus (ASB) and Service Bus for Windows Server (SBWS)

BrokeredMessages, Queues and Topics

  • ASB and SBWS both support BrokeredMessages.
  • ASB and SBWS both support a publish and subscribe pattern usingqueues andtopics.
    • With queues, each message sent to the queue is consumed by a single receiver.
    • With topics, messages are made available to each subscription registered with the topic. Each subscription logically maintains its own queue of messages. Subscriptions can also be configured with filter rules that restrict the set of messages passed to the subscription queue to those that match the filter.

Installation and support

  • ASB: Since ASB is a cloud-based service there is no software to install and support is provided by the Azure Team. OS and application patching and updating is also handled by the Azure Team. Storage is provided by and managed by the Azure Team. Backups and business continuity of ASB itself is managed by the Azure Team.
  • SBWS: SBWS runs on-premises and must be installed and configured on a Server 2013 or Server 2008 R2 machine (you can also install it on Win7 or Win8 for individual developer usage). SQL Server 2012 or 2008 is also required (Enterprise or Express versions). OS and application patching and updating must be handled by a local support team. Storage is provided by SQL Server and must be managed by a local support team. Backups and business continuity must be managed by a local support team.

Message Relays

  • ASB: ASB’s relay service supports direct one-way messaging, request/response messaging, and peer-to-peer messaging.  The Service Bus relay service enables you to build hybrid applications that run in both an Azure datacenter and your own on-premises enterprise environment.
  • SBWS: SBWS does not support relayed messaging.

Security

  • ASB: Shared Access Signature authentication (SAS) is the preferred way to implement authentication in Azure Service Bus.  SAS enables applications to authenticate to ASB using an access key configured on the namespace or the entity with which specific rights are associated. You can then use this key to generate a SAS token that clients use to authenticate to Service Bus.  See MSDN for more information on SAS tokens
  • SBWS: Solutions deployed on-premises using SBWS can use either Shared Access Signature authentication (SAS) or  Windows integrated security (Active Directory).  Applications can use SAS in scenarios in which they do not need to manage the notion of an authorized "user".  SBWS includes a Service Bus Security Token Service (SBSTS) which is fully integrated with the Windows security model. SBSTS can issue self-signed Simple Web Tokens (SWTs) using Windows identities. 

Quotas/runtime settings

  • ASB: Options regarding message and queue sizes are fixed due to the multi-tenant nature of ASB.  ASB Queue/Topic sizes can be up to 5 GB.  Messages can be up to 256K.  See here for specifics on ASB quotas.
  • SBWS: SBWS provides much greater freedom for configuring runtime settings and message and queue sizes.   SBWS Queue/Topic sizes can be up to 10 GB.  Messages can be up to 50MB.    See here for specifics on SBWS quotas.

Network latency

  • ASB: Network and security latencies may impact performance, especially when moving messages from on-premises to cloud or cloud to on-premises. Throughput could also be impacted by unexpected spikes in unrelated internet traffic.
  • SBWS: Administrators have much more control over their own network’s traffic and routing, thereby enabling more efficient bandwidth usage and throughput.

Addressing schemas

  • ASB: ASB Namespaces are fixed – all endpoints have a Service Bus postfix added to the URL to ensure uniqueness.
  • SBWS: SBWS uses fully qualified domain names (FQDN) or a mapped DNS entry to represent service namespaces.

Instances

  • ASB: In ASB there is only one "instance" of the service available and it is managed by Microsoft.
  • SBWS: With SBWS it is possible to have several on-premises SBWS servers via self-hosted servers or third-party providers.

Notification Hubs

  • ASB: Azure Notification Hubs provide an easy-to-use infrastructure that enables you to send mobile push notifications from any backend (in the cloud or on-premises) to any mobile platform.

 

  • SBWS: SBWS doesn't support Notification Hubs (although Notifications can be sent over SBWS).

Event Hubs

  • ASB: Event Hubs are highly scalable publish-subscribe event ingestors that can intake millions of events per second so that you can process and analyze the massive amounts of data produced by your connected devices and applications.
  • SBWS: SBWS doesn't support Event Hubs (although Events can be sent over SBWS).

 

What to Use When:

 

Use Azure Service Bus when:

  • Building cloud applications or services and requiring a scalable messaging system between components
  • Crossing cloud and on-premises boundary
  • Message transformation or service orchestration are not required
  • Support for B2B integration is not required (AS2, X12, EDIFACT, …)
  • Relaying small messages (256 KB or less), which may contain the payload itself or may be notifications for the availability of larger payloads to process from Azure Storage Blob (see http://msdn.microsoft.com/en-us/library/hh690942.aspx)
  • You need to support AQMP in a cloud or hybrid architecture
  • Distributed Transactions (DTC) is not required
  • You need to build hybrid applications that run in Azure datacenter and on-premises without having to open a firewall connection or require intrusive changes to a corporate network infrastructure. (See note below regarding Service Relay vs. Hybrid Connections)
  • You need to support mobile push notifications from any backend (in the cloud or on-premises) to any mobile platform.
  • You need to integrate with and analyze large volumes of events on a near real-time basis (e.g. IOT, RFID and similar scenarios)

 

Use Service Bus for Windows Server when:

  • Publishers and Subscribers are all on premises.
  • Message transformation or service orchestration are not required
  • Support for B2B integration is not required (AS2, X12, EDIFACT, …)
  • You need to support large Queues/Topics or (up to 50 MB) or Messages (up to 10 GB)
  • You need to support AQMP on-premises
  • Distributed Transactions (DTC) are not required

Use BizTalk (on-premises BizTalk Server or Azure BizTalk Services) when:

  • Brokered application-to-application message-based integration with data mapping and diverse communication mechanisms are required
  • You need to support service orchestration (on-premises) or workflows (cloud)
  • You need to support Content-Based Routing (CBR)
  • Dealing with long-running processes or configurable business rules
  • Implementing B2B standards (e.g. EDI, AS2, X12, EDIFACT others) for multiple trading partners
  • Integration with popular LOB systems (such as SAP) is required 
  • Visibility into integrated processes via BAM is required
  • You need simple, configurable business rules implemented by a broker

Use MSMQ when: 

  • You need to support simple asynchronous communications between on-premises Windows applications
  • Senders and receivers are not running at the same time
  • Message level logging is required
    • MSMQ makes a useful lightweight local transactional queue to support durable messaging when on-prem (especially if you’re using HTTP)
  • You aren't deploying into Azure (MSMQ isn't available in Azure)

 

A note on Service Bus Relays and Hybrid Connections

When connecting from Azure to on-premises Azure Service Bus Relays and Hybrid Connections initially seem to provide similar capabilities.  Service Bus Relay relies upon Service Bus and WCF while Hybrid Connections relies upon BizTalk Services. Here are some simple guidelines on when to use one over the other. 

 

Use Service Bus Relay when:   

  • You need to build hybrid applications that run both in Azure and on-premises
  • You need to enable a hybrid architecture at a lower cost than using BizTalk Services
  • You need to connect to a WCF service using WCF relay bindings
  • You need support for ACS security
  • You need to configure your own listening component or a WCF Service to use a relay binding
  • You need to avoid installing or using a special "agent" to configure and connect to on-premises web services
  • You can only support web service integrations via ACS
  • You need to consume web services from on-premises (not within Azure)

 

Use Hybrid Connections when:   

  • You need to consume on-premises resources (not just web services) from Azure, not from on-premises
  • You need to connect via any port
  • You need to connect to something other than a WCF service (e.g. an application or a database)
  • You need to support Shared Access Signatures
  • You need to integrate with non-.NET technologies in a hybrid architecture 
  • You need to connect to on-premises resources from Azure using BizTalk Services 

 

Scenarios

Service Bus for Windows Server

 

Azure Service Bus

Performance and Scaling

Azure Service Bus (ASB)

 

Service Bus for Windows Server (SBWS)

  • SBWS supports both scale out (add more compute nodes and databases) as well as scale up (add more memory and CPU to the existing nodes). These two main scenarios lead to different approaches: When a Service Bus farm is planned to support many topics and queues each with low\medium throughput, a scale out approach is recommended as you can keep adding databases and nodes. However, when high throughput of small numbers of topics and queues is expected, it is recommended to add more CPU and memory to your existing hosts and database servers.
  • For more details see MSDN for SBWS Performance Considerations

Business continuity   

Azure Service Bus (ASB)

 

 

Service Bus for Windows Server (SBWS)

 

Security

 

Manage

  • Deployment:
    • Azure Service Bus:
    • Service Bus for Windows Server:
      • SBWS runs on-premises and must be installed and configured on a Server 2013 or Server 2008 R2 machine (you can also install it on Win7 or Win8 for individual developer usage). SQL Server 2012 or 2008 is also required (Enterprise or Express versions). OS and application patching and updating must be handled by a local support team. Storage is provided by SQL Server and must be managed by a local support team. Backups and business continuity must be managed by a local support team.
      • See MSDN documentation on Planning and Configuring SBWS
      • See MSDN documentation on Managing Service Bus for Windows Server
      • See MSDN documentation on using Service Bus Explorer with Service Bus for Windows Server

 

 

 

Troubleshooting:

 

Tools and Scripts

 

References and Resources

 

Reactive Extensions, SignalR and WebHooks

2 min read

Reactive Extensions is a library for creating/composing streams of data or events. Rx doesn't deal with network connectivity. Rx only deals with Observables and can wrap any collection, stream, event or async method into a common Observable interface.

SignalR is a communications tool for implementing duplex/real-time connections. It works over HTTP and supports long-polling, server-side events and WebSockets.  SignalR requires requires a constant network connection.

WebHooks are user-defined HTTP callbacks that are useful for communicating event notifications across web apps and external services. Event notifications can be "pushed" in near real-time - no need for polling or a constant network connection.

SignalR, Rx and WebHooks are very different but can be used together. For example, when you receive a WebHook notification from PayPal, you could pop up a toast notification to a user on your webapp via SignalR indicating that a payment was been received.

TLDR;

  • Rx helps you specify what happens but doesn't get into the details of how an event can be communicated.  
  • SignalR enables real-time communications of an event but requires a constant network connection.
  • WebHooks also enable real-time communications of an event but is "web friendly" (doesn't require a constant network connection).