Written by Dell’s Jim White, EdgeX Foundry TSC Member and Chair of Core Services Working Group
In a post I made to this blog back in October, I reported that the EdgeX community was committed to reducing the original footprint, startup times and overall performance by making a move from Java to Go. The community has been hard at work, and I am happy to report on the initial success of that effort.
California Preview
Today, we announced the availability of what we have deemed the “California Preview” that is available for exploration from the EdgeX sites.
The California Preview is a sample of what we hope to bring you in full this spring. In the California Preview, the community has built several Go Lang micro services that are drop in replacements for the Java versions. Specifically, the core services (Core Data, Metadata, and Command) have been re-created in Go Lang. Additionally, a portion of the export services functionality found in the original Java Export Client and Export Distribution micro services have also been re-created in Go Lang. Finally, the Core Config Seed, which is the initialization service that sets up the configuration/registry service, is now done in Go Lang. Consul is our configuration/registry service and that has always been written in Go.
Team Effort
This has been a community effort with the Dell team providing the core Go services, Cavium and Mainflux teams providing the export services, and Samsung producing the new config seed. The Linux Foundation led DevOps team is busy working a continuous integration process for our new Go micro services –even cross compiling for Intel and Arm platforms. Last but not least, the blackbox testing provided by the IOTech team is making sure the replacement services are REST API compatible with the Java services and therefore are drop-in ready. This is how open source gets done today – many companies and teams working together towards one dream. Group hug.
Go Lang Results
Now, back to the results and benefits of all this hard work. Because Go is compiled into an executable, the size of the application is much smaller than it’s Java counterpart – even before considering the JVM required for Java applications. Here’s a look at the raw Java JAR versus Go executable size for the EdgeX core micro services. The size of these same services in a Docker container is also indicated on the right side of the chart. The Java container image size does includes the Java JVM – thus the even larger footprint when looking at Java versus Go containers.
All well and good, you might say, but what about the micro services’ use of critical resources such as memory or CPU? Go Lang micro services used an astounding 97% less memory and generally 5 to 40 times less CPU!
Lastly, the startup time for the Go services nears 100% improvement. We typically had to measure our Java micro service start times in seconds. We measure our Go Lang micro services starts in milliseconds.
I have been doing Java most of my programming career. Love Java, but in order to get EdgeX to the real edge of IoT environments, we have to put our micro services on a diet – make them small and fast. Go Lang is helping us get EdgeX svelte.
Still Hurdles to Clear
Go is still a young programming language relative to Java. Version 1.0 of Go was released by Google in 2012 whereas Java has been around for more than 20 years now. The libraries, tools, frameworks, and idioms are still emerging in Go while Java has a plethora of these. Our developer community, in some cases, is also learning that the Java-way is not necessarily the Go-way, and therefore is having to adapt to a new programming paradigm. For example, the multiple repo approach for the Java micro services and associated share libraries doesn’t work so well in a Go Lang development environment where a single “mono” repo is preferred. Some of our Go code will likely have to go through a refactoring exercise as lessons are learned. That’s to be expected as even the Java micro services were refactored once or twice since being created.
The Go work is progressing but we are not done. We need to make similar reductions to the rest of our micro service collection. Not all the work will be done in Go Lang. For example, we are hopeful to have a C/C++ Device Service SDK (along with a Go Lang Device Service SDK) this spring which will allow for small C/C++ micro services for some protocols/platforms at the EdgeX southern layer. In some cases, especially for the some of the services that are more application focused and could live in bigger environments when EdgeX is distributed, Java micro services may still flourish.
However, if we are able to make similar reductions to all of our EdgeX micro services (whether using Go, C/C++, or other language), the forecast for EdgeX size and performance is quite good. Early forecast calculations put the total memory usage (database and other infrastructure inclusive) at less than 200MB. That compares to a 2.5GB of memory needed today. The total containerized footprint would be around 600MB (compared to more than 1.8GB today). And EdgeX would start up in about 5 seconds (compared to around 5 minutes today). The concentric circle relative size diagrams for some of these metrics provide a visually compelling story that should help you soak in the differences.
Help Needed
Come help us complete this work. Help us make EdgeX go (pun intended) smaller and faster! In addition to the work to complete the EdgeX micro service reductions, there $is crucial work in security and system management that is to be completed for the California release. As I already indicated, we need help completing SDKs in various programming environments. More north and south bound connections, more testing, and more deployment / orchestration work needs to happen. We welcome companies and individuals looking to make a contribution in the IoT landscape.
If you have questions or comments, visit the EdgeX Rochet.Chat and share your thoughts in the #community channel.
