IBM Open Horizon Demo For Edge X Systems

IBM Open Horizon Demo For Edge. X Systems Management Working Group May 28, 2019

From: https: //github. com/open-horizon/

Background • History • IBM began Horizon development mid 2015, demo at Io. T World Forum 12/2015 • Previously named Project Mountain, then Blue Horizon, now Open Horizon • Actively developing the project • Focus & Technology • Targeting the Edge Gateway/Controller and Device tiers of Edge Computing • Works with Linux variants and OSX, x 86_64 and armhf, 32 - and 64 -bit • Written in Golang and Scala • Solution to enable application and analytics management at scale: • Containerized workloads • Metadata • ML/DL models

Edge. X’s Tiered Edge Deployment Multiple gateways with the number of deployed microservices and functionality increases higher in tier Edge. X allows you to ingest sensor data locally to respond with simple rules, while pushing aggregate data higher up for more intelligent analysis and control From: https: //www. edgexfoundry. org/get-started/deployment-patterns/

Tiered Edge – with Asset Synchronization, and ML/DL Scoring and Inferencing Multiple gateways with the number of deployed microservices and functionality increases higher in tier Edge. X allows you to ingest sensor data locally to respond with simple rules or local analytics, even when disconnected, while making data available at rest or pushing aggregate data higher up for more intelligent analysis and control HORIZON Agent HORIZON Svcs Edge Sync Service Cloud Sync Service Modified from: https: //www. edgexfoundry. org/get-started/deployment-patterns/ Choice of Orchestration and ML Pipeline Solutions

Potential Integration INTEGRATION WORK NEEDED HORIZON MANAGEMENT HUB / PLANE HORIZON Agent Modified from: https: //www. edgexfoundry. org/get-started/ IBM CONTRIBUTED CODE

Component Architecture • Exchange • Switchboard • Sync • Ag. Bots • Agent Horizon architecture is as decentralized as possible. It manages applications and analytics automatically on all of your Edge Nodes without any manual intervention. Decentralized and fully autonomous Agent processes run on each Edge Node, governed by policies specified when the machine was registered with the Horizon Management Hub. Decentralized and fully autonomous Ag. Bot (short for "agreement 'bot") processes can run in any deployment tier (even on Edge Nodes). Like Agents, the Ag. Bots are governed by policies configured when they were created. Horizon includes three centralized services: Exchange, Switchboard, and Sync. These services have no central authority over the autonomous Agent and Ag. Bot processes. Instead they just provide simple discovery and metadata sharing services (the Exchange) and a private mailbox service to support peer-to-peer communications, even when the peers are behind firewalls (the Switchboard). They support the fully autonomous work of the Agents and Ag. Bots. Each of the five Horizon component types has a small and tightly focussed area of responsibility, and each has no authority or credentials to act outside their focus area. From: Horizon documentation, in progress

Placement Policies

Backup

Exchange Service The Exchange API provides services for the exchange web UI (in progress), the edge nodes through the Agent client, and Agreement Bots. The exchange service also provides a few key services for Horizon in areas where the decentralized P 2 P tools do not scale well enough yet. As soon as the decentralized tools are sufficient, they will replace these services in the exchange. • API Swagger Docs: https: //stg. edgefabric. com/api? apis. Sorter=alpha&operations. Sorter=alpha&url=https: //stg. edge-fabric. com/api-docs/swagger. json#/default • Exchange source code: https: //github. com/open-horizon/exchange-api From: Horizon documentation, in progress

Switchboard Service Ag. Bots periodically poll the Horizon Exchange to find all Edge Nodes registered for their Deployment Pattern. When an Ag. Bot discovers a new Edge Node registered with its pattern, it uses the Horizon Switchboard to send a private message to the Agent on that node. That message proposes that they should collaborate on managing the software lifecycle of this pattern on that node. The Agent meanwhile is polling its private mailbox on the Horizon Switchboard for Ag. Bot proposals. When a message is received, the Agent decrypts it, validates it, and responds to accept the proposal. In addition to polling the Exchange, each Ag. Bot is also polling its private mailbox in the Switchboard. When it receives an acceptance from an Agent, the negotiation is complete. Both Agents and Ag. Bots share their public keys with the Horizon Switchboard to enable their secure and private communications. All messages are encrypted by the sender before they are sent to the Switchboard. The Switchboard is incapable of eavesdropping on the messages because it lacks the necessary keys to decrypt them. The receiver on the other hand, is able to decrypt any message encrypted with its public key. Similarly the receiver will use the other party's public key to encrypt its replies. This approach makes the Horizon Switchboard just a simple mailbox manager. Even if corrupted, the Horizon Switchboard remains incapable of eavesdropping on any of the conversations between participants occurring privately through its mailboxes. Note also that since all communications are brokered through the Switchboard, the IP addresses of the Edge Nodes are not revealed to any Ag. Bot until the Agent on each Edge Node chooses to reveal this information, once the two parties have successfully negotiated an agreement. From: Horizon documentation, in progress

Sync Service The Sync service is designed to simplify applications that run on the edge by providing a separation of concerns between micro-services and related assets. It is a tool to synchronize objects between origin and destination. Users of the Sync service can create/update an object in the cloud and the object is then automatically propagated to the relevant Edge Nodes. Similarly, an object can be updated on the edge and delivered to the cloud. Example use cases include synchronization of configuration, rules and actions, user preferences, AI models, monitoring statistics, deployment files, and more. • https: //github. com/open-horizon/edge-sync-service • Clients in Go, Java, Python: https: //github. com/open-horizon/edge-syncservice-client From: https: //github. com/open-horizon/edge-sync-service

Agreement Bots Each Edge Node registers with the Exchange for a particular Deployment Pattern. An Ag. Bot for the Deployment Patterns finds the Agent on the Edge Node through the Exchange and communicates with it through the Switchboard to negotiate collaboration. The Agent will then evaluate the proposal from the Ag. Bot to ensure it complies with policies set by the Edge Node owner. It will also verify the cryptographic signatures using its locally installed key files). If the proposal is acceptable according to the local policies and the signatures are verified, then the Agent will accept and this formalizes their agreement. Next, the Ag. Bot and the Agent collaborate to manage the software lifecycle of the Deployment Pattern on the Edge Node. The Ag. Bot provides details as the Deployment Pattern evolves over time, and monitors the Edge Node for compliance. The Agent locally downloads software on the Edge Node, verifies it signature, runs it, monitors it, updates it and terminates it as appropriate. From: Horizon documentation, in progress

Agent Client An Agent is born at the moment when the Horizon software package is installed on an Edge Node. After it has been registered with the Exchange, the local Agent will begin polling the Switchboard, waiting to receive offers of collaboration from remote Ag. Bot processes. When the Agent has been discovered by an Ag. Bot for its specified Deployment Pattern, that Ag. Bot will reach out to negotiate with this Edge Node. Once in agreement, the Ag. Bot will send the information detailed in the previous section to the local Agent on the Edge Node. The local Agent will then proceed to pull the specified resource from the appropriate origins, and launch them in reverse dependency order with the specified environment configurations (after verifying their hashes and cryptographic signatures). • Nicknamed Anax, the source code is at: https: //github. com/open-horizon/anax • The APIs are documented at: https: //github. com/open-horizon/anax/blob/master/doc/api. md From: Horizon documentation, in progress

Orchestration vs Edge Delivery Common application orchestration tools distribute copies of services to a scalable pool of resources in a manner optimized for the operator-specified target goals: speed or cost or location or other weighted metrics. Targets typically number in the 10 s to 100 s, sometimes as high as 1, 000 s. Edge Delivery requires a different approach. It securely distributes both services and metadata (ML models, for example) according to specific placement policies and delivers the correct match to a fixed pool of devices and compute nodes in an automated fashion while failing gracefully. Targets typically number in the 100 s to 1, 000 s, sometimes as high as 1, 000 s/

Device Edge to Device Edge • • • X 86 / ARM Compute Scale: None Network: Wi-Fi, NB-IOT, 5 G Latency: <2 ms Storage: Filesystem Cloud On-Premise/Far Edge Telco Networks/DCs • • • X 86 / ARM Compute Scale: Limited Network: 5 G, LTE, Wi-Fi, Wireline Latency: <5 ms Storage: Local • • • X 86 / ARM, some GPU Compute Scale: Limited, On-Demand Network: Telco Network, 5 G Latency: <10 -50 ms Storage: Local Public Cloud • • • X 86 / ARM, GPU, Mainframe Compute Scale: Hyperscale Network: Backbone Latency: <20 -100 ms Storage: Managed Hyperscale Source: LF Edge/IBM Draft Workloads Edge to Cloud (April) Device Edge Control Edge Thin GW / Compute Edge Thick GW / Compute Edge Industrial/Telco/ MDC HCI Edge On-Premises DC Edge Telco/Cloud Edge Source: LF Edge - Functional View Draft (January 2019)