top of page
Writer's pictureKnox Lively

Why I Joined Atym: Bringing DevOps to Embedded Development

 

Kismet 

Earlier this year, I found myself wandering the booths at the Open Source Summit North America (OSSNA) with my team at the time from Wave Terminal. We'd come with hopes of understanding more about what people need and want from a terminal emulator and how they use them. As fate would have it, Atym was there too, in a nearby room formally launching their product. 


OSSNA 2024


Though we'd never formally cross paths at the conference, I found myself pondering the exact question they'd come to answer: "Why hasn't embedded development substantially evolved in the past 20+ years?" There have been exciting (albeit modest) improvements in the hardware world—faster and cheaper MCUs, RISC-V taking off, and an ever-growing list of hobbyist boards. However, embedded firmware development was still largely done in C (or assembly if you're a badass), compiled by a brittle and fickle 30+-year-old toolchain, and flashed by even more confusing and fickle tools. And though there were more libraries, SDKs, and IDEs than ever, writing code and deploying for these platforms hasn't gotten much easier. 


By contrast, it's become nearly impossible to keep up with the burgeoning tools, methodologies, and paradigms for building, testing, and delivering software further up the stack and into the cloud. Overnight, containerization and microservice-based architecture became the norm, and if your infrastructure isn't written in code by now, then you're a dinosaur. 


Coming on Board 

A few months later, after these questions and quandaries subsided, I came across Atym's website. Though I found the tech and concepts familiar, it took me a second to unpack. There were words like containers, CI/CD, and cloud-native—all concepts that I was intimately familiar with as a former DevOps Engineer—paired with words I was familiar with as an electronics hobbyist like microcontrollers, embedded development, and edge devices. It seemed like the perfect intersection of my career and hobbies as Atym seemed to be trying to bring DevOps to embedded development, particularly for edge devices. 


I promptly applied, and though very hopeful, I was still delighted when Stephen, our CTO reached out to me for a chat. After a few discussions with him and our CEO Jason, I knew Atym would be an easy product to champion and was more than happy to accept the offer as the company’s lead Developer Relations engineer. 


Atym, A Roadmap for the Industry 

I come from a world where agile, continuous integration/continuous deployment (CI/CD), and cloud-based provisioning are the norm. We deploy often and aren't afraid to break things because our toolchain allows us to quickly iterate, learn from our failures, and fix them. This accelerates innovation.


Atym is bringing these principles to resource-constrained devices that don’t have enough memory to support technologies like Docker and Kubernetes and I couldn’t be more excited. Atym is an enterprise-class company, but also an incubator of ideas, practices, and standards. Atym is breaking the embedded mold and rewriting the software development and delivery model for resource-constrained edge devices that have as little as 1MB of memory.  


Once the Atym device runtime is flashed onto a board, the centralized Atym Hub opens up developers to a new world of possibilities. A world where they can write applications in the language of their choice (e.g. C, Rust, Golang), package them into secure and modular containers, and then easily deploy them to edge devices with cloud-like agility.


The Atym runtime has a footprint of just 256KB and a simple app container can be as small as 300 bytes. The upper limit of size and number of apps per target device is limited by the capability of the underlying hardware. While we make it possible to run cloud-native containers on microcontrollers (MCUs), even devices that can run Linux can benefit from our solution as an alternative to Docker in terms of freeing up 256+ MB of memory for applications. Generally speaking, our sweet spot is devices that have between 1MB and 1GB of memory.  


Ocre as an alternative to Docker for freeing up system memory

 

The Atym solution enables organizations to drastically shorten development cycles, attract talent outside the traditional embedded world, boost security, protect IP by sharing apps as containers instead of source code, and save memory compared to Docker alternatives. Moreover, these containers can be shared and re-used from and by 3rd parties, similar to Docker Hub, enabling developers to easily incorporate pre-built components into their solutions. 


Though we feel the industry has been slow to adapt and change, there's nothing "wrong" with the current development model. Some solutions will remain embedded – like an airbag controller. We just know that Atym can breathe new life and opportunities into devices that have been locked into traditional development models due to their constrained nature. Now, devices that can't support a traditional operating system like Linux can run containerized applications, just as a cloud server can—bringing the flexibility and power of modern software practices to the smallest and most resource-constrained of devices.  

 

Built on Open Standards 

Though Atym is an enterprise offering, the on-device Atym runtime is built entirely with open-source software that we collectively call Ocre. Ocre is the open-source version of the Atym Runtime and provides the core features needed for running containerized applications locally on embedded devices. Let's take a look under the hood and see the open-source technologies that power Ocre. 


At the base level, the Ocre runtime needs drivers and board support to run. While Ocre is technically RTOS agnostic, we chose to build the Ocre reference design on Zephyr due to Zephyr's comprehensive library and tool support, as well as its modularity, flexibility, and active developer community, to which we also contribute. This allows us to support hundreds of platforms out of the box. Not only does this ensure Ocre can run easily on multiple devices, but with just the addition of a couple of config files, Ocre can be up and running on new or custom hardware if an organization decides to swap chips or transition to a completely custom solution. 

 

Ocre device runtime architecture


Next, to run containers on resource-constrained devices we leveraged WebAssembly (particularly the WebAssembly Micro Runtime, or WAMR) for our virtualization layer as it’s incredibly lightweight and designed to be executed in a sandboxed environment. WebAssembly allows developers to write code in their preferred language, which we then compile into a WebAssembly binary, package it into a container image, and from there we’re able to build a container and then run that on the device in a secure and isolated environment. Another key advantage is that we don't prescribe a specific toolchain—developers are free to use their choice of language, compiler, or toolchain, as long as it can build WebAssembly binaries. 


Lastly, we have the actual Ocre runtime or the components that “glue” Zephyr and Wasm together that allow containerized applications to run locally on embedded devices.  

 

  • Runtime Manager: Oversees the overall execution of Wasm containers on target devices. 

  • Application Framework: Structured framework for supporting multi-container embedded applications. 

  • WASI Components: Implementations of WASI (WebAssembly System Interface) components tailored for embedded systems, ensuring seamless integration with core WASI functionality. 

 

All of these components together make up the Ocre runtime, which is now itself open source.


Earlier this year we donated the Ocre runtime codebase to the Linux Foundation to kickstart the Ocre project in LF Edge and collaborate with the broader open-source community. Ideally, this will help drive innovation, and formalize industry standards around Ocre containers, their format, and how they run on embedded devices.


Beyond the runtime source code, we're also making available the Ocre containerization format, which builds upon the established standards governed by the Open Container Initiative. This approach ensures compatibility and interoperability with containerization solutions and tooling in the broader software ecosystem — like how Docker standardized containers for cloud and server environments.  


Atym = Enterprise-Ready Ocre + Fleet Management at Scale

If Ocre provides all the essential components for running containerized applications on embedded devices, you might be asking, "So, what exactly is Atym?" Great question—let’s break it down. Atym consists of two main parts: the Atym Hub and the Atym Runtime

 

While the Ocre runtime works well for single deployments via manual command-line operations, the Atym Hub is designed to be the command center for managing and securing large fleets of devices running Atym. With features like a graphical interface, built-in CI/CD tools, a container registry, and much more, developers can write in their preferred languages and compile applications into native WASM code. Essentially, Atym Hub takes the power of Ocre and makes it scalable and manageable at an enterprise level. 

 


 Atym solution architecture

 

On the device side, the Atym Runtime is the commercially supported version of the Ocre runtime, working seamlessly with the Atym Hub. We will initially support the Ocre runtime as-is but plan to enhance its features and expand its functionality over time. Importantly, we will maintain compliance with the Ocre APIs, ensuring interoperability with the broader ecosystem, while the Atym Runtime will simply be “enterprise-ready” Ocre. 


In addition to scalability, Atym also offers premium features like streamlined device onboarding, FUOTA-based firmware updates, ahead of time (AoT) code compilation for optimized on-device performance, advanced security, and more. In short, Atym provides an enterprise-grade solution that simplifies the entire process of building, deploying, managing and securing containerized applications at scale, while Ocre is more suited for DIY users looking for individual deployments. 

 

The Future of Ocre 

I'll wear many hats in my role at Atym, but my priority is kickstarting the Ocre community and providing great content in the form of docs, blogs, and fun examples. I'll also be guiding organizations in their journey from Ocre to Atym as their needs grow, helping them leverage the full potential of our enterprise offering. However, the success of Ocre isn't just about my efforts – it's about building a vibrant, engaged community. 


As part of our commitment to open-source and the vendor-neutral governance provided by the Linux Foundation, we've established a Technical Steering Committee (TSC) for the Ocre project to shape the architecture and roadmap. This is where you come in: if you're interested in contributing to Ocre's future, I highly encourage you to check out the project calendar and join our meetings when you're able. To stay informed about all things Ocre, including upcoming meetings and developments, make sure to sign up for the mailing list


If you're as passionate about revolutionizing embedded development as we are, I encourage you to get involved with Ocre in any way you can, whether it be participating on the TSC, developing code, or building sample projects for various use cases. Whether you're a seasoned embedded developer or just starting out, your contributions can help directly shape the future of this groundbreaking technology. Check out the Ocre repository on GitHub to see how you can be part of this exciting journey! 

 

Comments


bottom of page