I'm building an Azure IoT Hub application. I have several customers. Do you think all those customers should be connected to the same hub or a different one(s)?
And if that's even possible, how would such multi-tenancy work so that the customers (tenants) wouldn't see each other's data on that same hub?
And finally, do you have to pay for each new IoT hub? (in which case maybe it's a good idea looking into sharing one between customers)
A single hub would suffice but then there should be provisions needed to make sure that you are not hitting the maximum allowed message in a hub as IoT Hub SKU size is defined on the number of messages https://learn.microsoft.com/en-in/azure/iot-hub/iot-hub-scaling?branch=release-iotbasic
With single hub you need an almost near time throttling feature also in your application so that one rouge device won't eatup the maximum message allowed for IotHub Unit.
"And if that's even possible, how would such multi-tenancy work so
that the customers (tenants) wouldn't see each other's data on that
same hub?"
The message can have TenantId (please check https://azure.microsoft.com/en-in/blog/azure-iot-hub-message-enrichment-simplifies-downstream-processing-of-your-data/) which would differentiate messages from each tenant.The custom solution need to filter it based on the Tenantid or DeviceId which would be unique across every tenant in a IoTHub.You can have TenantId added in DeviceTwins once device is registered in IoTHub so that it would help identify Tenantid associated with the Device.
Related
Right now, on IoT Hub there is an information that limit for messages per day 8000. I would like to ask you about any patterns which are being used in Azure.
I am curious if I am able to hit to Azure with some service outside Messages in order to prevent it from being overloaded by big amount of data, or save some confidentiality for this service.
For example, I would like to store some data from given service to Messages that are not being confidential and other data by using some WebSocket or any Rest protocol. I think that there are some patterns that serve that scenarios.
Does anyone has experience with that kind of situation?
Not everything needs to go through IoT Hub. IoT Hub is great for two way communication to/from IoT devices. You could also look at Event Hubs for ingestion from devices that don't need two way comms. We have a write up on the differences here Connecting IoT Devices to Azure: IoT Hub and Event Hubs.
I am trying to understand on do I need to choose individual IOT HUB based on device category.
For Example I have devices sending GPS info.
Devices send stock info
Devices sending quality info.
Devices sending security info.
Devices sending fire safety info.
Each of the above category devices send versatile data in versatile format. In this scenario is it a best option to configure multiple IOT hubs or one IOT hub is suffice.
Thanks in Advance....
As the IoT Hub is totally agnostic to the actual data that you are sending, you would not need to have separate IoT Hubs per use case. You can still connect all the devices to one IoT Hub and then route the telemetry data, for example based on on device properties, to different downstream processing steps.
You might still want to use multiple IoT Hubs but mainly then for either scaling reasons or for geographical distribution.
Let's say I've got an azure service bus in a microservice scenario.
One microservice pushes master data changes to the other services with a subscription.
Now let's say a new service is introduced and subscribes to the master data service. How can I make sure that the new service receives all neccessary data?
Do I have to resend all master data on the master data service or does the azure service bus (or alternatives) provide some features for that?
As far as I know there is no way to achieve what you want within the capabilities of Azure Service Bus. Also, I don't think this what Service Bus is there for.
Of course there is a configurable "time to live" value for messages within queues and topics, which could probably be set to some really high value, but this would still not make your master data be infinitely available for future services. And - but this is just my opinion and I'm far from being an expert - I wouldn't want to load up my service bus with potentially thousands or even millions of messages (depending on what you're doing) without them being processed quickly.
For your specific concern I'd rather implement something like a "master data import service" without any service bus integration. Details of this, however, depend on your environment and specific requirements.
Couple of points:
1) This is not possible with Azure Service bus. Even If you set TTL at Topic level, the messages will only be delivered to available subscriptions at that point of time. you cant read messages directly from Topic.
2) you can consider Eventhub option where you can create new consumer group with offset from when you want to start reading messages but Eventhub has maximum retention period as 7 days. If you need message retention beyond 7 days, enabling Event Hubs Capture on your event hub pulls the data from your event hub to the Storage account. But in this case you would require additional logic to read from this storage account to replay the messages.
I'm looking into using Azure Service Bus for publishing/delivering messages between different services in our application, and are trying to find a decent design for the topic and subscriptions within a Service Bus namespace.
The intent of the system is for service-a to publish a message with type service-a.test-event to a bus, and have any service listening on that event type get the message delivered. It will be a fairly low volume
I'm a bit torn on which of the following designs to use:
The Service Bus namespace has one topic events where all messages from all services are delivered. Any service subscribing to events from any other service create a subscription in this topic using filters to get the message types they want - one subscription per message type (eg. service-b-service-a-test-event).
The Service Bus namespace has one topic per publisher (eg. events-service-a). Any subscribing service to events from this service create a subscription in the topic using filters to get the message types they want - one subscription per message type (eg. service-b-test-event).
Service Bus seems to have a limit of 2000 subscriptions per topic, which as far as I can tell will be sufficient for us. If I had suspicions otherwise, option #2 would probably be the best choice (as I can have 10.000 topics per namespace). None of the other limitations of Service Bus, as far as I can tell, really impacts which of these options I should go for.
One additional requirement is that I want to have a service subscribing to any event from any service for recording reasons. If I went for option #1, that'd be very simple to implement. For option #2 however, that service needs to somehow make sure it has a subscription within any event topic in the namespace - and reconfigure itself once new topics are added and old topics are removed. That's outside the scope of this question, but a requirement for the design none the less.
When deciding about a topology, take into consideration things that matter to you the most. One of the principles of pub/sub is to decouple between publishers and subscribers. With topology #2 (topic per publisher) this principle is violates since every subscriber would have to know the name of the publisher. And if publisher of an event would change, all your subscribers would have to get that knowledge in order to re-subscribe. Topology #1 solves that problem by abstracting publishers away by using a single topic.
Also, the 2nd requirement you had (to audit all of the events) would be much easier to implement with this topology as you only have to maintain a single wiretap subscription on that topic.
You're correct about limitation of 2000 subscriptions per topic. Saying that, 2000 subscriptions is quite a lot. Once your system get to that number of subscribers, you'd probably want to review your architecture/topology anyway.
These two topologies are sound extremely similar to the NServiceBus on Azure Service Bus as a transport topologies. You could have a look to see some of the other ideas you could use for your topology, including benefits of one over another.
Disclaimer: I am working on NServiceBus Azure Service Bus transport. You don't have to use NServiceBus, though a lot of questions like the one you're posting here become a non-issue when you do.
I am investigating migrating from Azure Mobile Services push notifications to Azure Notification Hubs for two primary benefits: 1) pub/sub architecture using tags, and 2) abstracting the device registration.
However, I'm struggling to understand the pattern for device badge value management.
With mobile services push notifications it's straightforward to maintain the current badge value in the db for individual device registrations. But with Notifications Hubs where Azure maintains the 'subscribed' devices registrations and manages the fan out of device notifications, what is the best approach for the client devices to update their current badge value with Azure Notification Hubs?
I have reviewed the Azure documentation, viewed several of the excellent overview videos, such as Channel 9 Cloud Cover episode 100, but documentation and examples seem to be lacking with regard to Notification Hubs and management of badge values.
Thanks for your help, friends!
Unfortunately badge management is not straightforward in a pub/sub architecture. If you use tags to indicate individual users then you can keep your counter in your backend and then add it in your notification when sending to your hub.
In you are using tags as interest group, then things are not straightforward, and they depend on what you want that count to be. For some platforms (i.e. iOS and ANdroid) you can code some client code that keeps a personalized counter. Some other times however, one has to avoid keeping personalized counters and resort to use generic badges like "!" in Windows 8.