Web2Day 2016: Clearing the fog in fog architecture or distributed computing as an IoT enabler

IoT is at the height of the hype cycle. But only now is starting to get serious. This talk is an overview on how enterprise level projects in IoT are done. The gateway and the edge network are essential categories. This type of network architecture goes by the name of fog computing. What's in it? How do "serious" IoT projects are setup?

Transcript

1. Clearing the fog in fog architecture or distributed computing as an IoT enabler Web2Day Nantes Antonio Almeida developer & product evangelist at relayr antonio@relayr.io June 15, 2016
2. IoT?
3. the promise of IoT I
4. the promise of IoT II
5. IoT 101: constrained devices low computing power: CPU, memory, etc unreliable networking: mesh, 6LoWPAN, BLE low power consumption: small duty cycle RFC 7228
6. IoT 101: system architecture
7. question: what is fog computing?
8. problem I: cloud centric architecture device to cloud communication centralized cloud to cloud distributed a lot of implicit assumptions
9. problem II: large numbers
10. problem III: assumptions bandwith is assumed to be large connectivity is assumed to be good to great latency is admissible to a certain degree network is physically public
11. problem V: bandwith is expensive
12. problem VI: connectivity is unreliable
13. problem VII: latency is critical - realtime requirements
14. problem VIII: security - exposing valuable data to the world
15. definition I: fog computing fog computing is like cloud computing but closer to the edge
16. definition II: distributed at the edge fog computing is pushing distributed systems from the data center to the edge
17. definition III: physical world fog computing is about reactive systems that interact with the physical world from the data center to the edge
18. the future is already here The future is already here — it’s just not very evenly distributed. William Gibson
19. the future is already here: LHC CERN as an example I
20. the future is already here: LHC CERN as an example II the largest machine in the world built for testing hypotheses of particle and high-energy physics generates tens of petabytes (10005 bytes) per year requires very well thought out data sensing, operation control and asset management scheme
21. the future is already here: LHC CERN as an example III
22. the future is already here: LHC CERN as an example IV
23. the future is already here: LHC CERN as an example V
24. design: peer to peer new approach to designing the system peer to peer (p2p) client-server node distinction gets fuzzy
25. practice: building a simple sensor node build a sensor node that uses CoAP acts both as a client and a server coding time in Lua
26. the sensor circuit temperature sensor DS18B20
27. relayr developer dashboard sign up here: http://hubs.ly/H03bvTL0 create a model for temperature with range [−55, 125] ◦C
28. now the gateway remember distributed computing we’re going to apply the same ideas micro-service based architecture multiple services that talk among themselves through an event bus
29. components I: event bus must be lightweight - lighter than Apache Kafka all messages are put on the bus the relevant service selects what is for it like a data river
30. components II: local data store if the uplink to the cloud is down if we want to accumulate messages to send in batch if we want to use the data as is being collected if we want to provide better (distributed) data integrity
31. components III: authentication & authorization control access to devices from other devices control access to data streams (sensors) control the access to devices from the outside control access to actuators
32. components IV: device registry & management update the firmware on the devices list device capabilities have overview of device availability (healthcheck) update code running on top of the firmware - if applicable
33. components V: output filters to provide data compression to provide data in multiple serialization formats to inject metadata into the output data stream to convert between different units between edge and cloud
34. components VI: rules engine to allow us to control certain actuators to take the appropriate action for the given event to allow for basic filtering of data to execute self-heal processes based on certain activated rules
35. components VII: analytics - streaming data to actuate based on collected data on the edge to reason about the processes being monitored to extract valuable information as the data is collected to avoid over-dimensioned data warehousing with all associated costs
36. components VIII: firewall & bridge to protect data streams from external access to implement private clouds at the edge to convert between different protocols (e.g. 6LoWPAN vs IPv6) to allow access from the outside to particular devices - with or without NAT (IPv6)
37. a simple solution use a CoAP to HTTP proxy this allows to immplement all services as ReSTful web services leverage all free software out there written for implementing web based nicroservices,
38. hands-on: build first layer CoAP to HTTP proxy: bidirectional modify it to include the necessary headers we have the first component of the gateway now
39. I rest my case
40. thank you