"Smart Products and Microsoft Services" (you could also say "Internet of Things with Microsoft Datacenter Services") is the topic of this very long, 110 minute presentation. But before I'll let you watch it, allow me to apologize for completely skipping the first quarter of 2014 here on Subscribe!Happy New Year! It's been a busy time here in my basement in Germany and over in Redmond and on the road, and to make up for the long drought, I recorded an extended director's edition of the "Smart Products and Microsoft Services" talk I gave at the CeBIT trade show and several other conferences in recent months and also added a section about "Project Reykjavik" that I've been working on (and which is the reason for the long break) and that Todd first mentioned and showed in his BUILD talk last week. I don't have a demo in this talk, but I'll have that coming up soon. The video is probably really too long, but the upside of the videos here on Channel 9 are that you can pause it when the popcorn bag is empty and you need to get a new one. The scenarios I talk about are about Public Transportation systems and Connected Car, and you may recognize the transportation scenario from my "Internet of Things or Thing on the Internet" blog rant. I also give a refresher on Service Assisted Communication in the context of the Reykjavik discussion. The PowerPoint deck for this presentation is here.

This is the last (numbered) episode in this series and I'm showing you the code that runs on the Pi in my car as well as the server side code that pumps the data into storage. Mind that the code is built for demo/explanation purposes, so it's not as robust as production code would be and it's missing retry and failure detection logic. GitHub repo https://github.com/clemensv/D2C-RPi-OBDLogger Startup Script: https://gist.github.com/clemensv/7928218 Qpid Proton: http://qpid.apache.org/index.html (GitHub https://github.com/apache/qpid-proton)OBDGPSLogger Original http://icculus.org/obdgpslogger/ See you next year with a new set of episode and have great holidays!

In this episode I'll show you the Raspberry Pi that lives in my car and some other nice things that a latest-model vehicle (from Audi in this case) can do with built-in online data services, such as getting much more frequent traffic data updates that give you the all-important 10-minute information edge over radio-signal based services when avoiding the just-formed traffic jam ahead.

Today we're releasing Service Bus for Windows Server 1.1. Ziv Rafalovich gave me (and you) a tour through one of the most exciting additions we for the server version, the new Windows Azure Pack portal. For background on Service Bus for Windows Server 1.1 read this blog post by Brad Anderson and then go grab the bits. The best way to do that is to get it as part of Windows Azure Pack, but you can also install the Service Bus 1.1 runtime standalone. Both you can do with the Web Platform Installer.

In this 6th episode of my Device to Cloud series, which is another whiteboard talk, I'm talking about why application-level security matters in typical M2M scenarios where, for instance, sensors pick up environmental data and control systems react on that input and take action. Security approaches that merely focus on providing a secure tunnel separating "this" system from the rest of the world, or are even further segregating traffic at the lowest layers of the network, are not a sufficient solution if the underlying networks are not fully trustworthy (that includes public mobile operator networks) and/or there is any risk of 3rd party interception and manipulation inside such a segregated network zone, for instance by foreign malware intrusions and in the infamous Stuxnet case. The best way to deal with network-level foul play is to pull the responsibility for privacy, integrity, and identity up to the application layer or to at least tie these concerns into the application layer from the underlying network layer. [Part 1] [Part 2] [Part 3] [Part 4] [Part 5]

Last week I had the chance to speak with Tier3 Product Manager, Microsoft MVP, InfoQ editor, Pluralsight trainer, and conference speaker Richard Seroter (@rseroter) on Lync. Richard is using Windows Azure Service Bus for Integration scenarios and in this episode he shows how you can integrate your own on-premises (or even cloud-based) services with one of the most popular SaaS applications, Salesforce.com [And you can obviously also employ the same sorts of patterns with the also-awesome Microsoft Dynamics CRM, if anyone were wondering]

Before attending two recent M2M conferences in Düsseldorf and Berlin, I probably wouldn't have recorded this episode. But as I see it, there's quite a bit of fear-driven "black magic" security pixie-dust applied to industrial scenarios in form of stacking up layers of hardware boxes, and "VPN" is often used and understood as a synonym for a comprehensive security solution, while vendors in this space who don't use VPN and rely on straightforward direct and secure connections are met with skepticism. So in order to get everyone who follows the series on the same level of understanding, this 5th episode is specifically for the folks on OT (operational technology) side of the IT/OT divide. I'm talking about VPN and what it is and what it isn't, how it adds security and how it doesn't, and I'm talking about the range of link, network, and transport layer security protocols that readily available for solutions today and that you're likely relying on these exact protocol suites with any VPN solution you buy magic hardware boxes for. If you're in IT, you may like this as a refresher. In the next episode I'll cover the next set of security aspects like authentication and authorization, so you get one more security theory episode than I though I'd do. [Part 1] [Part 2] [Part 3] [Part 4] [Part 6]

In this 4th episode of my "device to cloud" series I'm introducing the notion of intermediated service-assisted connectivity for devices, whereby the gateway I introduced in the previous episodes gets split into an API layer that device controllers speak to through HTTP(S) and a protocol head layer that the device connects to and those two layers are interconnected with a set of queues. The added benefits of using this model is the ability to scale the two layers independently, it allows for load-balancing in both layers and it greatly improves the reliability of the overall communication path, including allowing to send commands or notifications to devices that are either connected through wireless radio links that may be occasionally degraded or unavailable for short periods of time or that are simply not always turned on. The code for the episode can be found at https://github.com/clemensv/D2C-Ep4-LedBlinker [Part 1] [Part 2] [Part 3] [Part 5]

In this third episode of my cloud-to-device series, I'm talking in some more detail about why it is a questionable and sometime outright dangerous strategy to let small devices actively listen on a network and, through that, open itself up to unsolicited traffic it needs to triage and secure. As a counterproposal I'm showing a very simple model for how to create a much safer way (even if not yet truly secure, we'll get to the in future episodes) of exposing a device to public network consumers - through use of a cloud based gateway that acts on behalf of the device and does a lot of the heavy lifting in terms of protocol implementation but also for defense against unwanted traffic. The code for this episode can be found here: https://github.com/clemensv/D2C-Ep3-LedBlinker [Part 1] [Part 2] [Part 4] [Part 5]

In this second episode of the (open-ended) device-to-cloud series, I'm talking about the four basic patterns of device information exchange and then start investigating the trickiest of these patterns, Commands, using a simple HTTP web service on the Arduino Ethernet board. The four basic patterns are Telemetry, Inquiries, Commands, and Notifications. Telemetry is the flow of information about the current or temporally aggregated state of the device or the state of its environment (e.g. readings from its sensors) from the device to some other party. The information flow is unidirectional and away from the device. Inquiries are questions that the device has about the state of the outside world based on its current circumstances; an inquiry can be a singular query akin to a database lookup, but it might also ask a service to supply a steady flow of information. For instance, the aforementioned toaster will ask for the weather and get a singular response, but a vehicle might supply a set of geo-coordinates for a route and ask for continuous traffic alert updates about particular route until it arrives at the destination. Only the former of these cases is the regular request/response case that HTTP is geared towards. Commands are service-initiated instructions sent to the device. Commands can tell a device to send information about its state – either as a point-in-time observation or over continuously some period – or to change the state of the device, including performing activities with effects in the physical world. That includes, for instance, sending a command from a smartphone app to unlock the doors of your vehicle, whereby the command first flows to an intermediating service and from there it's routed to the vehicle's onboard control system. Notifications are one-way, service-initiated messages that inform a device or a group of devices about some environment state they're otherwise not aware of. Cities may broadcast information about air pollution alerts sugges