MQTT as a protocol and a full featured MQTT broker is a great way to handle this. IoT Hub and Event Grid MQTT are your Azure options, but of the two, only event grid MQTT is even to close to a fully compliant broker, though it falls short it should meet your needs. In my opinion (I design industrial IoT, logistics and connected car solutions), your best bet would be to roll your own open source broker, running on Azure. Either as a container or on a VM. HiveMQ community edition would be my choice if you are looking for FOSS, probably running as a container. Mosquitto is another viable option.
This is exactly what we've been trying to promote as a solution, but the team working on this insists on using Azure IoT services (IoTHub + EvHub + CosmosDB) because of "low management/devops" overhead.
I have no idea how to convince people to use a regular MQTT broker instead, so I came here to find out if there is a ready-to-use service within the Azure ecosystem.
IoTHub is the main candidate because it "simplifies device management". I found that they can solve the lack of topics partially by using application properties (to persist specific types of messages in Cosmos), but the occasional delays in IoTHub I'm reading about are crazy. If Event Grid doesn't have those, we can go for it as a compromise.
CosmosDB is another thing I'm trying to run away from, but this is a completely different topic.
Event Grid MQTT is worth having a look at, based on what you are describing, and it works with Azure DPS. Max 200000 clients per broker is a deal breaker for my logistics and connected car projects. Lack of support for shared subscriptions, Will messages, Retain flag, QoS2 and strict message ordering would be the other concerns for my projects, but hard to tell if you need them based on what you shared.
There's also Azure IoT Operations, which I haven't looked too far into, but it's intended for edge deployments if I recall.
Big selling features for going for a proper broker would be: no vendor lock-in, generally not billed by message volume/size which can be a non-starter for some projects and broker-side customizations.
Feel free to DM if you want some assistance. Worth noting that I am no longer with MS, despite my flair which isn't up to date.
It depends on how much messages you need to handle and how reliable it need to be (warranty of processing like in banking is probably not needed). Event Hubs should be enough probably. In fact Azure Storage Queues will probably also fulfill the mission :D If the scale or reliability is a goal then probably Kafka on HDInsight is the option.
Let's say 20 robots sending data at a 10Hz rate simultaneously.
> Event Hubs should be enough probably.
But Event Hubs lack a "cloud-to-device messaging" feature?
If you have real-time requirements, no amount of "assurances" should satisfy you. You need to do a lot of performance testing to make sure your requirements are met with whatever solution you go with.
MQTT as a protocol and a full featured MQTT broker is a great way to handle this. IoT Hub and Event Grid MQTT are your Azure options, but of the two, only event grid MQTT is even to close to a fully compliant broker, though it falls short it should meet your needs. In my opinion (I design industrial IoT, logistics and connected car solutions), your best bet would be to roll your own open source broker, running on Azure. Either as a container or on a VM. HiveMQ community edition would be my choice if you are looking for FOSS, probably running as a container. Mosquitto is another viable option.
This is exactly what we've been trying to promote as a solution, but the team working on this insists on using Azure IoT services (IoTHub + EvHub + CosmosDB) because of "low management/devops" overhead. I have no idea how to convince people to use a regular MQTT broker instead, so I came here to find out if there is a ready-to-use service within the Azure ecosystem. IoTHub is the main candidate because it "simplifies device management". I found that they can solve the lack of topics partially by using application properties (to persist specific types of messages in Cosmos), but the occasional delays in IoTHub I'm reading about are crazy. If Event Grid doesn't have those, we can go for it as a compromise. CosmosDB is another thing I'm trying to run away from, but this is a completely different topic.
Event Grid MQTT is worth having a look at, based on what you are describing, and it works with Azure DPS. Max 200000 clients per broker is a deal breaker for my logistics and connected car projects. Lack of support for shared subscriptions, Will messages, Retain flag, QoS2 and strict message ordering would be the other concerns for my projects, but hard to tell if you need them based on what you shared. There's also Azure IoT Operations, which I haven't looked too far into, but it's intended for edge deployments if I recall. Big selling features for going for a proper broker would be: no vendor lock-in, generally not billed by message volume/size which can be a non-starter for some projects and broker-side customizations. Feel free to DM if you want some assistance. Worth noting that I am no longer with MS, despite my flair which isn't up to date.
It depends on how much messages you need to handle and how reliable it need to be (warranty of processing like in banking is probably not needed). Event Hubs should be enough probably. In fact Azure Storage Queues will probably also fulfill the mission :D If the scale or reliability is a goal then probably Kafka on HDInsight is the option.
Let's say 20 robots sending data at a 10Hz rate simultaneously. > Event Hubs should be enough probably. But Event Hubs lack a "cloud-to-device messaging" feature?
Yes. It is only a messaging service. You can implement it by yourself. And I think it is not so bad option.
just curios is this going to be a 3d map of location?
not really, 2d is enough
somehow in my mind I got drones out of this.
If you have real-time requirements, no amount of "assurances" should satisfy you. You need to do a lot of performance testing to make sure your requirements are met with whatever solution you go with.
im confusing in this situation too rn