In the current, March issue of MSDN Magazine, you can read Bruno Terkaly and Ricardo Villalobos’ latest Windows Azure Insider column, titled “The Windows Azure Service Bus and the Internet of Things, Part 2.” The column dives into the specifics of machine-to-machine (or M2M) computing and offers a hands-on look at how Windows Azure and the Windows Azure Service Bus can be used to enable streaming, capture and processing of the constant flows of data among remote devices and controllers.

As the authors conclude near the end of this month’s column: “Building an Internet-of-Things (IoT) architecture using the Windows Azure Service Bus to manage devices and services connections provides an easy way to secure, scale and address clients individually without incurring costly VPN solutions, with the benefit of efficiently handling occasionally disconnected scenarios.”

Part 1 in the series ran in the January issue of MSDN Magazine, and offered a great, high-level introduction to the challenges and opportunities presented by the IoT, and presented four patterns that can be used on the client to communicate with a cloud service. The January column proved a major hit, drawing more Web page views in the first month of publication than any Windows Azure Insider column to date. Given the interest in the IoT among Windows Azure column readers, I reached out to Ricardo with a few questions.

Your part 1 column on the Internet of Things has recorded more page views in its first month than any Windows Azure Insider column yet published. What do you think is behind the strong readership?

Timing, and the lack of information about this topic in the official documentation. Interconnecting devices is a hot topic in every single industry right now. The fact that a public cloud can be used to support these scenarios is extremely attractive. We have said for many months that the Service Bus is the most underused and least understood feature inside Windows Azure. Now that the industry is finding a good application for it, the interest has skyrocketed.

You make the point that VPN is not a good approach for security in IoT scenarios, in part because remote VPN endpoints that get compromised can pose a threat. Can you talk more about this issue?

The biggest concern around using a VPN to connect devices is none other than security, based on the level of device isolation that it provides. You can go here to find a full discussion of this topic from Clemens Vasters, who worked very closely with us to create the article. Having said this, it’s also nice – as a developer – to use a platform that supports occasionally connected scenarios using queues and topics (something VPN generally does not).

You make a compelling case for Windows Azure and its various infrastructure elements as a solution for IoT-focused scenarios. Can you talk at all about coming improvements in this arena?

We are constantly enhancing the platform and adding new features around messaging and orchestration. One of the most popular requests is a component that would allow developers and architects to schedule specific actions triggered by events. Based on this, we have created the Windows Azure Scheduler, currently under preview. More information can be found here.

A couple questions from readers of the first column. First, Uri Kluk asks: For cellular base devices, how is the TCP connection always open? Does the AMQP client require flowing keep-alive traffic? How many concurrent connections can Service Bus handle?

One, if you use Service Bus queues, a permanent TCP connection is not required. Commands and messages can be queued up for a delayed delivery, with the option of attaching an expiration date/time to them. We show an example of this in our March 2014 column.

Two, by default the Service Bus client library communicates with the Service Bus service using a dedicated SOAP-based protocol. Now that the AMQP protocol is offered as an alternative, functionality is similar for AMQP clients. Keep in mind some of the current limitations if using this approach.

Three, Service Bus can handle up to 2,000 messages per second.

Another question, from Dan-W: Why not include the NETMF and Gadgeteer systems (with the Arduino and Raspberry PI) when discussing micro devices? .NET Micro Framework is very powerful, plus its C#/.NET.

One of the objectives of our MSDN Magazine column is to demonstrate the openness of Windows Azure by incorporating examples of interconnectivity with other devices and platforms. Of course, we would like to show examples of this pattern working with the .NET Micro Framework. If you decide to follow the example that is published in the March issue and share your experience with us, please let us know.