Hubs, Sharding and Partitioning
It seems there is a some misunderstanding related to sharding and partitioning when talking about IoT and Microsoft Azure platform. Here is my recommendation about how we should thnk about this. EventHub uses internally messaging feature called 'partitioning'. To understand how that works I would recommend to read more about this in context of service bus. It basically enables multiple message brokers instead of a single one. So, this is called partitioing even if some people might call this shrading. IotHub also uses same (or similar) technic as EventHub. However, when we talk about IotHub 'shards' we do not think about partitioning on message level. It is rather using of multiple IotHubs inside of same solution. This is not some specific technology under the hub. To use multiple IotHubs inside of a single solution, You should decide how device provisioning is done. Dev1-Hub1, Dev2->Hub2 etc.Azure IoT supports new security hardware to strengthen IoT security
Microsoft’s commitment to leadership in IoT security continues with Azure IoT’s improving the level of trust and confidence in securing IoT deployments. Azure IoT now supports Device Identity Composition Engine (DICE) and many different kinds of Hardware Security Modules (HSMs). DICE is an upcoming standard at Trusted Computing Group (TCG) for device identification and attestation which enables manufacturers to use silicon gates to create device identification based in hardware, making security hardware part of the DNA of new devices from the ground up. HSMs are the core security technology used to secure device identities and provide advanced functionality such as hardware-based device attestation and zero touch provisioning. In addition, Azure IoT team is working with standards organizations and major industry partners to employ latest in security best practices to deploy support for a wide variety of Hardware Secure Modules (HSM). HSMs offer resistant and resilient hardware root of trust in IoT devices. The Azure IoT platform transparently integrates HSM support with platform services like Azure IoT Hub Device Provisioning and Azure IoT Hub Device Management, thereby enabling customers and developers to focus more on identifying specific risks associated with their applications and less on security deployment tactics. Read about it on the Azure blog.Extend Azure IoT Hub with a watchdog using Azure Functions
Once you are working with the Azure IoT platform, there comes a moment where you want to add notifications. In a previous blog, we looked at how to send notifications when telemetry values did not match certain ranges. Although this is great, there are even more cases where we want notifications. Here I am referring to watchdog functionality. When no telemetry is arriving anymore or devices are disconnected, the complete IoT platform is not working as designed. So we want to be informed when something fails. In this blog, we will build a simple watchdog using Azure Functions. Read the full story hereIntroduction to the microsoft/azureiotedge-modbus-tcp IoTEdge Module
The newest version of the Azure IoTEdge solution is a very promising platform. The combination of remote provisioning the modules, the power of twin configuration and the new routing is interesting. But the learning curve is pretty steep. The first version was based on programming an application. The new version is based on docker images, each being a separate application, which has to be stored in the container registry of your choice (like Docker Hub or your own container registry in Azure. So once you have learned how to build and deploy your own modules, you can check out the modules Microsoft already supplies. One of these modules is a Modbus module. It's available at the Docker Hub of Microsoft. Modbus is a great protocol for highspeed communication over TCP and I have already blogged about it, using the previous IoTEdge SDK version. Let's check out how we get some telemetry from it. Read the full article hereDirect methods support in the IoT Hub Connected Service
The Visual Studio 2017 Connected Service for Azure IoT Hub has received an update a couple of months ago. This update had some visual updates and now supports a Singleton pattern for the Device client too. But it also included support for both Device twins and Direct Methods. The latter feature looks a lot like the Commands method but there are some fundamental changes. Yes, both solutions (Command and Direct Method) can execute code on a remote IoT Hub client. But the remote method just passes a message to the client. The Direct method can pass a message in a certain context. It calls a specific method (a client can have multiple methods registered) and passes the JSON parameter. If you execute a Command, it feels like fire-and-forget. There is no descriptive response. But the caller of a Direct Method can wait until a response is accepted and a JSON value is returned. Let’s check out Direct Methods. It all starts with that Connected Service extension in Visual Studio 2017. Read the full story hereAnnouncing support for X.509 CA on Azure IoT Hub
We’re pleased to announce support for X.509 Certificates Authorities (X.509 CA) on Azure IoT Hub! The use of X.509 CA simplifies the creation of initial unique Internet of Things (IoT) certificate identities for devices in the device manufacturing flow. Instead of pre-creating the identities for every device and having to protect associated secrets during manufacturing, the use of X.509 CA simplifies the flow into two, one-time processes for the certificate owner. Read about it in the Azure blog.Azure IoT Hub Device Provisioning Service preview automates device connection and configuration!
Today we're announcing the public preview of the Azure IoT Hub Device Provisioning Service! The Device Provisioning Service is new service that works with Azure IoT Hub to enable customers to configure zero-touch device provisioning to their IoT hub. With the Device Provisioning Service, you can provision millions of devices in a secure and scalable manner, automating a process that has historically been time and resource intensive for manufacturers and companies managing volumes of connected devices. The Device Provisioning Service is the only cloud service to provide complete automated provisioning, including both registering the device to the cloud as well as configuring the device. Device Provisioning Service is available in East US, West Europe, and Southeast Asia starting today, and eventually will be available globally. Without a provisioning service, connecting devices to Azure IoT Hub requires manual work. Each device needs a unique identity to enable per-device access revocation in case the device is compromised. Doing this manually works for very few devices, but at IoT scale, you have to individually place connection credentials on each of millions of devices. Read about it on the Azure blog.
