The Eclipse Foundation in collaboration with the OpenAtom Foundation today launched the Oniro project and working group to create an independent implementation of OpenHarmony, an open source operating system.
Created by the OpenAtom Foundation, the OpenHarmony operating system is based on a HarmonyOS originally created by Huawei. It is designed to support multiple kernels but uses the Linux kernel if a device has a large amount of memory.
It also includes a DSoftBus capability for integrating physically separate devices into a single logical super device that enables one device to control others in addition to facilitating data sharing among distributed devices.
Huawei, in collaboration with Linaro, Seco, Array, NOITechPark and Synesthesia, has also been contributing to a continuous integration/continuous delivery (CI/CD) platform that is part of the larger Oniro project.
Mike Milinkovich, executive director of the Eclipse Foundation, said the goal is to provide a common layer of abstraction platform that can be employed across a wide range of embedded systems that are typically being deployed at the network edge. That level of fragmentation surrounding platforms that don’t provide a lot of significant differentiated value only results in slowing down the deployment of applications, noted Milinkovich.
As part of that effort, a dedicated working group has been created to provide a vendor-neutral structure through which contributions to the project can be made with greater transparency. The OpenAtom Foundation was created in Beijing last year with the support of Alibaba, Baidu, Huawei, Inspur, Qihoo, Tencent and China Merchants Bank. The alliance with the Eclipse Foundation brings more traditional governance rules for building open source software to the OpenHarmony project.
In general, DevOps teams should be tracking the development of proposed de facto standards for edge computing platforms closely. More applications are now being deployed on edge computing platforms that make it possible to process and analyze data at the point where it is being created and consumed. The DevOps challenges associated with building and deploying applications across a highly distributed computing environment are considerable.
In many cases, organizations that never really attempted or mastered continuous delivery of applications and their associated updates will be sorely challenged when it comes times to support hundreds, possibly thousands of applications, running on embedded systems based on a wide range of processors.
In addition, many of those same DevOps teams will start to see traditional batch-oriented applications being superseded by applications based on event-driven architectures that process data in near-real-time. In most cases, those applications are going to be built on microservices-based applications that are typically more challenging to build and deploy than a traditional monolithic application.
Arguably, IT organizations are on the cusp of a new era of IT that assumes most organizations have not only mastered DevOps best practices but are now also embracing DevSecOps best practices to secure those application environments.
It may be a while before the open source software that will be developed by the Orino project finds its way into production environments, but it should be apparent that reducing complexity at the network edge should be a high priority for all DevOps teams heading into 2022.