Building the Internet of Things
Download 258.06 Kb.
|
- Navigate this page:
- Communication and ingestion
- Data storage scalability
i.Designing for scaleThe opportunity for IoT is in the ubiquity of connected devices, the volume of data that those devices will supply, the intelligence to be gained from that data, and the command/control that we can exert on the devices. All of these aspects mean that the solution must be designed to scale at all levels. In many respects, designing an IoT solution to effectively scale carries the same aspects as any large scale solution. While IoT does not require a cloud-based deployment, in most cases, taking advantage of the cloud makes sense because of usage-based pricing, a simple model that scales, geographic availability, and infrastructure support provided by the cloud vendor. Many documents and articles have been written about cloud application scalability and availability. For a good overview of this topic, see “Failsafe: Guidance for Resilient Cloud Architectures.”67 The Microsoft patterns & practices team also has a large body of work on Cloud Development that provides guidance on building scalable cloud systems.68 There are specific scalability areas that come up more frequently in IoT scenarios that may not appear in other IT solutions, however. One area is identity. For web properties, the concept of identity federation has taken hold, and most modern consumer web properties now allow a user to use their identity from other well-known identity stores, such as an account registered with Microsoft, Facebook, Google, Yahoo, and so on. Additionally, corporate accounts can be federated with platform as a service (PaaS) vendors and partners. But with the addition of devices, there will often be identities associated with those devices, relationships between those devices and human identities, and relationships between multiple humans and devices. This potentially complex set of relationships should be considered early in an IoT project, and the solution should strive to simplify these relationships as much as possible. In our project experience we have not yet seen a pattern that satisfies this level of complexity with satisfactory results. The initial projects have used Azure Active Directory for human identities, and external data stores for device identity and the associations with Azure Active Directory users. Design, prototyping, and testing is an ongoing process to find more scalable, resilient and feature complete solutions. Communication and ingestionAnother scalability area that is tested are the communication paths for ingestion. Most solutions will require secure, authenticated communication between devices and the collection point. Additionally, any implementation choice for messaging technology will have scalability points, limits in certain properties, such as messages per unit (for example queue, topic, and so on), and bandwidth per implementation unit (subscription, instance, and so on). These parameters must be well understood, planned for from the beginning of the project, and tested and verified as the architecture and solution progress. Our projects have used the Microsoft Azure Service Bus69, with Azure Active Directory Access Control (ACS)70 keys granted for each device. In a generic solution, some type of secure key must be generated that will make a device unique, and one that only that device knows about. The system it connects to must know about the device and its key, and then verify that they match when messages arrive. The Service Bus and ACS provide these capabilities, making them a good fit. The solutions use Topics and Subscriptions71, and they are designed to take into account the scalability parameters of the Service Bus72, and use as many topics as needed to comfortably support the number of devices in the system and scale to additional topics if and when additional devices are added to the system. Data storage scalabilityScalable data storage is another area that will be important in these projects. Because of the expected volume of data, blob storage will normally be the preferred choice. The reason for this is that blob storage is the lowest cost storage option, and Big Data analysis tools are built to work against blob storage. Depending on the volume and the geographic dispersion of the devices, the solution may need to use multiple storage accounts, and it may also need to move data from collection data centers into a single data center in order to perform analysis on that data. For additional guidance on managing the data, see “Data Management Patterns and Guidance”73 on the Microsoft Developer Network. j.Device registration
|
