I'm new to both Terraform and Azure. In a timespan of 6 weeks I have to create an IoT solution. I've only got 3 weeks left.
I have to provision devices in an IoT hub using a DPS and if 'm not wrong, a DPS uses azure functions to do so.
My question is, how can I add azure functions to a dps using terraform or is this not possible and do I have it all wrong?
DPS does not require an Azure Function for basic functionality. That's only needed if you're doing custom allocation policies. If all you want to do is have an IoT Hub assigned from a pool of one or more Hubs, then one of the built-in allocation policies will work, as described in the overview:
Multiple allocation policies to control how DPS assigns devices to IoT
hubs in support of your scenarios: Lowest latency, evenly weighted
distribution (default), and static configuration via the enrollment
list. Latency is determined using the same method as Traffic Manager.
The documentation explains how to select this in the Portal, and since you mention you're using Terraform, the provider does this using the allocation_policy setting according to the provider documentation.
I understand you're under a small time crunch but you might find the self-paced training at Microsoft Learn for the AZ-220 exam worth your time. There is a learning path about device provisioning, and the information on load balancing is covered in that (for example, at this lesson).
Related
Situation:
I hit a throttling limitation of free tier IoT Hub where deployments are limited to 10. This limitation is described here
Failed deployments manifests itself
when Azure DevOps CI pipeline is used
Azure Portal
Problem(s):
The error is pretty clear, but what I'm struggling to understand is whether the limit of 10 gets reset at some point or is that it - no more automatic deployments for this Edge device, ever? The documentation seems to suggest that paid for IoT Hubs have 100 deployment limit, what do developers do after that?
I have created a deployment manifest and attempted to deploy it manually through VS Code. This has worked, but then within very short period of time (~5min) the Hub reverts to previous configuration. Is that because of this limit or its a property of the Hub to e.g. revert to previous configuration if newly deployed modules fail for one reason or another?
You should not create a deployment for every device. Rather target deployments to a set of devices: https://learn.microsoft.com/en-us/azure/iot-edge/how-to-deploy-at-scale?view=iotedge-2020-11
To modify a single device, follow the steps outlined here: https://learn.microsoft.com/en-us/azure/iot-edge/how-to-deploy-modules-portal?view=iotedge-2020-11
This allows you to change every one of your max 1 million devices per IoT Hub individually. But is this really needed?
Best practice: Use layered deployments (https://learn.microsoft.com/en-us/azure/iot-edge/module-deployment-monitoring?view=iotedge-2020-11) and change settings via Module Twin, if needed.
I am not understanding when Azure IoT Hub can be preferred over Azure IoT Central. From the readings done so far, IoT central seems better over all the aspects.
Anybody can explain me where are the situations where IoT hub is better than IoT Central?
Thanks
There is no definitive answer to that question, neither are "better", but most of the times one will fit your use case more than the other.
If you want a complete, managed way of connecting devices to the cloud and create dashboards (within the product's limits), a Software as a Service solution like Azure IoT Central can be a match. Think about the requirements of the project you're looking to do, and if it's all supported by IoT Central, go for it! If there are some features you can build by leveraging data export from IoT Central, it might still be a great fit.
If you want to build bi-directional communication and device registration for IoT devices into your own cloud platform, IoT Hub comes into play. Maybe you need better control of the data, or maybe the data insights you need aren't supported by IoT Central. There are a lot of cases where it might not be the best choice. IoT Hub gives you a lot more flexibility that you can use to create almost any IoT scenario.
Both are not directly comparable, there are specific advantages of IoT Central which you may need to consider.
IoT Hub is a PaaS service which can be used with other services to create an IoT solution while IoT Central is IoT Application platform which can be used as-is or extended via companion application. Even addressing basic functionality in IoT Central you will need over dozen other services and you own responsibility to design, manage and administer the orchestration yourself.
IoT Central internally uses multiple IoT Hubs (HA/DR) and bunch of services to bring the functionality that you see in the application. This includes App Service to host the UX, Rules Engine, Fast Storage, API layer, Data Export, RBAC, in-app Multi-tenancy , etc. etc. The key advantages you get -
Full featured IoT solution with high availability, security, scalability that is available in < 10 secs under 99.9% SLA
Simplification, easy to connect any device or simulate basic capabilities using the built-in plug-n-play support. Just select any device from the pnp catalog and try it out even before purchasing the devices.
Create user or app level dashboards with device specific views. Device specific view can be auto-generated with PnP devices.
Rule creation, alerting and integration with other applications via Logic Apps, Functions
Data Export functionality to Event Hub, Service Bus, Blob Storage or Web hooks
Rich Job's interface allowing updating device configurations or firmware
RBAC in combination with Organizations allow giving specific permissions to user.
The big advantage is all this is available with a very simpler per device per month pricing that starts as low as 8 cents per device per month ($2 a year) + additional messages https://azure.microsoft.com/en-us/pricing/details/iot-central/
In general unless you already have UX, Storage, Rules engine, etc. elements required for IoT Solution and need to add IoT Hub to ingest and manage IoT devices it will make more sense to start with IoT Central and build with it. It will save time, efforts and you can focus on specific differentiation than build the underlying plumbing and owning the management and sustenance. It is difficult to come to that price point given the high cost of cloud engineers required to support and maintain it.
It is recommended that all customers begin their IoT journey with our aPaaS offering Azure IoT Central. IoT Central is a ready-made environment for IoT solution development. As an aPaaS offering it is built to simplify and accelerate IoT solution assembly and operations, by preassembling PaaS services from the IoT Platform (including IoT Hub and the IoT Hub Device Provisioning Service) and across Azure. A customer that starts with IoT Central builds valuable expertise regardless of whether they go to production with IoT Central, or later build a custom solution to meet complex business needs using PaaS services. To learn more about onboarding to Azure IoT check out this documentation: https://aka.ms/azureiotarch and stay tuned for a session at Microsoft Ignite Nov3-4th Entitled Onboarding to Azure IoT
I have nearly identical service buses in 2 separate regions. I am trying to make them be more region agnostic for consuming applications.
While looking into things like Azure service bus geo-disaster recovery and message replication and cross-region federation and how complicated they are, I was thinking instead that I could create a service bus client that would just read from the same topic/subscription name in separate regions and treat them as if they came from the same region.
While I'm sure this can be implemented, I was wondering, does this functionality exists in any current Microsoft libraries? Basically, if message A get published to the east topic/subscription and message B gets published to the Central US topic/subscription, then the client would receive A and B. The order is not important.
Thanks!
Some sort of functionality has existed in the track 0 SDK of Azure Service Bus SDK for failover but not concurrent execution. As it was a client-side feature, it did not get much traction and was very confusing and complicated.
NServiceBus had a legacy Azure Service Bus transport that supported using more than one namespace concurrently. The feature was deprecated as it was also more of a trouble than good. Not to mention the fact that Service Bus has introduced the Premium tier which would handle availability better than multiple standard namespaces together. On top of that, add availability zones and it's hands down a better option than the complexity of setting up multiple receivers.
In case your namespaces are identical, I would suggest consolidating them. One of the strategies would be to "forward" messages from one namespace to another using some processor as there's no cross-namespace forwarding.
I'm developing a basic Azure IoT Remote Monitoring solution with the Azure Solution Accelerator "Remote Monitoring". When I start to actually pay for services and stop using a free account, very soon the cash starts to pile up and there seem to be very many resources created behind the scenes. I'm wondering which resources I really need and which one I could throw away to save money. These are the resources that I have:
App Service plan
App Service
Network interface
Network security group
Public IP address
Virtual network
Storage account
Azure Cosmos DB account
Device Provisioning Service
Event Hubs Namespace
App Service
App Service plan
IoT Hub
Key vault
Logic app
Azure Maps Account
API Connection
Disk
Storage account (2)
Stream Analytics job
Time Series Insights environment
Time Series Insights event source
Virtual machine
CosmosDB is probably one of the more expensive resources in your list so if you can find a way to swap some other datastore for it you can save some money.
Take a look at Remote Monitoring architectural choices. The Azure IoT Remote Monitoring solution accelerator is an open-source, MIT licensed, solution accelerator. To help you speed up your IoT development process, it shows common IoT scenarios such as:
Device connectivity
Device management
Stream processing
The Remote Monitoring solution follows the recommended Azure IoT reference architecture.
This article describes the key architectural and technical choices made in each of the Remote Monitoring subsystems. However, the technical choices Microsoft made in the Remote Monitoring solution aren't the only way to implement a remote monitoring IoT solution. You should regard the technical implementation as a baseline for building a successful application and you should modify it to:
Fit the available skills and experience in your organization.
Meet your vertical application needs.
I'm trying to create a table of comparison of different messaging queue, from opensource to proprietary. and I'm trying to identify the issues and disadvantages of Azure Service Bus without availing the standard and premium tier. I would like to ask this question to those who experienced implementing it on their own application.
I tried researching for related topics but i cant find reliable resource.
I'm expecting a list of possible issue and disadvantages in general in any of this areas; features, limitations, experience, maturity, community, and performance.
Service bus is just a medium to deliver messages from issuer to the receiver. it doesnt matter when they both are as long as they can talk to the service bus. your application can talk to service bus from inside the container just fine.