Message queueing to provide application scalability has been a common pattern for decades. In the last few years a new term has been coined — Internet of Things (IoT) that puts a brand name over highly scalable message-based computing.
Why is IoT a thing?
The emergence of the IoT “brand” demonstrates that a pattern needed in perhaps 1% of use cases in the past is becoming mainstream. In a world where smartphones are used by the majority of consumers, computing systems that support transactions from thousands of remote devices are more common.
20 years ago, a message queueing pattern would be implemented in a traditional, on-premises technology. For example I used Microsoft Message Queuing (MSMQ) “back in the day”, i.e. with Windows NT 4.0. Today, it makes a lot of sense to use a public cloud provider like Microsoft Azure or Amazon AWS to implement application message queues, since these services are more cost effective and scalable than on-premises alternatives.
Why use a Queuing pattern?
Almost any system that has more clients than servers can generate spikes in volume that exceed the ability of back-end resources. Anyone who has been stuck in a customer service hold queue has experienced a supply/demand imbalance which has been mitigated through the use of queuing. For most customers, hold music is preferable to a busy signal, and technology makes that happen.
For an IoT or mobile device architecture, it’s basically the same problem with the same solution. Following the call center analogy, the “callers” in the IoT scenario may be mobile devices, industrial sensors or thermostats. The “call center agents” are event processors that pick up application messages, read the data contained in them, update databases, send notifications, and/or conduct streaming analysis.
Queue/Event Architecture Diagram
The following diagram illustrates a general model of an IoT processing architecture that utilizes a public cloud provider’s infrastructure.
I’ve differentiated between “Message” queues and “Event” queues, as these highlight overlapping but different use cases. Both AWS and Azure provide differentiated services as well, which I’ll discuss below.
In the diagram above, transactions are sent by a potentially large number of client devices. Without a message queue architecture, the solution architect needs to scale back-end web front ends and databases to meet peak demand at all times. That can get (really) expensive!
Message Queue Processing
Historically, the message queue architecture has been used to model transaction flows that needed to be highly consistent and reliable, but don’t necessarily need a realtime response of 10–20 milliseconds. Typically we’d want to be sure that every message arrived without fail, the sequence of processing was perfectly FIFO, that confirmations or responses were dispatched on return queues, etc. This is a “message queue” use case, and is important for many use cases.
What if the use case is more “event” oriented? If the application sends a stream of navigation clicks within an application, what’s the response? There isn’t one, is there? This might also be true if the application is to stream temperature or rainfall measurements. These are all events that require no response at all — maybe a simpler architecture would be more appropriate?
Indeed, as IoT has surfaced, a lot more emphasis has been placed on processing events, and products specifically targeted for event processing have become common place.
But is there an advantage to a technology specifically geared to event processing? The answer is yes — an event processing system is less expensive to provision and operate. Maybe 90% less expensive!
Public Cloud Offerings
Public cloud infrastructures invariably support message and event processing services. The two most popular services — AWS and Azure — have specific offerings for both Message Queue and Event processing.
AzureAWS Application Message QueuingAzure Service BusAmazon SQS Event QueuingAzure Event HubAmazon Kinesis
Each cloud provider has somewhat different approaches, but in general message vs. event use cases differentiate the most appropriate service selection. Selecting the right service is important to meet application needs appropriately, as well as keeping operating costs minimized.
Want to learn more about cloud message queues and event processing? Check out these other excellent articles: