EdgeX Foundry - A Microservice Approach to IoT Edge Computing

1 . A Microservice Approach to IoT Edge Computing Jim White - Dell Technologies • May 2018 edgexfoundry.org | @edgexfoundry 

2 .Agenda • The inherent challenges of IoT • Introduce EdgeX – a microservice architecture for the edge • Addressing 5 key challenges of the edge & how microservices help • Microservices no silver bullet – challenges microservice architecture bring • Resource list for more info, call to action edgexfoundry.org | @edgexfoundry 

3 .Who is this guy? • Jim White • Dell Technologies IoT Solutions Division – Distinguished Engineer • Team Lead of the IoT Platform Development Team • Chief architect and lead developer of Project Fuse • Dell’s original IoT platform project that became EdgeX Foundry • Yes – I wrote the first line(s) of code for EdgeX (apologies in advance) • EdgeX Foundry … • Technical Steering Committee member • Ad hoc and unofficial lead architect edgexfoundry.org | @edgexfoundry 

4 .edgexfoundry.org | @edgexfoundry 

5 .Why is IoT hard to do? • Heterogeneity of platforms IoT is a post doctorate in all we know and have • Diverse collection of OS and OS variants done in computing for the last 30-40 years • Linux, Unix, Windows, VxWorks, embedded and RTOS, … • Networks/protocols • Various Hardware (Intel, AMD, ARM,…) • Mobile computing • Distributed compute • Cloud, gateway, smart thing (the “Fog continuum”) • Cloud compute • Thing protocol soup • AI/Machine learning • Industrial: BACNet, Modbus, OPC-UA,… • … • Wireless: BLE, Z-Wave, Zigbee,… • Message: MQTT, AMQP, DDS, … • Variety of cloud platforms • Azure IoT Hub, AWS IoT Platform, Google IoT Core, IBM Watson IoT Platform, … • Add your favorite selection of… • Applications, edge analytics/intelligence, security, system management, … • Difficulties in determining where to start edgexfoundry.org | @edgexfoundry 

6 .Introducing EdgeX Foundry • An open source, vendor neutral project (and ecosystem) • A microservice, loosely coupled software framework for IoT edge computing • Hardware and OS agnostic • Remain agnostic with regard to microservice implementation • Many of the microservices were in Java and are now in Go • C/C++ is envisioned for south side connectors and to address real time needs • JavaScript for UI • Goal: enable and encourage growth in IoT solutions • The community builds and maintains common building blocks and APIs • Plenty of room for adding value and getting a return on investment • Allowing best-of-breed solutions edgexfoundry.org | @edgexfoundry 

7 .A Brief EdgeX History • Chartered by Dell IoT marketing in July 2015 • A Dell Client CTO incubation project (Project Fuse) • Designed to meet interoperable and connectivity concerns at the IoT edge • Started with over 125,000 lines of Dell code • Entered into open source through the Linux Foundation on April 24, 2017 • Started with nearly 50 founding member organizations; today we have more than 75 • Release Cadence: 2 formal releases a year 2017 2018 2019 Oct Nov Dec Jan Feb Mar Apr May Jun July Aug Sep Oct Nov Dec Jan Feb Mar Apr ‘Barcelona’ Release ‘California’ Release ‘Delhi’ Release ‘Edinburgh’ Release (Released Oct 20 2017) (June 2018) (Oct 2018) (Apr 2019) edgexfoundry.org | @edgexfoundry 

8 .Disclaimer • I am not here to sell you on EdgeX Foundry (the product or org) • Although that would be a nice by-product  • I am here to present a microservice based solution to solve some of the more challenging IoT problems • The EdgeX implementation helps to demonstrate (validate?) the concept • Consider the architecture in your decision making • Use our lessons learned where you can • Replicate/duplicate if you must • Join us if you can • If you think the approach correct and you don’t feel like starting from scratch edgexfoundry.org | @edgexfoundry 

9 .EdgeX Primer - How it works • A collection of a dozen+ microservices • Written in multiple languages (Java, Go, C, … we are polyglot believers!!) • Several commonly used library projects (common domain objects, client libraries, etc.) • EdgeX data flow: • Sensor data is collected by a Device Service from a thing • Data is passed to the Core Services for local persistence • Data is then passed to Export Services for transformation, formatting, filtering and can then be sent “north” to enterprise/cloud systems • Data is then available for edge analysis and can trigger device actuation through Command service • REST communications between the service • Some services exchange data via message bus (core data to export services and rules engine) • Microservices are deployed via Docker and Docker Compose edgexfoundry.org | @edgexfoundry 

10 . Cloud, Enterprise, On-Prem… Local Analytics It’s 102◦c Stop the machine 

11 .Performance Targets • The target is to run all of EdgeX on a Raspberry Pi 3 type of device • 1 GB RAM, 64bit CPU, at least 32GB storage space • Additional “developer community” targets • Startup in 1 minute or less (post OS boot) • Latency for one piece of data from data ingestion to actuation will be < 1 second • Remaining OS and Hardware agnostic • Windows, Linux, *nix, … • Intel/Arm 64/Arm 32 edgexfoundry.org | @edgexfoundry 

12 .The Challenges of IoT • #1 Dealing with the diversity • Dealing with the diversity of device connectivity protocols • Working with multiple cloud and enterprise systems • Dealing with multiple IoT data models and data formats • #2 Incorporating any analytics package • #3 Allowing for the continual improvements and upgrades of parts of the IoT solution • #4 Respond to evolving business needs and technological advancements (how to make a ROI in IoT) • #5 Addressing limited resources in an IoT environment edgexfoundry.org | @edgexfoundry 

13 .Problem 1: protocols, models, and formats • IoT is inherently a multi-transform problem • Communicating across multiple protocols, using different data models and formats (JSON, XML, etc.) • From “thing” to edge platform (like a gateway) Gateway Sensor • From edge to application layer or cloud Gateway Cloud Apps • Sometimes from thing to cloud Sensor Cloud • To/from analytics applications Gateway Analytics edgexfoundry.org | @edgexfoundry 

14 .Transformation on the “South Side” • The world of OT protocol soup • Modbus, BACNet, Profibus, CANBus, OPC-UA… • Consumer and traditional IT protocols are also entering the mix • BLE, Zigbee, ZWave, MQTT, SNMP, … • New “things” & protocols are being added all the time • You can never keep up with them all • EdgeX Device Services transform from “thing” protocols and data to common Core Data (micro) Service edgexfoundry.org | @edgexfoundry 

15 .Device Services Core Data Core Command REST/JSON Device Service (per protocol) Driver Sensor/Device Protocol SDK Sensor edgexfoundry.org | @edgexfoundry 

16 .Transformation on the “North Side” • North side endpoints need data… • Filtered • Transformed (data model of choice) • Enriched (add device metadata, location, etc.) • Formatted (XML, JSON, CSV, …) • Compressed, Encrypted, etc. • This is classic EAI (enterprise application integration) • aka pipe & filter architecture • EdgeX Export Services take the data from Core Data and get it to the applications/cloud edgexfoundry.org | @edgexfoundry 

17 . Export Services Export Client Azure IoT Hub Google IoT Core Export Distro HTTP(s) MQTT(s) 0MQ Azure IoT Google endpoint endpoint endpoint Hub IoT Core XML Filter(s) JSON Compress Encrypt CSV Core Data edgexfoundry.org | @edgexfoundry 

18 .Problem 2: edge analytics • Intelligence or analytics at the edge is critical • It’s too expense to transport all the data “north” • It’s too expense to store all the data “north” • It’s too late to react to a problem from the cloud • Your devices/sensors are not always connected to the “north” • How smart does your edge platform need to be? • Simple rule engine smart? • Complex event process (CEP) smart? • Machine learning/AI smart? • The edge platform must be flexible enough to incorporate different capability • EdgeX’s analytic service can wrap and isolate the edge analytic capability edgexfoundry.org | @edgexfoundry 

19 . Rules Engine Service EdgeX Reference Implementation 3rd Party Value Add Export Client Format/ Rules Engine Export Client Format/ Edge Intelligence model as model as required required Export Distro Export Distro REST/JSON REST/JSON Core Data Core Command Core Data Core Command Device Service Device Service edgexfoundry.org | @edgexfoundry 

20 .Problem 3: Fast Continual Improvements • Microservice architecture allows for continual improvements, future break throughs • Ex: device services that do their own device discovery • Ex: streaming analytics over core data/analytics services • Upgrades to microservices without impact to others • Example: upgraded the config/registry service that used Consul 0.8 to Consul 1.0 • Improve performance over time, so they fit on more constrained devices • Ex: Moving from Java to Go for massive performance and footprint improvements • Grow them over time and distribute/migrate them to the cloud • Ex: Machine Learning analytic services with a local edge agent • Promote best of breed solutions • Allow specialization to occur edgexfoundry.org | @edgexfoundry 

21 .Problem 4: Differentiation and Value Add • EdgeX was created with commercialization in mind!!! • Allow for value additions • RedHat style commercial support packages (IoTech) • Improved data synchronization between edge and cloud (MongoDB) • Edge analytics customized for the vertical or use case (many orgs) • Security features to protect trust devices, secure the data, etc. (RSA) • Allow for low/no value commodity to be taken care of by a community • Ex: open logging probably suffices for a large part of the user base • Allow specialization to demand higher price • Ex: IoTech creating a real time extension on the south side for embedded systems • Ex: Aicas using Jamaica and other technologies to run faster/smaller Java microservices • Provide incentive to commercial (even competing) companies and reason to support an open source effort edgexfoundry.org | @edgexfoundry 

22 .Problem 5: How to maximize the use of resources • From sensor to cloud, there exist a continuum of • Compute • Storage • Networking/connectivity • Management • Security • How can all these resources be maximized? • Sensors will get more compute and storage • Pipes to the cloud may get bigger edgexfoundry.org | @edgexfoundry 

23 .Microservice Distribution • Microservices can live where they can get the resources they need • With a tendency to push to the south • Latency needs • Storage and transportation costs • Disconnected modes • Allow the microservices to adapt to the use case • Requires extremely loose coupling • In some uses, microservices might be collapsed or combined edgexfoundry.org | @edgexfoundry 

24 .EdgeX Flexible Deployment Possibilities Core Export Analytics Services Services Device Service Cloud Device Service Gateway Cloud Device Core Export Analytics Service Services Services Cloud Gateway Fog Server Device Core Export Service Services Analytics Services Embedded Cloud Device Services Fog Server Core Export Analytics edgexfoundry.org | @edgexfoundry Services Services 24 

25 .Microservices challenges • Microservices offers aid to addressing some of the significant IoT issues • A microservices architecture inherently introduces challenges • Performance • More microservices = more communications • More communications = more latency concerns • Orchestration • Deploying microservices (especially when distributed across platforms) • Managing/updating microservices • Configuring (how to provide platform dependent/environmentally dependent configuration to each service) • Registering (how does one service know where to go to get another service) • Getting status/health (where microservices are dependent on one another, how do you know a microservice is up and ok) • More points of failure • Security – more interfaces and endpoints to secure edgexfoundry.org | @edgexfoundry 

26 .Addressing Microservice Challenges • Performance • Combined/collapsed services on occasion • Real time versions or components are being developed (IoTech EdgeX RT) • A bevy of products can help with deployment and orchestration • Docker, Compose, Snappy, Kubernetes, Mesos, Swarm, … • Combine some services to reduce points of failure • Security services offer some of the most opportunity for 3rd party value add • Ex: take advantage of hardware root of trust • Ex: distributed ledgers/blockchain • Cloud and system management tools have addressed many of the points of failure issues • Provides many know solutions to take advantage of edgexfoundry.org | @edgexfoundry 

27 .Now Backed by 70+ Members edgexfoundry.org | @edgexfoundry With more in process! 

28 .Current Status • EdgeX California Release on track for release at the end of June 2018. Key features include: • Initial security building blocks (reverse proxy, secure store) • Most services transitioned from Java to Go (exception: device services and SDK) • Dramatically improved performance, resource usage, and footprint (~7x reduction in size) • Already hitting our system performance targets • Additional “northbound” connectors • Improved documentation (documentation treated more like code in its management) • Arm 64 support • Blackbox testing for all services • Improved continuous integration • Technical Steering Committee meet in Palo Alto, June 4-6 • Scoped next release (code named Delhi) due Oct 2018 • Roadmapped future releases (Edinburgh – Apr 2019, Fuji – Oct 2019) • Current membership: ~70 companies/organizations • Code contributions from ~40 developers edgexfoundry.org | @edgexfoundry 

29 . EdgeX Releases 2017 2018 2019 Oct Nov Dec Jan Feb Mar Apr May Jun July Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun July Aug Sep Oct Nov Dec ‘Barcelona’ Release ‘California Preview’ ‘California’ Release ‘Delhi’ Release ‘Edinburgh’ Release ‘Fuji’ Release (Released Oct 20 2017) (Made available Jan 2018) (Released June 2018) (Oct 2018) (Apr 2019) (Oct 2019) • Improved fit and finish, • Drop-in Go Lang • First integration of • Additional security and • Certification Program • Load balancing formalized Core Service microservice security first manageability replacements • Improved and more • Multi-host EdgeX APIs, additional Device capabilities • Run in < 1 GB RAM, scalable northbound and Export Services, test demonstrating • Additional security reduced footprint come up in < 30 sec, • Go / C device service connectors and system apparatus < 1 second actuation SDKs and higher • Southbound management latency performance • EdgeX UI connectors to capability common protocol devices • ARM 32 support edgexfoundry.org | @edgexfoundry