It's very likely that you have never even used a service like Microsoft Azure so we will start off with a bit of a crash course. Obviously we won't be covering everything (that's what the hours and hours of online material is for) but instead focusing on what exactly we are doing. This way you're not simply building a black box and have no idea that magic happening behind the scenes, but rather a high-level conceptual understanding. This will allow you to expand on it in the future, and also understand the purpose behind why we are using Azure versus another service.

Why Azure?

Why not Node.js? That's probably a question a lot of you will be asking, and it's a very legitimate question. Why not just create a basic REST server that we can hit to command our devices? Well the issue is that we live in the future, and the future is all about the Internet of Things (IoT). IoT deals with tens if not hundreds of little devices all around your home, all connected giving you unparalleled control. Will a simple Node server running on a Pi be able to handle all of that? Isn't dealing with all of that funky server code another guide (if not an entire book) in it's own right? Yes, yes it is, and that's why Azure is here to the rescue. While we really won't see the benefits of Azure in this initial guide because we are only hooking up one device, once we begin to hook up more and more devices we will be able to see the true benefits.

What Will We Be Making?

For our project, we're going to make a Service Bus that will process Topics and Subscriptions. Don't worry, I know we're throwing a lot of fancy words around early, but I assure you that it doesn't take long to get a basic understanding. A Service Bus, in a nutshell, provides a highly robust messaging framework that serves as a relay between two (or more) endpoints. It is essentially the magical 'cloud' that we hear so much about. Something sends it a message, it decides where that message should go, sends it, and another device gets that message. The service bus is our mail sorting facility, make sense?

So what about these Topics and Subscriptions? Why can't we just call them messages? Well, because it's not quite that simple. A Topic contains a message, but you can't say that a Topic is a message. It's just incorrect. So what is a Topic then? A Topic forms a relationship (both logical and physical) between publishers and subscribers so that a publisher (Cortana) can publish messages to multiple subscribers (all of our IoT devices). Think of it this way: Say we had 10 different IoT devices all around our home, all hooked up to different light switches. When we give the command "Turn the Lights Off" we want to send a message to each and every IoT device telling it to turn off, but we don't want to send 10 different messages. Furthermore, how much of a pain is it that every time we add an IoT device we need to re-code our entire Cortana logic? Instead, we publish a message to the Topic "LightControls" and that Topic now publishes to all subscribers (which would be every IoT device that controls a lightswitch) to go to the "OFF" position.

Still Confused? Don't worry, this isn't something that's easy to pick up (let alone explain) in a paragraph or two. If you still want to learn more, here are some great resources:

Introducing Queues and Topics in Azure Service Bus - Code Magazine

How to User Service Bus Topics/Subscriptions - Microsoft

Windows Azure Service Bus Topics and Subscriptions - Neudesic

In a Nut Shell...

Cortana is going to send a message to a Topic on the Service Bus (the cloud). Our Cloud will then send that message to every device that has "subscribed" to that topic. So when we send "DeskLightsOff" to the "LightControl" Topic, our DeskLights will have Subscribed to it, will receive it, and then will process that command.