The first and most important chapter of the #AvsB #gossipiece!
Disclaimer: it’s just my own view, doesn’t represent any organization or people
I was asked by my colleagues many times, “what is the difference between EventHub and IoT Hub in Azure?”. What don’t you use EventHub? it takes care of your real-time sensor data.
Well, there are a few difference between these two of course, but you only need to remember one thing that makes the difference —-
I have mentioned in my previous article, without proper device management functionality (in the platform level), your IoT solution becomes a DIY home project.
Okay, let’s take a look at what AWS and Azure offer. I want to emphasize it again, I am comparing the platform, i.e., PaaS solution from AWS and Azure, PaaS solution is designed for developers, not for end-users. This is the most confusing part!
Looking at Device Management, both AWS and Azure provided some services, such as AWS IoT Core, AWS IoT Device Management, Azure IoT Hub, etc. I will explain each of them below:
- Sensor on-boarding (single sensor)
- Sensor visualization & alerting
- Fleet Provisioning
- Sensor organization (indexing + IAM)
- Remote monitoring & control
It is a very long article, I hate it… so I am going to summarize it for you here:
Overall, AWS IoT and Azure IoT can both achieve most (nearly all) of the IoT device management activities, mostly is through their SDK. You can build the logic yourselves. However, AWS IoT’s dev UI portal is much better, cleaner, friendly than Azure IoT Hub, and some simple service like monitoring, alerting are just easier to configure in AWS, and cheaper. But Azure is far more better than AWS IoT in enterprise level scalability. It provides Device Provisioning Service (DSP). This is something big enterprises are looking for, managed service.
Therefore, my vote on AWS IoT if you are looking for some quick and small project, demo, prototype. Good for startups. If you are a big company, looking for some market standard, managed service, Azure is a good place to go.
Last word: don’t forget this is definitely a fast-changing field. In some situations, you don’t even need such PaaS solution, you can just buy some SaaS solutions and apply it to your business.
————————————Below are the comparison details———————–
1 . Sensor on-boarding (single Sensor)
Microsoft Azure IoT Hub:
- Create devices
- Select authentication methods Create device
- SAS token
- Upload certificate
- Add device attribute
- Add device tags
- IoT Hub SDK for development
- If not using symmetric key for authentication, IoT Hub does not create a certificate for us, the user has to generate certificates use openSSL15.
- GUI functionality is limited, cannot edit device info in initial creation, must edit in the Device Twin after creation. Complete functionalities are provided in the IoT Hub SDK.
AWS IoT Core
- Add device name
- Create type
- Apply type to the device
- Create and assign a device to groups
- Set attributes
- Create certificate
- Create certificate
- Create CSR (certificate signed request can leverage certificates that are injected into the hardware while manufactured and avoids send certificate over wire)
- Use own certificate
- Download certificate
- Scalability is supported while using AWS IoT Core API. More info to be found Fleet provisioning section below.
- AWS IoT Core GUI is well developed and has full functionality to add, edit device info either in the creation or after creation.
- NA (I couldn’t find any big limitation when add one sensor, AWS is just easy to use and have the highest secure way with certificate)
“I use red, amber, and green to determine, if it’s red, meaning below expectation, amber means it meets expectation but not that good. Green means it’s quite good.”
If you get familiar with Azure IoT Hub, you won’t feel any difference, but AWS is just built in a such a simple way for everybody. To onboard one device on the Cloud, you will love AWS. Azure also offers the symmetric key to make your life as easy as in AWS, but please keep in mind that symmetric key is not as safe as the X. 509 certificate. Check out the article from Microsoft: https://azure.microsoft.com/en-us/blog/iot-device-authentication-options/
2. Sensor visualization & alerting
- Visualizing sensor data using Azure Time Series Insights (TSI) —> this is not cheap just for development purpose….
- Visualizing sensor data using IoT Hub SDK or build on top of IoT Suite solution (e.g., remote monitoring)
- Send email or notification alert using Azure Logic App
- Scalability can be managed through SDK developing customized service
- Time Series Insights can be used for telemetry visualization in scale
- Logic App has user friendly UI to create alert use if-this-then-that workflows
- Time Series Insight is easy to use, but it’s a bit expensive.
- Customize solution from IoT suite can accelerate the development of IoT solution.
- Visualization and alerting are managed through multiple services, which may potentially increase the cost of hosting and using these services. The pricing model for TSI is per unit and per month for a tier of hosting service, not as flexible as charging per usage.
- Visualize sensor data in CloudWatch
- Create alert within CloudWatch rules
- Customized dashboard with sensor Alarms or Events in CloudWatch.
- Sensor status can be monitored via a customized app developed with the SDK.
- CloudWatch can be used for sensor data visualization and alerting.
- IoT Core API allows us to create a customized app to monitor device status.
- CloudWatch enables easy setup of a dashboard for monitoring and alerting.
- NA – please add here if you found anything, I was pretty satisfied with it so far.
Azure can do the job of course, but it’s just expensive or overkill in the development phase. Check out TSI, quite expensive. AWS’ cloudwatch is simple and easy to use.
3. Fleet Provisioning
- You can use Azure IoT Hub SDK to manage device in a large scale. The logics need to be built in your code of course.
- Azure Device Provisioning Service (DPS) provide device onboarding with x.509 certificate (does not support SAS token)
- Scalability is largely depending on the way how you will inject the certificate into the devices.
- DPS itself can easily perform onboard activities for a large number of devices by groups.
- DPS is easy to use, and not many coding efforts are required
- No major limitation
- Bulk onboarding is possible using IoT Core API and provisioning template.
- Bulk onboarding can be achieved using pre-injected CA with a CSR and provision functions with Lambda.
- Bulk updating for devices (incl. edge devices)
- Scalability is powered by using IoT Core API.
- NA, I cannot find anything can make your life eaiser… it’s just coding and coding….
- No managed bulk provisioning service is provided, the provisioning templates need to be managed by the users either stored in S3 or other places.
Conclusion: Azure device provisioning service is definitely a killer in this game, it provides a managed service for companies. AWS IoT can achieve the same thing of course, but you have to build the code yourself, which mean you have to maintain your code! Not ideal for enterprise customers.
4. Sensor organization (indexing + IAM)
- Query window (SQL) in IoT Hub
- Able to monitor device using accelerator service IoT Suite (half managed service).
- IAM is managed through Azure directory (AD), it can allow different user to access the IoT Hub and services accordingly.
- Scalability can be achieved by using IoT Hub service SDK
- Cannot find anything…
- Query window is hard to use, only correct query can be recognized.
- IoT suite still needs a lot of customization if want to improve user satisfaction.
- Device access management is not easily manageable, custom codes are needed as IAM is not yet in the device level.
- Can search devices in the search box in IoT Console
- Can manage devices based on their attributes
- Can monitor device status using API
- Can create children accounts for access management to the IoT core.
- Scalability can be achieved using IoT Core API
- Python notebook was created to monitor multiple device status in real-time. Scalability can be achieved using IoT Core API
- Search functionalities in IoT console is super good. User can do fuzzy search as well as query search.
- No existing managed UI service for device status monitoring, can only be achieved through API
- IoT device resource scoping (on device level) is not possible at the moment.
Conclusion: No obvious winner, but AWS’ search function is better designed than Azure. Neither of them are capable of managing access to a device level. However, AWS has offered the IoT device defender end of 2018. I haven’t got time to look at that yet.
5. Remote monitoring & control
- IoT suite can provide monitoring dashboard (but customization is required)
- Using direct method, user can perform remote control (firmware update, reboot, etc.) over internet.
- IoT central as a SaaS solution can be utilized but it’s still in its early development stage
- Scalability can be managed by using IoT Hub SDK.
- Remote control of the device can only be done via Azure CLI or through custom apps built via SDK.
- Executable codes need to be put into the device to listen to the job message.
- IoT Suite is useful, but needs custom coding and is not a managed service.
- Remote monitoring can be done using IoT Core API (status monitoring)
- Remote control can be accomplished with jobs in IoT Core
- If use Amazon FreeRTOS system, it contains beta OTA functionality and Greengrass OTA update facility of Greengrass itself.
- Scalability can be managed by using IoT Core API.
- CloudWatch can be used for remote monitoring and alerting.
- IoT Console testing page can be used to subscribe to topics to quickly monitor device data and status.
- Remote monitoring of devices can only be done via AWS CLI or through custom apps built via SDK.
- To execute job or report device status, the executable codes need to be created and injected into the device beforehand.
Conclusion: Both solution offers remote control and monitoring capabilities. But you have to use their SDK, yes, you have to use their SDK. Otherwise, you don’t get the functionality. The most difficult is to put the code into the device for the first time. OTA, remote control will happen after it. The best way to achieve this in scale is to start in the factory where people make those IoT devices. Inject the basic function, certificates, etc