devopsy.kinsta.cloud

Tag: LF Edge

  • Onboard edge computing devices with SDO and Open Horizon

    By Joe Pearson, Engineering Strategy and Innovation Leader, IBM Edge Computing

    For many companies, setting up heterogeneous fleets of edge devices across remote sites has traditionally been a time-consuming and sometimes difficult process. This week at the Open Networking & Edge Summit conference, IBM announced that Intel’s Secure Device Onboarding (SDO) solution is now fully integrated into Open Horizon and IBM Edge Application Manager and available to developers as a tech preview.
    The Intel-developed SDO enables low-touch bootstrapping of required software at device initial power-on. For the Open Horizon project, this enables the agent software to be automatically and autonomously installed and configured. SDO technology is now being incorporated into a new industry onboarding standard being developed by the FIDO Alliance.
    Developers can try this out by using the all-in-one version of Open Horizon. Simply run a one-line script on a target edge compute device or VM and simulate powering-up an SDO-enabled device and its onboarding.
    Both Open Horizon and SDO recently joined the LF Edge umbrella, which aims to establish an open, interoperable framework for edge computing independent of hardware, silicon, cloud, or operating system. Thanks to IBM’s participation in the LF Edge open source community, contributors in the community are helping advance the future of open edge computing solutions.
    Simplifying edge device onboarding
    Our team uses the term “device onboarding” to describe the initial bootstrapping process of installing and configuring required software on an edge computing device. In the case of Open Horizon, that includes connecting it to the Horizon management hub services. We have simplified the software installation process by providing a one-liner script, so that a person can install and run a development version of Open Horizon and SDO on a laptop or in a small virtual machine.
    Before SDO was available, the typical installation process required a person to open a secure connection to the device (sometimes on premises), manually install all of the software pre-requisites, then install the Horizon agent, configure it, and register it with the management hub. With SDO support enabled, an administrator simply loads the voucher into the management hub when the device is purchased and then associates the configuration. When a technician powers on the device and connects it to the network, the device automatically finds the SDO services, presents the voucher, and downloads and installs the software automatically.
    Integrating SDO into Open Horizon
    The Open Horizon project has created a repository specifically for integrating the SDO project components into the Open Horizon management hub services and CLI. The SDO rendezvous service runs along side the management hub and provides a simple interface to bulk load import vouchers.
    Visit SDO GitHub
    LF Edge and open source leadership
    The LF Edge organization continues to strive to ensure that edge computing solutions remain open. In May 2020, IBM contributed Open Horizon to LF Edge. With Intel also contributing SDO to LF Edge, this ensures that another vital component of a complete edge computing framework is also open source.
    We’re excited to collaborate with Intel to expand the deployment of applications from open hybrid cloud environments down to the edge, making them accessible, secure, and scalable for the developer ecosystem and community.
    Visit our booth to watch the demo
    The virtual demo will premiere this week at the conference. Videos will be available in the virtual booth and via the LF Edge YouTube Open Horizon plalist, and representatives from both IBM and Intel will be on-hand to answer questions.
    The booth schedule is:

    • Monday, September 28. The booth is open 9:00 – 10:15 AM, EST. Booth Crawl at 4:00 – 5:30 PM, EST.
    • Tuesday, September 29. The booth is open 9:30 – 11:30 AM, EST.
    • Wednesday, September 30. The booth is open 10:00 – 11:30 AM, EST.
  • Harmonizing Real-Time on Edge Platforms

    Harmonizing Real-Time on Edge Platforms

    Edge computing platforms sit at the boundary between the real-time world and the digital enterprise. Uninterrupted, uncorrupted data from the edge is a must if analytics in the cloud drive reliable business decisions. What’s the best approach: using Linux, an RTOS (real-time operating system), a hypervisor or something else for edge platforms?  Let’s talk about harmonizing real-time on edge platforms and introduce a new foundation project in the Linux Foundation’s LF Edge family.

    Real-Time and Deterministic

    Real-time only means events are captured, tagged and processed as they unfold in the real world. That cadence can be seconds, milliseconds or microseconds depending on how many events and how often they occur and how tasks and algorithms stay in control. Three operating system characteristics determine how well real-time execution keeps pace: prioritization, interrupt response time and context switch time.

    Prioritization ensures that tasks receive resources when needed. Tasks at a lower priority should pre-empt when a higher priority task requests service. A task refusing to yield to pre-emption can throw off the prioritization scheme, causing missed deadlines.

    Interrupt response time measures the latency from the time an event requests service via a hardware interrupt to when the handler task executes. Real-time hardware platforms often place high-priority events on hardware interrupts for fastest pre-emption.

    Context switch time is softer scheduling at work. It measures the time for a change in processing control from one execution entity to another, swapping out resources including registers, cache and memory as needed.

    Deterministic means there are no surprises in behavior. The faster real-time events happen, and the harder a system works, the more likely non-determinism surfaces. One venture into virtual memory paging or a burst of networking activity can show up at an inopportune time, even though under most conditions real-time performance is adequate.

    ‘Hard’ vs. ‘Soft’ Real-Time

    That’s why most people think of real-time as “hard” with a fast, deterministic operating system. RTOS platforms optimize the kernel and only build things in around it that are necessary, providing rigorous and sometimes mathematically proven scheduling for many tasks.

    “Soft” real-time is more forgiving. On a fast processor, interrupt response time is tiny compared to the execution window. A system that isn’t deterministic can, if there is enough margin in context switch time, keep up with real-time events on a slower scale. Linux, while not deterministic, can handle some real-time needs through minimizing packages and tuning the kernel for better prioritization.

    Linux also benefits from lighter context switching. Originally, execution entities in Linux were resource-heavy processes. Now, threads can handle tasks with far less switching overhead. POSIX threads standardized the approach with portability between Linux and RTOS environments.

    How fast are threads? According to a recent synthetic thread benchmark by Eli Bendersky, switching on server-class platforms with enough memory, cache and storage can be in the range of 2 microseconds with 10,000 threads under ideal conditions. Eli pointed out his test environment has more RAM than many edge hardware platforms provide, but most edge applications won’t need that many threads, either.

    So, the line for soft real-time has moved down into new territory, making the trade-off between hard and soft a bit blurrier.

    Hypervisors and Orchestration

    If your DevOps team commits to an RTOS, you may give up some familiar functionality and have a learning curve to deal with, but you get assured hard real-time performance. If you go with Linux, you get the tools and coding practices you’re used to, but soft real-time performance can be an issue as code piles up.

    The leaders in RTOS platforms with enterprise networking noticed this, too. Recently they’ve turned to hypervisors in a bare-metal approach. A hypervisor can capture the benefits of environments working together, so teams are not forced into an either/or operating system choice. This is especially important if the edge application requires some form of certification, such as in medical, industrial or defense applications. Certified code can be compartmentalized on an RTOS, while Linux runs alongside.

    Linux providers are turning more toward orchestration layers and containers. It’s an application focus speeding up deployment, with more scalability and less hardware dependence. It also brings the edge into the enterprise faster with the same application deployment strategy anywhere. More code means more determinism risk.

    Convergence is a faint hope on this landscape with competing objectives, but a new approach offers a path for software reuse and rapid deployment.

    Harmonizing the Edge

    The Linux Foundation is active across the spectrum of IoT development, from the Zephyr open source RTOS to various embedded Linux projects. One of the newest projects in the LF Edge initiative is a foundation targeting a blend of deployment models in a consistent, open approach.

    Project EVE (short for Edge Virtualization Engine) supports containers, clusters, virtual machines and unikernels simultaneously. It’s a slim bare-metal runtime offering hardware root of trust, device resource management and software update and patch functions. EVE can host any combination of apps in virtual machines or containers, including running an RTOS with its application in a virtual machine. It can even assign CPU and GPU cores to specific applications for enhanced determinism.

    On the EVE road map is support for the ACRN hypervisor (another LF Edge project) and shrinking the EVE runtime for smaller embedded-class edge platforms. These efforts are essential where real-time requirements become harder and a hypervisor plus an RTOS makes sense. For softer real-time environments, EVE is adding support for Kubernetes K3S, Docker Compose, VPNs for public clouds and mesh networking for data flow between edge platforms.

    While the project is still young, EVE holds great promise for DevOps teams working the edge. We’d look forward to seeing some benchmarking on a real-time scale; it likely handles soft real-time needs as well as Linux today. By harmonizing a range of diverse approaches into one foundation, EVE is creating a space for real-time on edge platforms no matter which development perspective teams come from.