Subscribe! (HD) - Channel 9

This is the final part of a 6 part series introducing the AMQP 1.0 protocol, covering composite types and messages, and the frame layout.The AMQP 1.0 protocol is used by Azure Service Bus, Service Bus for Windows Server, Azure Event Hubs, Azure IoT Hub, and by numerous open source projects like Apache Qpid, Apache ActiveMQ, and Apache Apollo, as well as by commercial messaging products of other vendors like JBoss A-MQ, RedHat MRG, SwiftMQ, and IBM MQLight.The content of this video series is product neutral and applies to all AMQP 1.0 based infrastructure and applications.Part 1 - Part 2 - Part 3 - Part 4 - Part 5 - Part 6

This is part 5 of a 6 part series introducing the AMQP 1.0 protocol, explaining the type system basics and the encoding of primitive types.The AMQP 1.0 protocol is used by Azure Service Bus, Service Bus for Windows Server, Azure Event Hubs, Azure IoT Hub, and by numerous open source projects like Apache Qpid, Apache ActiveMQ, and Apache Apollo, as well as by commercial messaging products of other vendors like JBoss A-MQ, RedHat MRG, SwiftMQ, and IBM MQLight.The content of this video series is product neutral and applies to all AMQP 1.0 based infrastructure and applications.Part 1 - Part 2 - Part 3 - Part 4 - Part 5 - Part 6

This is part 4 of a 6 part series introducing the AMQP 1.0 protocol, describing the flow control models.The AMQP 1.0 protocol is used by Azure Service Bus, Service Bus for Windows Server, Azure Event Hubs, Azure IoT Hub, and by numerous open source projects like Apache Qpid, Apache ActiveMQ, and Apache Apollo, as well as by commercial messaging products of other vendors like JBoss A-MQ, RedHat MRG, SwiftMQ, and IBM MQLight.The content of this video series is product neutral and applies to all AMQP 1.0 based infrastructure and applications.Part 1 - Part 2 - Part 3 - Part 4 - Part 5 - Part 6

This is part 3 of a 6 part series introducing the AMQP 1.0 protocol, describing message transfers and disposition.The AMQP 1.0 protocol is used by Azure Service Bus, Service Bus for Windows Server, Azure Event Hubs, Azure IoT Hub, and by numerous open source projects like Apache Qpid, Apache ActiveMQ, and Apache Apollo, as well as by commercial messaging products of other vendors like JBoss A-MQ, RedHat MRG, SwiftMQ, and IBM MQLight.The content of this video series is product neutral and applies to all AMQP 1.0 based infrastructure and applications.Part 1 - Part 2 - Part 3 - Part 4 - Part 5 - Part 6

This is part 2 of a 6 part series introducing the AMQP 1.0 protocol, discussing the core protocol elements, Connections, Sessions, and Links.The AMQP 1.0 protocol is used by Azure Service Bus, Service Bus for Windows Server, Azure Event Hubs, Azure IoT Hub, and by numerous open source projects like Apache Qpid, Apache ActiveMQ, and Apache Apollo, as well as by commercial messaging products of other vendors like JBoss A-MQ, RedHat MRG, SwiftMQ, and IBM MQLight.The content of this video series is product neutral and applies to all AMQP 1.0 based infrastructure and applications.Part 1 - Part 2 - Part 3 - Part 4 - Part 5 - Part 6

This is part 1 of a 6 part series introducing the AMQP 1.0 protocol. Part 1 - Part 2 - Part 3 - Part 4 - Part 5 - Part 6The AMQP 1.0 protocol is used by Azure Service Bus, Service Bus for Windows Server, Azure Event Hubs, Azure IoT Hub, and by numerous open source projects like Apache Qpid, Apache ActiveMQ, and Apache Apollo, as well as by commercial messaging products of other vendors like JBoss A-MQ, RedHat MRG, SwiftMQ, and IBM MQLight.The content of this video series is product neutral and applies to all AMQP 1.0 based infrastructure and applications.The slide deck can be downloaded from here.

IoT Solutions World Congress 2015 was held in Barcelona (Spain) last week. On a VERY NOISY showfloor, I spoke to Nicole Berdy (@nberdy) about the Azure IoT Suite, and to Colin Murphy about Windows 10 IoT Core.

With the advent of the public preview of Azure Service Bus Premium Messaging, it's time for a fresh Service Bus Messaging overview talk here on Subscribe.This episode covers some of the motivations for why and how messaging middleware helps in applications, enumerates the different deployment and operations choices for Service Bus, gives a basic overview on capabilities, and provides information on the failover and reliability architecture and the isolation model for the two major public cloud offerings for Azure Service Bus, "standard" and "premium".More details on Service Bus can be found on the Azure Portal.

Azure Service Bus is the core messaging platform that sits at the heart of many sophisticated Azure-based solutions today.Azure Service Bus Premium Messaging is a new offering, now entering public preview that builds on the successful and reliable foundation of Service Bus Messaging. Premium Messaging provides a number of key enhancements for greater predictability and performance required for the most demanding workloads – paired with an equally predictable pricing model.With Service Bus Premium Messaging, you benefit from the economics and operational flexibility of a multi-tenant public cloud system, while getting single-tenant reliability and predictability.The announcement blog post is on the Azure blog, and you can find out more about pricing on the Service Bus pricing page on Azure.com, in the "premium" column.You can create new premium messaging namespaces in the new Azure portal right now and give the public preview a try (click "Create" in the menu bar across the bottom of the portal page).And if you want to learn more about Azure Service Bus Messaging, there's a new 40 minute episode here on Subscribe that goes into more detail on Messaging in general and Premium Messaging in particular.

After a long hiatus, the Subscribe blog is back on here on Channel 9!In this "reboot" episode, Dan (@DanRosanova) and Clemens (@ClemensV) talk about what's next in Subscribe and in Service Bus and Event Hubs and about some REALLY BIG numbers.

"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 suggesting fossil-fueled systems to throttle CO2 output – or, more simply, a car may want to show weather or news alerts or text messages to the driver. The Arduino device code used in the video is in this Gist https://gist.github.com/clemensv/6367476[Part 1] [-> Part3] [Part 4] [Part 5]

Subscribe! is back after a long mid-year (summer-) break and with a new series.Starting with this episode, I'm going to explore a range of embedded systems prototyping platforms and, ultimately, how to connect tiny devices into the cloud for fun, scale, and security. We'll explore how to establish basic connectivity, discuss security options, talk about how to flow and handle telemetry data and how to do remote switching like turning a motor or switching a light from the cloud and do that in a way that it would scale to very, very many devices and poor connectivity conditions.Prototyping platforms allow hobbyists, researchers, and industrial design engineers to explore designs, and wire up and easily program special-purpose devices without soldering or even having to make a printed circuit. Once the design is stable, the prototype can then be turned into an actual device that can be produced at scale.In today's episode I'm going to give an overview of the prototyping platforms I'm going to explore in the upcoming few weeks. I'm initially going to focus on platforms that are cheap to buy and have existing communities, so that you can play along if you like: Arduino, Gadgeteer, Netduino, Android ADK, Seeedstudio Grove, and Raspberry Pi. Later this year, we'll also take a look at prototyping/evaluation platforms for industrial microcontrollers.Today and in the next few episodes, I'll be starting with the Arduino Ethernet board, which I bought as part of a Fritzing Starter Kit. Fritzing.org is an open-source hardware design initiative by the Interaction Design Lab at the University of Applied Sciences in Potsdam, Germany. [Go to Part 2 or Part 3 or Part 4 or Part 5]

"Internet of Things" ist dieser Tage eines der vieldiskutierten Schlagworte in der Softwareindustrie. Bei "IoT" oder auch Maschine-zu-Maschine Kommunikation (M2M) dreht es sich allgemein um die direkte und indirekte Verbindung von zweckgebundenen Geräten wie Waschautomaten, Geschirrspülern, Toastern, oder auch Lokomotiven, LKWs und Werkzeugmaschinen an das Internet.Wir, Microsoft, sind in den vergangenen Monaten von einer steigenden Anzahl von Kunden in diesem Bereich zu Rate gezogen worden. Diese Kunden aus der fertigenden Industrie kommen zu uns mit einem oft langjährigen Erfahrungsschatz in der Automation und Sammlung von Telemetriedaten zu ihren Produkten, sehen sich allerdings vor beträchtlichen Problemen, mehrere zehntausend oder auch Millionen von Geräten gleichzeitig an einem föderierten System zu betreiben, bidirektionale Kommunikation herzustellen, und die Informationsflut zu beherrschen..Diese Episode hier auf "Subscribe!" ist die deutschsprachige Version der ersten Episode zu diesem Themenbereich, und dreht sich um IoT/M2M im Allgemeinen, die Kommunikationspatterns, und um die Verbindungsoptionen und -problem wobei ich spezifisch auch auf VPN und die damit verbundenen, aber leider nicht offensichtlichen Probleme eingehe. Mehr zum Thema [Englisch]:June 2012 MSDN Magazine "Using Service Bus for Things" (must read) July 2012 MSDN Magazine "A Smart Thermostat on the Service Bus" Internet of Things: Is VPN a False Friend? AMQP Support in Windows Azure Service Bus

"Internet of Things" is one of the hot catchphrases of the industry these days. It's about connecting special-purpose devices (laundry machines, dishwashers, toasters, locomotives, trucks, factory robots, etc.) directly or indirectly to the Internet. As things go, several commercial customers have nudged us in the direction of taking a good, long look at this space and we're already actively helping several of them to deal with the particular scale challenges of needing to connect tens of thousands or more devices concurrently and with bi-directional information exchange. This is the first in a series of episodes I'll do on the IoT/M2M subject area here on "Subscribe!" and in this first one, I'm introducing the problem space, talk about patterns, and am talking about the connectivity options and challenges around devices, specifically also discussing VPN.More on the subject:June 2012 MSDN Magazine "Using Service Bus for Things" (must read) July 2012 MSDN Magazine "A Smart Thermostat on the Service Bus" Internet of Things: Is VPN a False Friend?

Glenn Block and crew have been working on making Node.js' real-time eventing Socket.io library scale across nodes (machines) with the help of Service Bus. Talking to and hearing Glenn talk is always fun, so I hope you'll enjoy this.

In this episode, our identity wizard Vittorio Bertocci (you can identify true wizards by the long hair, even though most other wizards carry that hair under the chin) explains Windows Azure Active Directory and its role in the Windows Azure platform.