James Higginbotham

API Architect

#GlueCon 2014: APIStrat UnWorkshop Notes – Internet of Things

3 minute read

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/

You May Also Enjoy