Skip to main content

Durability and Reliability

1 min read

Many people tend to either confuse Durability and Reliability or assume they are the same. This is a quick write up to clarify that these are two fundamentally different yet critical concepts.

Message reliability focuses on the delivery of messages. Message reliability means a message needs to be delivered at least once with possible duplicates or at most once with no duplicates. Reliability also dictates whether messages must be delivered in the same order they were sent or can be delivered out of order.

Message durability focuses on the management of messages. Message durability dictates whether a message can be simply kept in-memory or if it must be saved to persisted storage to avoid message loss (in-memory messages are lost during system, network or power failures). Durable messaging also enables operations to resolve issues in a much easier manner than relying solely upon reliable messaging. When a durable messaging solution experiences an exception or outage it is much easier to determine the state of the transactions and restore/replay messages from a known state without losing any messages.

Note: I've been using this post to test webmentions.

UX is not UI

3 min read

Recycling more bits from an old blog...

Many people seem to confuse UX (User Experience) with UI (User Interface).  These are very different things and confusing the two are likely to result in unhappy users. 

Many people who “design UX” seem to spend the bulk of their time focusing on the screen layout, controls and behavior of various elements on the screen. Many weeks can be spent conducting user studies, analyzing feedback and reviewing various fonts and color schemes in an attempt to provide the most aesthetically pleasing user experience.  These are important things to focus on but something obvious usually goes missing – what about the data?  Where is the data coming from?  How must the data be transformed or manipulated prior to displaying it to the user?  These critical questions are frequently an afterthought as design engineers focus instead upon the look and feel of a given screen.  Focusing on the look, layout and behavior of individual controls on the screen is UI, not UX.  UX should require that designers consider potential latencies due to data retrieval, security and other background processes that impact the overall performance of the user experience.  A beautifully designed screen that performs poorly always results in a poor user experience. 

So how should one design a great UX?  I’m not a UX expert but I’d suggest you start by understanding the data that the screen is to display or work with.  List all of the fields or data elements that the screen must display or accept from the user.  Try to answer the following questions:

  • Where is the data coming from?
  • How long will it take to retrieve the data to display to the user?
  • What relationships (if any) are inherent in the data to be displayed or processed?
  • Is the data in a format that is presentable to the user or must it be transformed?
  • For data entry try to invoke the validation rules as close as possible the actual data entry experience
  • Is it possible to retrieve the data proactively via a background process?
  • How can we “distract” the user while their data is being retrieved/transformed/validated or otherwise processed?

Avoid blocking, especially if the data must be retrieved or processed by a slow/remote network location or an underperforming back end system.  Users have become accustomed to asynchronous experiences – blocking users with an hourglass, spinner or some other form of “dancing monkey” is insufficient. 

Design engineers should work closely with architects or developers to become intimately familiar with the data and its associated service level expectations (SLEs).  Understanding data behaviors can help design engineers avoid designing a Ferrari that performs like a Yugo.

 

A service bus is not a background thread. Just say no to architecture abuse.

Determining the age of a system

1 min read

Determining the age of a system is sometimes like determining the age of a tree: count the rings.

 

 

A Services Lifecycle

4 min read

Recycling some older bits for another test post to Medium.  I've almost got it working but the titles aren't coming through properly...

UPDATE: finally nailed it.  Interestingly enough, the picture below didn't show up on Medium.  I guess it's because I pasted it into my post instead of referencing it directly via IMG tags.

See here for an explanation of what I was doing wrong with the Medium setup. 

This post is a bit old but much of the content is still relevant. 

_________

Services, like applications, participate in a lifecycle in which they are designed, developed, deployed and eventually retired or replaced. 

A Service comes to life conceptually as a result of the rationalization of a business process and decomposition and mapping of that business process into the existing IT assets as wells the new IT assets to fill the gaps. The new IT assets once identified will be budgeted and planned for SDLC activities that result in deployable services (assuming that our goal is to create reusable IT assets).

Following are various important activities that happen (not necessarily in this strict order) during the life time of a service from the service provider perspective:

Service Analysis

Service Analysis is the rationalization of business and technical capabilities with the express notion of enabling them via services. Other aspects such as SLAs, localization / globalization, and basic service contracts will be established for future use in the life cycle.

Service Development

Rationalization of contracts and designing new contracts will be one of the primary activities in this phase. Object libraries supporting the service implementation will be acquired or designed. Security policies, trust boundaries, authentication/authorization, data privacy, instrumentation, WSDL, etc. will be the outcome of this phase. Distributing WSDL or service consumer proxies will be strategized during this phase.

Service Testing

Services will be unit, smoke, functional and load tested to ensure that all the service consumer scenarios and SLA ranges are met.

Service Provisioning

Service metadata as identified in the "Service Consumption" will be deployed into the directory. This will be associated with a deployment record into a repository that models deployment environment. Supported SLA policies will be an important metadata for successful operation of a service. Service gets a production endpoint in an appropriately designed production infrastructure. Support teams will be trained and appropriate processes for support among various roles (business versus IT) will be established. Access to service consoles and reports will be authorized to these roles.

Service Operation

This is the most important activity since the ROI will be realized through the operation of the services in production. The management infrastructure will do the following:

  • Service Virtualization

  • Service Metering (client usage metering and resource metering)

  • Dynamic discovery of service endpoints

  • Uptime and performance management

  • Enforce security policies (authentication, authorization, data privacy, etc.)

  • Enforce SLAs based on the provisioning relationship

  • Generate business as well as technology alerts for a streamlined operation of the service

  • Provide administrative interfaces for various roles

  • Generate logs and audit trails for non-repudiation

  • Dynamical provisioning (additional instances of the service as necessary)

  • Monitor transactions and generate commit/rollback statistics

  • Integrate well with the systems management tools

  • Service, contract and metadata versioning

  • Enforce service decommissioning policies

  • Monetization hooks

  • Reporting

Service Consumption

This activity is equally applicable to service consumers and providers as providers may consume services as well. During this activity, services will be discovered to understand the following:

  • Service security policies

  • Supported SLA policies

  • Service semantics (from the lifecycle collateral attached to the service definition)

  • Service dependencies

  • Service provisioning (will be requested by the consumer)

  • Pre and post-conditions for service invocation

  • Service development schematics (proxies, samples, etc.)

  • Service descriptor artifacts

  • Service impact analysis

  • Other documentation (machine readable as well as for human consumption

During this activity, service consumers will be authorized to discover the service and its metadata. SLAs will be pruned to meet the desired level of availability based on the negotiated contract.

Service Change Management

Service like any IT application asset will go through several iterations during its lifetime. Service contracts will change, service security as well as SLA policies will change, the implementation will change, and the technology platform may change. Some of the above changes may be breaking changes. So, the management infrastructure has to be resilient for all the mutations by providing necessary deployment support across all the above changing dimensions.

Service Decommission

As a result of a change in the business strategy or as a result of better alternatives or as a result of waning consumer interest, a service may be decided for decommissioning. Management infrastructure should be able to enforce retirement policies by gracefully servicing the consumers until the last request.

 

 

What is Modern Architecture?

2 min read

Last re-post to test integration with Medium...

I'm hearing the term "modern architecture" used quite a bit but haven't seen much clarification about what it actually means.  Here are some principles and capabilities that I would expect to see in "modern architecture":

  1. Cloud first
  2. Loosely coupled, distributed services
  3. Support Postel's Law
  4. Distributed storage and caching
  5. Weak/Eventual Consistency (CAP) - committed reads
  6. REST APIs where appropriate
  7. Scale out, not up
  8. Stateless
  9. No apparent downtime
  10. No biz logic in sprocs (prefer no sprocs at all)
  11. No ref integrity in db - enforce in service/app if needed
  12. No distributed txns
  13. Simple data abstractions for data access
  14. Multiple service versions in production 
  15. Active-active failovers across DCs where appropriate
  16. No singletons, at least 4 instances of a service running in prod (2 per DC)
  17. Consistent approach to monitoring/logging/SLE threshold compliance•
  18. Real-time access to service health/activity
  19. Design for/expect failure - degrade gracefully
  20. Test in production
  21. No reporting from txn data - keep OLTP and OLAP separate
  22. Asynchronous user experiences (no blocking)
  23. Avoid designing for a single device or form factor (user-scalable=0 is evil)

I'll plan to drill into more detail on several of these topics over the next couple of posts.

What do you think is missing from this list?  What shouldn't be in this list?

 Updates:

  • Mike Kavis suggested via FB that "Modern solutions have a combo of SQL, nosql, cache, CDN, and many other data and storage technologies under the hood".  I'd interpret this as: Data stores should be abstracted without regard to where/how they should be accessed.  The abstraction hands off to a more granular access component/service with specific awareness to location/access requirements/etc.

 

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

 

"Modern Apps" - I Know It When I See It

1 min read

I really dislike using the term 'modern app' when describing architecture because it lacks a clear definition. If you ask three different architects what a "modern app" is you're likely to get three or more different perspectives on it.

Much like SOA or art, some people know it when they see it but have difficultly describing it clearly.

I took a shot at this quite a while ago here on my old MSDN blog.  

 

 

 

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 using queues and topics.
    • 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

 

/sub