The Internet of Things (IoT) is where the digital and physical worlds connect. As IoT continues to grow and new use cases emerge, new cloud technologies are needed to store, process, interact with, and analyze data from IoT devices. Cloud vendors and open-source solutions are constantly expanding their offerings in this area.
Numerous cloud vendors offer IoT-specific services, but in this article, we will take a closer look at AWS IoT, Azure IoT, and open-source IoT solutions (including Linux Foundation IoT, and Eclipse Foundation IoT).
In a practical sense, there are two main aspects within the IoT landscape: embedded systems (a field that has been evolving since 1961) and cloud systems (also expanding since the 2000th). When it comes to IoT functionalities, embedded systems aim to offer more advanced services to users, while cloud systems strive to extend their data-gathering capabilities to physical devices.
To visualize the relationship, we can consider the following diagram:
Native embedded <----> Edge IoT services <----> Cloud IoT services (often consisting of control & analytics services) <----> Native Cloud
Examples of IoT functionalities encompass:
- Firmware update
- Enhanced security measures for embedded devices
- Data analysis
- Intelligent edge capabilities for making on/off device decisions
All solution providers are actively offering solutions in the realm of Edge and Cloud IoT services, with some even transforming the inherent aspects of each field.
As of May 11, 2023, the solution offers are:
| Device Software | Control Services | Analytics Services |
|---|---|---|
| FreeRTOS | AWS IoT Core | AWS IoT Analytics |
| AWS IoT ExpressLink | AWS IoT Device Management | AWS IoT Events |
| AWS IoT Greengrass | AWS IoT Device Defender | AWS IoT SiteWise |
| AWS IoT FleetWise | AWS IoT TwinMaker | |
| AWS IoT RoboRunner | Amazon Kinesis Video Streams | |
| AWS IoT 1-Click |
| Device Software | Control Services | Analytics Services |
|---|---|---|
| Azure RTOS | Azure IoT Hub | Azure Stream Analytics |
| Azure Sphere | Device Provisioning Service | Azure Data Explorer |
| Azure IoT Edge | Azure Digital Twins | Azure Machine Learning |
Linux Foundation (not an exhaustive list)
| Device Software | Control Services | Analytics Services |
|---|---|---|
| Zephyr | EdgeX Foundry (with Azure and AWS integration) | EdgeX Foundry |
| Yocto | ||
Eclipse Foundation (not an exhaustive list)
| Device Software | Control Services | Analytics Services |
|---|---|---|
| Zephyr (connectors to Eclipse projects exist) | Ditto | Paho |
| Yocto (connectors to Eclipse projects exist) | Hono | Zenoh |
| Wakaama | ||
| HawkBit | ||
| Kanto | ||
| IDTA digital twin |
It is important to note that in terms of functionality and pricing, these solutions all fall within the same spectrum. Therefore, we need to identify key indicators that will enable us to differentiate between them.
A key indicator takes the form of a topic to which we will add questions we want to answer.
Let us try:
- Maturity
- Is the solution scaling?
- Is it globally available?
- Is the solution maintained?
- Who uses the solution?
- Lock-in
- How dependent I get from a vendor?
- What are vendor specific solutions?
- How easely I can change providers?
- Protocol support
- Does it support IP based protocol? How many?
- Does it support non-ip based protocols? How? How many?
- Maintenance effort
- How much work is it to update/upgrade a cloud software?
- How much work is it to update/upgrade an edge software?
- How much work is it to maintain the service up and running?
- How much work is it to monitor and resolve issues?
- Operative Cost
- What are the cost for “similar” setups?
- How does the cost scale? Based on what?
In the following sections, We will go topic per topic and try to answer each of the associated questions.
At the end, we will create a comparison table.
Azure and AWS, known as hyperscalers, prioritize scalability in their services. However, the open-source landscape offers a wide range of projects, with some like netdata and Kafka specifically designed for scalability, while others like Paho offer commercial scalable solutions such as Cedalo.
In terms of availability, most solutions are accessible worldwide. However, it's worth noting that certain AWS services are not available in China (see here for details: link), and similarly, Azure services have limitations in China (see here: link). On the other hand, open-source projects are generally available globally.
Regarding maintainability, AWS and Azure have a strong commitment to their customers, ensuring regular updates and addressing any bugs or security vulnerabilities promptly. In contrast, open-source projects heavily rely on their communities. With a large community, open-source projects can often attract more experts and contributors than any single company could (for example, Zephyr has the contributions of over 1.6k experts).
The choice of solution often depends on a company's specific needs. Organizations seeking liability in their services tend to opt for hyperscaler providers like AWS and Azure. Conversely, some companies, including those involved in building hyperscaler services themselves, prefer open-source solutions for greater flexibility in customization.
Taking into account the vast and diverse set of projects available, I would rate AWS and Azure highly, and open-source solutions slightly lower due to the broader range and varying maturity of projects.
When comparing the lock-in factors between Azure and AWS, it becomes apparent that Azure offers a higher level of cohesion within its services, resulting in fewer building blocks compared to AWS. Consequently, making changes to an Azure block may theoretically take longer than modifying an AWS block. However, using tools like Terraform can help reducing the risk of lock-in by providing a standardized approach to managing infrastructure across multiple cloud providers. In practice, a tradeoff emerges: opt for a solution that remains agnostic, thus limiting functionalities to those endorsed by both providers, or harness the capabilities of a single provider.
Moreover, Azure has a stronger integration with other Microsoft products like Teams and PowerBI, which enhances its overall compatibility and synergy within the Microsoft ecosystem.
To illustrate this point, please take a look at the solution offering of Scope and functionalities.
In the world of open-source projects, there are several considerations to keep in mind when choosing the right project.
The most obvious consideration is carefully examining the associated licenses. Some projects have strict copyleft licenses, others have weaker restrictions, and some have no copyleft requirements at all.
There are also less obvious considerations, such as compatibility and domain application.
In terms of compatibility, the Eclipse Foundation hosts numerous projects, each managed by different people. The compatibility between these projects is solely determined by the decisions made by those projects. Achieving end-to-end integration may require implementing multiple connectors or integrating existing connectors into the relevant projects. The good news is that popular projects tend to build ecosystems, resulting in the availability of more connectors. For example, Zephyr already supports firmware updates with five providers, including via SMP Server or LWM2M.
In terms of domain application, if you find a project that fulfills your specific needs, such as implementing a particular protocol like MQTT, you should also consider whether it meets your domain-specific requirements. These can include factors like bandwidth, memory footprint, and error handling. For instance, the Eclipse Foundation offers two implementations for digital twins: Ditto and IDTA, with the last one more industry-oriented.
Choosing the wrong project may lead to additional costs, either by (1) contributing to the project to meet your requirements or (2) switching to a different project that better fits your needs. The advantage of open-source solutions is that you have choices and are not solely dependent on a provider to deliver the necessary features.
It is important to note that big players, like AWS with FreeRTOS and Greengrass 2.0 or Azure with iotedge are putting some effort to open-source some of their technologies. It is mentioned as "soft" lock-in because you still need to put some efforts in case you want to use alternative providers with it.
Based on the information provided, I would rate Azure as the provider with the highest degree of lock-in, followed by AWS in the second position, and open-source solutions in the last position.
Both Azure and AWS offer support for MQTT and HTTPS protocols. Additionally, Azure provides support for AMQP, which sets it apart from AWS in terms of protocol coverage. However, when it comes to supporting other non-ip communication protocols like LoRa or BLE mesh, there are differences between the two platforms. Azure may rely on third-party market players (you can find them listed here), while AWS may have their own proprietary solutions. In cases where AWS doesn't directly support a protocol like CoAP, services like AWS Fargate can be utilized to deploy CoAP servers.
It's noteworthy that although certain protocols like MQTT may be supported, the compatibility and version specifics can vary. For instance, AWS IoT lacks support for QoS 2 and does not conform to QoS 0, highlighting the need for meticulous protocol evaluation when considering platform choices.
In the open-source realm, there is a project available for almost every protocol. Some projects focus on creating shared platforms like TheThingsNetwork, which is specifically designed for LoRa communication. Other projects are managed by open-standard alliances such as matter.
Considering the breadth of protocol support, I would rate open-source projects as the most versatile, followed by Azure in second place, and AWS in the last position.
Both AWS and Azure often provide their IoT services as Software-as-a-Service (SaaS) or Platform-as-a-Service (PaaS) solutions, with a strong focus on cloud-native architectures. When you opt for a service from either provider, you typically have the option to subscribe to a Service Level Agreement (SLA) for that particular service. This combination secure you service availability while it is fully maintained by the provider.
To update an edge device, both providers offer their own approaches (usually open-sourced), but they are compatible only within their respective ecosystems. You can find more information about Azure's approach here and about AWS's approach here.
In the open-source world, as they mature, they also provide firmware update capabilities that are compatible with several other open-source projects. For instance, Zephyr supports five firmware update mechanisms, including a simple download from a SMP Server. You can refer to this link for more details.
Many open-source IoT solutions require users to build and maintain their own cloud-native services, which can be more challenging and demand additional investments in terms of time, resources, and technical expertise. In particular, if a user discovers a security vulnerability, they may have to fix it themselves for the benefit of the entire community.
Considering these factors, I would rate the maintenance effort as high for open-source projects and significantly lower for Azure and AWS in comparison.
AWS pricing is based on the usage of AWS Greengrass, while Azure pricing is determined by additional services like monitoring and real-time analytics on top of their basic IoT services such as IoT Hub or IoT Edge.
In general, Azure costs are lower compared to AWS, as indicated by various blog posts discussing the comparison.
However, when it comes to open-source solutions, they often require an Infrastructure-as-a-Service (IaaS) platform like Kubernetes (k8s) to operate. This can result in similar or even higher costs compared to using proprietary solutions.
It is important to emphasize that these costs can be optimized through (1) adopting more cost-effective alternatives, such as opting for a more rigid IoT device-management approach instead of utilizing Greengrass for updates, or (2) developing proprietary solutions similar to the approach taken by prime-video to achieve a remarkable 90% reduction in costs.
There are also other open-source projects that offer scalable professional solutions. The costs for such projects can vary and should be assessed individually. An example of such a project is ThingsBoard.
This is why I would rank open-source solutions as having the highest operational costs, with AWS in second place (although prices can be reduced with various workarounds), and Azure in the last position.
Small words to the legend. You may see it more like a comparison instead of a score. For example, if I put:
| Solution A | Solution B | Solution C | |
|---|---|---|---|
| Topic | ++ | + | + |
You can interpret it more like solution A has more on this topic than solution B and C. When it comes to this topic, solution B and C are very similar.
| AWS | Azure | Open-source | |
|---|---|---|---|
| Maturity | ++ | ++ | + |
| Protocol supported | + | ++ | +++ |
| Lock-in | + | ++ | None |
| Maintenance efforts | + | + | +++ |
| Operative costs | ++ | + | +++ |
After thoroughly examining and discussing various aspects of IoT providers and open-source solutions, it is evident that choosing the right provider requires careful consideration and alignment with your specific business strategy. Each provider, whether it be Azure, AWS, or open-source projects, brings its own strengths and considerations to the table.
Throughout this comparison, we have explored different factors such as scalability, availability, maintainability, lock-in, operative costs, and IoT functionalities. Azure stands out with its strong integration within the Microsoft ecosystem, while AWS offers a vast array of services and flexibility. Open-source projects provide a wide range of protocols and customization options, but also require more effort and expertise in managing infrastructure.
Ultimately, the choice of provider depends on your organization's unique requirements, industry, and goals. It is important to thoroughly assess the factors that matter most to your IoT implementation. Additionally, as the IoT landscape continues to evolve, it becomes increasingly important to consider industry-specific decision criteria that can further refine your selection process.
In conclusion, selecting the right IoT provider is a strategic decision that requires careful evaluation and alignment with your business objectives. By considering the insights and factors discussed in this comparison, you can make an informed choice that sets you on the path towards IoT success.
In future posts, we can explore more specific decision criteria tailored to different industries or conduct a comprehensive Total Cost of Ownership (TCO) comparison, taking into account development costs, operational costs, and maintenance costs.
I would like to express my gratitude to Aniket Yeole, Yehia Elbahrawy, and Marco Mantoan for their assistance in creating the content. Special thanks to Schaefer, Falk-Moritz for providing valuable content feedback and ChatGPT for its role as an editor.