IoT Edge Module deployment limit
Currently there is a limit of 10 modules (includes agent, hub) to be deployed to IoT Edge device. What is the plan for module deployment limit for GA release? The reason is the solution we are working demands multiple (more than 8) peripheral integration at device level and we see that each Edge module could represent the peripherals. Also, please share tentative plan of GArelease?
The limit has indeed been raised to 20. We’re interested to learn about scenarios that require more than 20 modules.
Sander van de Velde commented
The number of modules is extremely confusing. It seems to be 50 now.
The Azure Portal shows a limit after adding 20 modules (22 including edgeAgent and Edge Hub):
In https://docs.microsoft.com/en-us/azure/iot-edge/how-to-deploy-at-scale the limit is set to 30.
As seen in this discussion https://github.com/Azure/iotedge/issues/3105 (and https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-quotas-throttling#other-limits), the limit is now 50.
If 50 is correct indeed, please update the documentation and change to portal limitation.
Sander van de Velde commented
The limit is now 50. The Azure portal is still limited to 20 but the CLI should be able to add more modules.
See also https://github.com/Azure/iotedge/issues/3105
Our IoT Devices run AI modules provided by 3rd parties, trigger different types of actors, telegraf for keeping an eye on everything, time series database, rule processor, audio and video modules. We are constantly suffering from the 20 module limitation.
The limitation has already led to bad design decisions because we have to merge modules together causing problems that we should not have to begin with. Please increase the limit.
Bart Peirens commented
Our scenario also needs more then 20 modules. we have created small modules that can do very simple tasks. like a regex matcher, stringbuilder, Gs1HexToGrai convertor, fixed parameter adder, .... and we have special modules that can connect to specific devices like rfid or barcode readers, camera's, printers, barriers, ...
the idea is that we create a workflow by connecting all these reusable modules to a working middleware that runs in de edge and connect to a wms system.
As a exemple an inbound rfid enable gates (combining gpio,rfid, vision and wms communiction). ,lrp camera and rfid entry gate (combining gpio, rfid, lrp, barcode ticket slicker and wms communication), QC line (combining rfid, 2d barcode, 3d barcode, wms communication and opc ua), ...
At the momement we have 1 big module with our own wf engine that is using these modules because of this restriction.
The configuration is now very complex because we need a sepperate api so the module can donwload the configuartion. It would be easier if we have 1 location for a deployment configuration and use the desiered proprties and routing to build this complex workflows.
IoT-Edge Azure Functions are also limited to 20? That is probably too few and in contrast to the azure-functions purpose and design: lots of small functions carrying out independent tasks. But the real advantage here is that does enable any number of concurrent instances of a module to exist if it is really Azure Functions.
Richard Hubert commented
Thanks for the 20, we'll need more :-) The simplest designs separate coupling and concerns. At best, we would have simple modules (containers) in the IoT-Edge for each device type that is installed in a factory floor or hospital region. This can be well over 20 device types (classes or categories of different device types) of course.
If we take this separation-of-concerns thought further and say that we'd like to have even simpler code and better separation of concerns, then each edge module could handle and individual instance of a device. Then, our code would not even have to do multiplexing and multi-device-instance (of a device type/class) management. This instance-variant would be closer to functions as a service though, which is already available on the Edge if I am correct -- as long as it is production-ready...
Hi Leon, you have a very valid scenario we refer to as identity translation (you can read more at the link below). In this setup you would have 4 modules, one for each sensor type. Each module would then span a new process for each instance of the particular type of device that connects. That new process would use a device identity to connect. This way each downstream device will have its own twin that can be used for configuration.
That said, we also have not provided a code sample for identity translation yet. This is an item that's high on our list. You can track our progress at the User Voice request for it - https://feedback.azure.com/forums/907045-azure-iot-edge/suggestions/32497981-code-sample-for-identity-translation-pattern
Edge device as a gateway - https://docs.microsoft.com/en-us/azure/iot-edge/iot-edge-as-gateway
Our current solution :
- 4 "unrelated" types of sensors in a mining environment.
- Within a sensor type we can decrease each instance to a single process (Docker)
- Share some common infrastructure (eg DB and Monitoring)
- As it stands we are already running 30 sensors processors (Mixed) on a single server
In an ideal scenario We would like to be able to place the physical sensor (eg IP camera based) on the site and deploy and configure the new sensor processor using the Azure IOT edge solution.
I understand that there are ways of getting around this by running an image per sensor type capable of handling multiple sensor inputs, but that seems to take away from a lot of the features that makes the azure attractive
My understanding is that limit has recently been raised to 20 but I would like to see any arbitrary restrictions removed. 20 is still too low for some scenarios.