#GlueCon 2014: APIStrat UnWorkshop Notes – Internet of Things

APIStrat UnWorkshop – Internet of Things

• Why HTTP Won’t Work for IoT – Tim Kellogg @kellogh
  • Embedded + Internet = IoT
  • Constrained environments – memory, embedded linux, No OS, unreliable network connectivity
  • Telemetry – device to server; sensor readings; big data & analytics
  • HTTP is request/response, not pub/sub
  • Consumer must be avail at all times; publisher needs to know exact dest; publisher depends on response status
  • MQTT – broker must be avail at all times; pub/sub decoupled (at leisure); publisher doesn’t care who is subscribed, vice-versa
    • QoS – 3 levels: 0 (fire and forget), 1 (guaranteed delivery at least once), 2 (guaranteed delivery only once)
    • Hierarchy of topics
    • Last value available in case of disconnect
    • MQTT-SN extension for sensor networks w/ UDP and config-free discovery support
  • Constrained Application Protocol (CoAP)
    • HTTP mappings for proxy servers
    • GET+Observe for updates when the resource changes – no polling
  • Book: Mastering the Internet of Things
• What can you do with connected cars? – Bret Tobey @Carvoyant
  • Big market with complex interfaces reducing developer adoption
  • Lots of opportunity to see how to intersect other APIs, data, and intelligence when we can connect to our cars
  • Many devices are 8-bit, use 2G network w/ UDP, require complex code to fix or integrate
  • Carvoyant tries to normalize across all makes, models, and even differences in the same make/model
  • “Cars drive in realtime, but they weren’t designed to talk in realtime” – on why you can’t sample data every 1 sec, but rather 5 min
• Greg Burns – Qualcomm
  • AllSeen Alliance – https://allseenalliance.org/ (Chief Architect, working on it for 5 years) – focused on IoT
  • AllJoyn Framework – https://allseenalliance.org/allseen/framework
  • Protocols/interactions different on a private/home network than publishing to cloud where servers might not talk together
  • “Smarthubs” for the home re: rules engines in the home vs. rules engines in cloud services
• Pushpin & GRIP: next-gen realtime – Justin Fanout.io
  • Passionate about federation and open standards
  • Cloud service for realtime push for API creators with open source server code
  • Scaling realtime push
    • Scaling requires delegation from app to edges to clients
    • Scaling pull traffic is transparent via Varnish, Squid, etc
    • Scaling push traffic has no generalized tools, often proprietary interface, requires engineering to code for it, often by hand
    • Pushpin is the proxy server (aka Varnish for realtime), works for HTTP and websockets w/ full control over client-to-edge interface (to the byte level)
    • Pushpin targets APIs, focused on the backend protocol
    • https://github.com/fanout/pushpin (Mongrel2, 0MQ)
    • Engineers target GRIP protocol, DevOps manages the edges as they see fit
    • Goal is to offer more implementations for Nginx, Apache, etc.
• Shawn Rose – CIO ecovent
  • Techstars Boston
  • Automated vents that open and close (replaces old metal vents) and sensors to control the temp of each room
  • 4 systems installed w/ -13F and -30% energy use
  • Interact with the NEST API, internal APIs for mobile control
  • How to build APIs for the end user?
• Canary.io – Open monitoring for the web – http://www.canary.io/
• Pat Patterson – Developer Evangelist Architect – Salesforce.com @metadaddy
  • Helping to move medical fridge from a clipboard system of what inventory was removed to an automated system using a barcode reader + smartcard to scan supplies that have been removed, then reported in realtime
• Do we really need realtime for IoT?
  • Vehicle-to-Vehicle is great but 25 yrs out as it requires a lot of other infrastructure to exist first
  • This is because the IoT has too many variables, both in hardware (the Things part), network (the Internet part), and software (the APIs)
  • Hardware realtime is different than software realtime and each often have different SLAs (tech-driven, not legal/sales-driven)
  • Near-realtime is what people probably mean, not realtime (< 5 ms latency)
  • Devices are limited by battery and compute power to push realtime data
  • This likely means subscriptions are really what are needed, so that interested parties can be informed of events
  • Push is common here for updating web apps without a refresh
  • Realtime definition is relative to the device, app, and end-user and should be specified as benchmarks to clarify intent and staleness
  • Data flow has a distinct impact (device-to-bluetooth-to-mobile, device-to-2G-to-cloud-to-API availability)
  • This means that systems must be designed to be fault-tolerant of missing data
• Summaries from other groups:
  • Data-driven API design vs. User-experience-driven design
  • Kin sees lots of traffic about API design, markup, and RAML
  • Use the markup that meets your team’s workflow
  • Markup is being driven by auto-generated client and server stubs more than documentation
  • apis.json as a README for APIs (tweeted out) – http://apisjson.org/