-
Notifications
You must be signed in to change notification settings - Fork 0
APIs for Things
An open discussion to discover what is needed for the development of Internet of Things (IoT) applications and services.
- Market Estimates - Billions to Trillions of potential revenue and market value
- Market - early days, starting slowly but nothing has fully taken hold in the development community
- Developer Estimates - 17% now, 23% January, 2015 with expected annual growth at 27%
- Vertically focused on micro-services. One function per application.
- Cisco Grand Challenge 250k award
- Submissions must be entered into one of five categories: Applications and Application Enablement, Analytics, Management, Networking, or Things.
- Each submission must map to one of a variety of industries Education, Energy, Healthcare, Manufacturing, Oil and Gas, Retail, Smart Cities, Sports and Entertainment or Transportation.
- Device diversity
- Fully formed OS's versus Mini or Micro Operating Systems
- Variation in connectivity - wired & wireless
- Device "fleet" management
- Security - Authentication mechanisms for smaller devices
- New Protocols such as CoAP and MQTT
- Development Requirements
The IoT discussion began with a level set across the participants regarding IoT current state and market potential. After initial discussions it became evident that there are going to be new models of how to create, maintain, and operate applications and devices across a large IoT landscape.
Carl noted that his previous experience with scale would probably involve different models of the state of a device or system. His suggestions revolved around the need for more probabilistic models for determining the state of a system. The canonical example was the sensor enabled bridge where the application monitoring the bridge needed to determine the difference between a large truck crossing over versus an earthquake. I believe we agreed that scale in a large IoT application would need different models (more later).
We had a lengthy discussion around the different protocols which may be required for these devices in addition to HTTP and REST. We discussed the use of Constrained Access Protocol (CoAP), the messaging protocol MQTT, and the notion that current protocol overhead may be larger than some payloads. Single integer readings or large Hypermedia formats for example. I believe this discussion and the session later in the afternoon on protocols were stating a potential problem. There doesn't seem to be enough work in this area to determine if this is an actual issue at this time.
Regarding the protocol discussion here is a Slideshare article on Internet of Things protocols.. And here is an InfoQ presentation on the same topic with video.
Getting back to the architecture needs Brian Mulloy discussed what APIgee was doing in their lab around IoT and different application architectures. In short Brian brought up the notion of using a graph model for their architecture where the applications which managed the IoT devices performed the function of a node within a graph and were connected across their edges via RESTful APIs. The nodes acted as proxies to the local devices (Arduino, Pi, etc) and presented a Hypermedia API to the other nodes in the graph without having some of the design constraints of the smaller form factor devices. The APIgee team noted the graph based architecture was useful such that each node connected to the graph was able to be managed by any other node in the topology.
The last part of our discussion surrounded the potential for cross pollination of ideas from Engineers who perform low level device work ("Born to Suffer") versus the Web 2.0 engineers who require the agility to meet or make a market. This "culture clash" would benefit both sides as the quality and detail required to keep devices running for extreme life meets an agile world. The group felt this was good for both sides - but expect some friction in the short run. The group also felt that the quality of engineer and previous learning from the "Born to Suffer" Engineers will have a lot to bring to the table as they have solved many difficult issues in this area already.
Security was recognized as an overall issue from a device and network perspective. This is a larger issue that the group wasn't ready to take on in this initial meeting. Note the Bitid and Bitauth links below as potential methods to solve for IoT security on small form factor devices (maybe).
- Location Case studies
- Public playground of things
- IoT-craft Google group
- Day2 - Protocol sessions
Eclipse Article on IoT Protocols
- Chris Wilson
- Adam Magaluk
- Carl Zetie
- Brian Mulloy
- Kristopher Kleva
- Matt Bishop
- Glenn Block
Forgive me if I missed your name, please add if you attended. Thank you.
Christopher Wilson
@datamoor