Jim White | 28 February 2018
Learn more about the “California Preview,” due out in June, which provides a collection of five key microservices written in Go.
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.
- The first community release (code named ‘Barcelona’) last October.
- A community of participating companies and organizations that started at 50+ and is now over 70+.
- An announced alliance and liaison with the Industrial Internet Consortium to collaborate on test beds and best practices.
- A bi-annual cadence producing technical roadmaps and releases to focus the community and deliver on the goals of the project – with the next release (code named ‘California’) scheduled for June.
From Fuse to EdgeX – The Evolution of the Platform
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.
In addition, the startup time for each microservice was measured in minutes (vs. seconds). For an edge platform, it was clear this wasn’t going to do the job. As the technical “father” of EdgeX, I had to admit “my baby” had a weight issue.
California Preview
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.
The New Slimmer EdgeX
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.
Go is compiled into an executable and does not require the virtual machine which Java requires. Plus, in Java, we took advantage of many frameworks like Spring to build our initial proof-of-concept platform. This helped us get something up quickly, but in a framework, there are a lot of features that you don’t end up using causing bloat of the overall program artifact.
What this table does not depict is also the reduction in the spikes of memory usage that is smaller in Go. The necessary Java garbage collection causes larger spikes in memory usage.
CPU usage is estimated as there can be wide swings in usage based on what is happening in each service and on the hardware itself. These numbers are based on averages observed while running the virtual device service. Again, the Java microservices often spike much higher (sometimes up into the 75% range), which is not depicted here.
Without the JVM, Spring Bean instantiation, etc., the Go executable leaves no question that our EdgeX startup time will eventually be measured in sub-seconds and not minutes.
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.
And, if your use case requires more real-time performance, there are members of our community like IoTech that are building real time extensions of EdgeX.
The Power of Microservices Architecture
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.
The Forecast and Future
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.
If this forecast is even close, then all of EdgeX will be smaller and faster than one of the original microservices just a year ago! This list depicts just a few key metrics and we still have work to do to complete this transition by our California release. Also, there are some additional infrastructure (MongoDB and Consul) and microservices (Scheduling) that are not included in the totals. Still, the forecast looks bright.
In addition to the smaller, faster EdgeX, our California release is also hoping to include some key additions and improvements.
- Initial security services/capability to include a reverse proxy API manager, authentication/authorization services, and data protection services.
- An initial system management API offered in all the microservices along with managing agent.
- Delivery of EdgeX Foundry containers for ARM platforms (natively tested on ARM hardware)
- Improved and overhauled documentation set; moving developer documentation from Wiki to GitHub so that it is updated/maintained/reviewed like code is (through formal pull requests, etc.).
- Device Service SDKs in Go Lang and C/C++
- Blackbox tests for the entire EdgeX API set
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.