Skip to main content

IoT offer comparison: AWS vs Azure

Nowadays IoT is appealing for everyone. These opportunities made the two biggest cloud providers from the market (Amazon and Microsoft) to come up IoT platforms and solutions. The main purpose this this article is to compare the current solutions from features perspective and capabilities perspective.
The interesting thing that happened in the last few years is the way how IoT solution evolved. At the beginning the solutions were oriented around transport and communication, but now the IoT platforms evolved and are integrated with systems that runs on the edge and in the cloud, supporting the business needs.

Let’s take a look on the available solutions that Amazon and Microsoft offers. Both providers are offering a central Hub that is used to establish and facilitate a communication between devices and backend systems.
At device level, each provider is offering a set of package libraries that allows clients to integrate their devices with the communication platform faster. At backend level, the basic functionality is almost the same, with some small differences. Most of the processing systems used for data crunching can be found on both providers.
Is interesting how both platforms are positioning. Both of them are focused on telemetry and data collection from devices. Even if there is full support for communication (commands) from backend to device, complex scenarios or chatty devices might have some problems.
Don’t be shocked if you will find a lot of similarities between these two solutions. The main focus of both providers is to fulfill the clients’ needs. Because of this, it is normal when a new feature is available on one platform, the other one to provider a similar one in a short period of time.
Overall, from the way how both solutions are organized and list of cores features the offer is similar.

Core functionality
Let’s take a look on the main features of each platform. This list represents the main core features that are available today. Starting from tomorrow this list might be incomplete, because new functionality can be added anytime.

Device Management
From device management perspective, both providers are offering a similar list of features.  You have the ability to specify the list of attributes of each device and have a device shadow into the cloud. A useful feature that can be found on both platform is the ability to enable a device and control device capabilities. This is extremely useful when concepts like devices black list needs to be supported.
Azure IoT Hub is offering pipeline support for data that needs to be send to the device, in comparison with AWS where this is not an out of the box feature. Extra development feature is required for it.

Authentication and Authorization 
Good authentication and authorization mechanism are offered by both providers. For startups and small companies that are not using Active Directory (AD), AWS might be tempting, but Microsoft is very attractive in the moment when a corporate is using AD. Native AD support combined with token based access for device will simplify integration with legacy application that exist inside the company.

Communication Channels
The list of protocols supported by both providers starts with HTTPS, MQTT and AMQP. Be aware that Azure is very strict related to HTTPS and HTTP is not supported anymore. If you need HTTP protocol between device and Azure, they can be supported only with a custom gateway between device and Azure IoT Hub.

SDK and programing language
AWS and Azure have a clear statement related to this – to support all top platforms, starting from Node.JS and C (ANSI C99) to Java and C#. The SDK features and API is the same for all programming language. Don’t expect to find a feature available only in a specific programming language.

Extra capabilities
The current IoT vision that is shared in the market is starting at device level and goes until to Machine Learning, AI and Analytics solutions. Azure and AWS are offering not only the same capabilities, but are using also similar is not even the same solutions. Hadoop, Spark and R language are something common for both of them.
Monitoring and Identity Registry
Azure is storing all the device information in the backend. The last device state can be queries in any moment. The state of the device is available in Azure IoT Hub together with last know activity, with full control of the device (create, updated and delete).
The identify management in AWS is called Thing Registry and is equivalent to the one offered in Azure.

Device Communication
Bi-directional communication is supported by AWS and Azure. The only difference is how is this supported. AWS is supporting this using a rule engine. Devices that are connected to AWS IoT platform have a specific topic/subscription that plays the role of message broker that sends messages to their devices. Each device publishes their state through publishing updates and stored in a Thing Shadow.

Azure IoT Hub is using two different endpoints that are used to send and receive data from devices. Messages contains a timestamp and can expired after a specific period of time. The concept of Thing Shadow can be found also on Azure IoT Hub as Twin Device. Personally, I thing that in this moment the Azure IoT Hub is offering a more mature solution at device communication level.
From communication perspective, both provided are offering the same feature, but implement in a different way.

Nowadays security is a hot topic. You will be able to find a lot of whitepapers related to this. You should remember that Azure IoT Hub relies on Transport Layer Security (TLS) protocol that offers an encrypted communication channel that guarantees data confidentiality. Customers can come with their own X.509 certificates. Beside this, services and devices are secured using access control and credentials that specify a list of permissions. In this way, each device will have control to a specific list of actions.
AWS also relies on TLS for backend authentication with full support of mutual authentication. Clients has the ability to attach certificates to device and policies.

Certified Hardware Boards
Each provider is offering starter kits together with different hardware manufacture. This kits are ideal to create prototypes and validate ideas. Below you can find a list with the most important partners.

Application and Services
Each provider is offering a collection of services to help their clients. The most important services offered by Azure (IoT Suite) around IoT are:
Stream Analytics
Machine Learning
Power BI
Azure Time Series Insights
Azure Storage
Azure Cosmos DB
Azure Web Apps
The services offered by AWS are covering the same functionality:

This topic is pretty hot and complex. Calculating the E2E cost of an IoT platform it’s hard, especially when you need to make different assumptions (data volume, ingest, egress, number of messages, size, queries complexity, …). The message size for AWS is 1KB in comparison with Azure where the message size is 4 KB. This can have affect at costs level.
It seems that if you put all the costs together you might find that an IoT platform to be 20-50% cheaper on Azure than on AWS. Free tiers at communication level are offered by both providers.

Final thoughts
The best way to finish such an article is not with the writer opinion, because this might be irrelevant. I thing that most relevant information would be a chart that compares this two platforms.


Popular posts from this blog

How to check in AngularJS if a service was register or not

There are cases when you need to check in a service or a controller was register in AngularJS.
For example a valid use case is when you have the same implementation running on multiple application. In this case, you may want to intercept the HTTP provider and add a custom step there. This step don’t needs to run on all the application, only in the one where the service exist and register.
A solution for this case would be to have a flag in the configuration that specify this. In the core you would have an IF that would check the value of this flag.
Another solution is to check if a specific service was register in AngularJS or not. If the service was register that you would execute your own logic.
To check if a service was register or not in AngularJS container you need to call the ‘has’ method of ‘inhector’. It will return TRUE if the service was register.
if ($injector.has('httpInterceptorService')) { $httpProvider.interceptors.push('httpInterceptorService&#…

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

Run native .NET application in Docker (.NET Framework 4.6.2)

The main scope of this post is to see how we can run a legacy application written in .NET Framework in Docker.

First of all, let’s define what is a legacy application in our context. By a legacy application we understand an application that runs .NET Framework 3.5 or higher in a production environment where we don’t have any more the people or documentation that would help us to understand what is happening behind the scene.
In this scenarios, you might want to migrate the current solution from a standard environment to Docker. There are many advantages for such a migration, like:

Continuous DeploymentTestingIsolationSecurity at container levelVersioning ControlEnvironment Standardization
Until now, we didn’t had the possibility to run a .NET application in Docker. With .NET Core, there was support for .NET Core in Docker, but migration from a full .NET framework to .NET Core can be costly and even impossible. Not only because of lack of features, but also because once you…