Updating the Edge

A presentation at Kubernetes and Cloud Native Virtual Summit in April 2020 in by Kat Cosgrove

Slide 1

Update Strategies for the Edge There’s a better way. @jfrog

Slide 2

Kat Cosgrove IoT Engineer Developer Advocate Twitter: @Dixie3Flatline Email: katc@jfrog.com jfrog.com/shownotes @jfrog

Slide 3

How large is the Edge? @jfrog

Slide 4

20,400,000,000 That’s a lot of devices. @jfrog

Slide 5

Updates Today They don’t update; device is effectively single-use OR It’s time-consuming, complicated, or requires physical access @jfrog

Slide 6

Why change? @jfrog

Slide 7

It’s beyond inconvenient Edge computing is massive and growing

Consumer - Industrial - Medical Slow OTA updates are annoying Wired updates are expensive and more annoying @jfrog

Slide 8

It’s dangerous Unpatched bugs can be a huge vulnerability

Expose private data Harnessed for a botnet Used for cryptocurrency mining Safety implications for medical @jfrog

Slide 9

What’s slowing us down? @jfrog

Slide 10

Not building for it. Many devices are not made to be updated.

Designed to run one version until the end - “Update strategy” here is flashing the device - Bugs are inevitable @jfrog

Slide 11

Between 1 and 25 Number of bugs per 1000 LOC @jfrog

Slide 12

Connectivity Concerns We can’t rely on the device’s network

Networks may be unstable - Bandwidth may be low - Network probably isn’t secure @jfrog

Slide 13

Hardware Variations - It’s 20.4 billion devices - Lots of specialized hardware - Variations in memory, storage space, architecture How do we design something that handles so much variety? @jfrog

Slide 14

Think future-forward. Updates are your friend. Embrace updates, not security nightmares. @jfrog

Slide 15

Get better with age. Your product should not be getting worse from the moment it ships. @jfrog

Slide 16

Build robust. Brittle software means a brittle device, and that doesn’t inspire trust. @jfrog

Slide 17

Modern DevOps tools. Your developers will thank you and things will run more smoothly. @jfrog

Slide 18

The Proof of Concept @jfrog

Slide 19

Slide 20

Cars Now - Majority not designed for OTA updates OTA updates are still slow and inconvenient Little standardization Significant portion of recalls are due to software @jfrog | Copyright © 2019 JFrog. All Rights Reserved

Slide 21

Cars as Edge Devices - Presented a range of solvable pain points in one device - Tangible example for end users and manufacturers - Device in question meant speed, reliability, and safety were equally important @jfrog | Copyright © 2019 JFrog. All Rights Reserved

Slide 22

Slide 23

Two Distinct Workflows Software Updates Firmware Updates

Without flashing firmware - No interruption of user - Takes only seconds - Relies on K3S and Helm @jfrog |
More difficult update - Takes only minutes - Rollback if there is a failure - Relies on Mender, Yocto, and Artifactory Copyright © 2019 JFrog. All Rights Reserved

Slide 24

Slide 25

Slide 26

Slide 27

Slide 28

Slide 29

Slide 30

Slide 31

Slide 32

Helm “Charts” describe complex applications

Slide 33

Slide 34

The Result - Software Application updates are quick and efficient

Average of 35 seconds from dev to car No interruption for the user Can happen while device is in use Could happen silently, depends on device purpose @jfrog | Copyright © 2019 JFrog. All Rights Reserved

Slide 35

Slide 36

Slide 37

Slide 38

Mender Overview Ticks several of the boxes we’re looking for:

Slide 39

Mender - A/B Two partitions are on the device

Bootloader aware of “active” - Update streams to “inactive” - Automatically revert to previous partition on failure Update A User Space A Update B Kernel Initramfs A Now let’s handle the size of our builds. @jfrog | User Space B Copyright © 2019 JFrog. All Rights Reserved Kernel Initramfs B Bootloader

Slide 40

Slide 41

Yocto Overview - Eliminates OS bloat Drastically reduces resources required BitBake recipes and layers define your build Layers for common configurations are provided Custom layers to isolate applications or behaviors @jfrog | Copyright © 2019 JFrog. All Rights Reserved

Slide 42

Slide 43

Yocto and Artifactory - After first build, we can make things much faster Yocto cache allows for incremental updates Build cache can be stored in Artifactory Reduces time required to build by up to 50% @jfrog | Copyright © 2019 JFrog. All Rights Reserved

Slide 44

The Result - Firmware - Cuts the total time after first build to 5-10 minutes Build is as small as possible Updates are signed and secure Automatic rollbacks in case of failure Success! @jfrog | Copyright © 2019 JFrog. All Rights Reserved

Slide 45

Slide 46

Slide 47

OSTree - Versions updates of Linux operating systems Git-like system with branching Tracks file system trees Allows for updates and rollbacks Exists as a meta-layer for Yocto @jfrog | Copyright © 2019 JFrog. All Rights Reserved

Slide 48

Slide 49

LAVA - Linaro Automation and Validation Architecture CI system for deploying an OS to device for testing Can deploy to physical or virtual hardware Boot testing, bootloader testing, or system testing Results tracked over time @jfrog | Copyright © 2019 JFrog. All Rights Reserved

Slide 50

LAVA - Designed for validation during development For example, whether the kernel compiles and boots Templates for more than 100 boards built in Custom devices types can be added @jfrog | Copyright © 2019 JFrog. All Rights Reserved