EdgeX Foundry is still a few months away from its one-year anniversary. For those unfamiliar, EdgeX Foundry is a vendor-neutral, open source IoT edge computing framework project under The Linux Foundation. At the heart of EdgeX is a microservice architecture which allows the platform to be distributed, updated, replaced, improved and even provided by commercial third parties for additional value add where it makes sense. Its goal is to provide an interoperable platform (hardware and OS agnostic) to accelerate the deployment of industrial IoT solutions.
Even before the project’s first birthday, there is plenty to celebrate.
Although EdgeX is less than a year old, we did get a jump-start on the project. Dell had been working on a proof-of-concept platform called Project Fuse that we contributed to The Linux Foundation to seed EdgeX Foundry. While this effort helped boost the EdgeX launch, there are some challenges in taking a proof-of-concept project and turning it into a platform ready for industrial use. As the architect and lead developer on Project Fuse, I can tell you that what was important to our proof-of-concept effort was demonstrating the architecture and trying to get the general design and API set correct. When starting Project Fuse, Java offered the means to quickly prototype a cross-platform framework with plenty of libraries available to help connect many of today’s Industrial Internet of Things (IIoT) devices and sensors. Forefront in our thoughts, however, was not creating the most performant or efficient platform.
This was a fact that the community identified as a primary need in one of our first face-to-face meetings this past summer. Java was flexible and platform independent, but when looking at the edge requirements, it was evident that the platform needed to get faster and it needed to get smaller.
Looking back on my notes just before EdgeX’s launch in April of 2017, I had collected statistics on the size of the EdgeX microservice containers and use of memory (RAM). The table below has a sampling.
As a community, in our July 2017 technical steering committee face-to-face meeting in London, we resolved to moving the microservice code base from Java to Go. At the time of our Barcelona release in October, the EdgeX community made announcements regarding our commitment to reducing the original footprint, startup times and overall performance by making a move from Java to Go. We had even done some early prototyping in Go with one service to show that our migration had promise.
The community worked hard to prove the diet plan was working and this past month, only 3 months from our first release, the EdgeX community made available what we are calling the “California Preview.” This preview is a collection of five key microservices written in Go that are drop in replacements for our Java microservices. The work on the California release (again not due until June) still continues, but we wanted to show the world that EdgeX was indeed going to be fast, small and still a flexible platform for building IIoT solutions – thus we named this a “preview” of what we hope to show in full by the California release.
In the preview, the core services (Core Data, Metadata, and Command) have been recreated in Go Lang, as well as the bulk of the Export Client and Export Distribution microservices. Just how fast and how small has EdgeX gotten? Let’s take a look at some of the new EdgeX measurements.
I’ll let these numbers speak for themselves. As you can hopefully see for yourself, the EdgeX community is getting ready to release an IIoT platform that is going to meet the community’s expectations with regard to performance. If all the numbers are a bit much, let me give you a simple visual comparing the Java versus Go microservices to that you have an appreciation of the direction of EdgeX memory usage and startup times.
The microservice architecture proved its value as part of this Java-to-Go evolution. When designing the platform, we knew that pieces of the platform were going to be updated and evolve over time. We also knew that in order to support industry advances, we had to expect the underlying technology used to deliver a microservice to evolve over time. The history of software is one of always emerging new programming languages, approaches, technology, etc. We could not expect that the platform was always going to be Java, or C, or any technology for that matter. Within a few short months of its existence, our theory on that evolution was tested and validated with the move from Java microservices to Go microservices.
The microservice architecture allowed various teams to replace the Java microservices without impacting any other part of the platform. It even allowed other community members to provide additions and fixes as the Go microservices were being developed. It was kind of like watching your local automobile repairman replacing significant elements of your engine while traveling down the interstate highway to your next destination.
As EdgeX evolves, we believe the next phase of this architectural approach will show itself again as community members are starting think about and develop commercial microservice replacements where they add value and solve the needs of particular use cases/verticals.
If we take the first 5 EdgeX Go replacement microservices and extrapolate the same savings to all of the EdgeX microservices, the forecast size and performance of EdgeX looks very good.
In addition to the smaller, faster EdgeX, our California release is also hoping to include some key additions and improvements.
Indeed, the future of EdgeX is bright. The platform is getting smaller and the community around it is getting bigger…all before we’ve even lit the candle on the first birthday cake.
Jim White is an EdgeX Foundry TSC Member and Chair of Core Services Working Group. He is also Distinguished Engineer and Project Lead of the IoT Platform Development Team within Dell Technologies IoT Solutions Division.