Platforms that serve to expedite the interaction and collaboration of apps in the Internet of Things (IoT) are sort of the next new thing. There are several that some of the IT analyst firms are following. Trouble is the term allows for a wide variety.
One I’ve written about several times here and here and here is open source developed under the auspices of the Linux Foundation with major leadership and contributions by Dell Technologies. It’s called the EdgeX Foundry. The initiative includes 47 member companies.
The second major release of the platform (California) has just seen the light of day. I picked up information from a blog post by Jim White, Vice Chair of the Technical Steering Committee and Distinguished Engineer and Project Lead of the IoT Platform Development Team within Dell Technologies IoT Solutions Division.
Following is a lightly edited version of his blog concerning the announcement.
While EdgeX is only a year old, our community is demonstrating its staying power with the second major release in its first year. The California release, which follows Barcelona, shows the commitment and dedication of many who see the importance and potential of developing a flexible, open source, IoT software platform for the edge that provides connectivity and interoperability while still allowing value add.
So, what is new with the California release? A lot! But before we get into the details, I want to highlight that the biggest focus of this release was to introduce a few key security capabilities and to make EdgeX smaller and faster.
EdgeX began its existence without security and organizations wanting to leverage the platform had to add their own security capability. Today, EdgeX incorporates some of the first security elements. These initial elements, while useful on their own, are essential building blocks to additional security features in the future.
The first security elements include a reverse proxy that helps protect the REST API communications and a secrets store. With the EdgeX reverse proxy in place – as provided by incorporating an open source product called Kong – any external client of an EdgeX micro service must first authenticate themselves before successfully calling on an EdgeX API.
The secure storage facility was provided by incorporating the open source Vault (Hashicorp) product, and it allows items such as username/password credentials, certificates, secure tokens, etc. to be persisted and protected within EdgeX. These types of “secrets” will allow EdgeX to, for example, encrypt data, make HTTPS calls to the enterprise, or connect EdgeX to a cloud provider in a secure manner.
Performance and Scalability
The EdgeX Foundry Technical Steering Committee decided early last year in the project’s formation that we would release twice a year – once in April and once in October. You probably noticed that it’s not April.
Last year, we decided that EdgeX needed to be smaller and faster to better function effectively at “the edge”, which the largely-Java code from the seed donation was going to make difficult. To do this, we needed to rebuild the EdgeX microservices in Go Lang – and do so by our spring 2018 release. This was not a small endeavor and it was made at a time when the EdgeX Foundry developer community was just coming on board. We knew it would take a bit more time, but we were committed to this, and added two more months to this release cycle.
The extra time was well worth it! With the California release, we’ve dramatically lowered the footprint, startup time, memory and CPU usage. Take a look at the statistics below, which compares services from our first community release last October (Barcelona) to our current release (California).
We still have work to do, but it’s now possible to run all of EdgeX on something like a Raspberry Pi 3.
In addition to the initial security capabilities and reducing the size and latency of the platform, this release includes other work – some visible to the user while some features are more hidden but improve the overall quality of EdgeX.
• Several additions were made to the export services to provide additional “northbound” connectivity, to include connectors for XMPP, ThingsBoard IoT, and Brightics IoT
• We improved the documentation and now have documentation stored with the code in Github – allowing it to be maintained and updated more like code by the community
• Arm 64 is now fully supported. In fact we worked with the Linux Foundation to add external environments and tools to create native Arm 64 artifacts.
• We added blackbox tests for all the micro services. These are now kicked off as part of our build and continuous integration processes.
• Other improvements were made to our continuous integration – to help streamline developer contributions
On to Delhi
Our next release, named Delhi, will come out in October 2018. Due to the extended release cycle for California, the Delhi release cycle is going to be short. The significant features planned for Delhi include:
• Initial manageability services and capability
• Device Service SDKs (Go/C) and at least one example device service
• The next wave of security features to include access control lists to grant access to appropriate services and improved security service bootstrapping
• Better/more unit testing and added performance testing
• Adding the last of the refactored and improved Go Lang microservices
• Outlining options and a potential implementation plan for alternate or additional database support
• An EdgeX UI suitable for demos and smaller installations