Since the Red Hat Enterprise Linux Server for ARM Development Preview 7.3 became available I’ve been wanting to try it out to see how the existing code for x86_64 systems works on the 64-bit ARM architecture (a.k.a. aarch64).
Going in, I was a bit apprehensive that some kind of heavy lifting would be needed to get things working on the ARM platform. My experience with cross-architecture ports with other distros (before I joined Red Hat) indicated
going through dependency hell as I frantically tried to find equivalent packages for the ARM architecture. Needless to say, most of these porting exercises ended with massive amounts of productivity loss and potential security exposures as I downloaded packages from unknown sources, all the time hoping one of them would work.
For the cross-architecture porting exercise with Red Hat Enterprise Linux, I chose the Virtual IoT Gateway Lab as the test case. This lab builds an Intelligent IoT Gateway, a key component of enterprise Internet of Things (IoT) as it enables real-time decision-making at the edge, secures downstream devices and optimizes network utilization.
The other reason I chose this lab was because it uses Red Hat Fuse, A-MQ and BRMS - standard tooling for any enterprise Java developer. This lab is also fairly easy to set up and comes with scripts that build the needed services from source.
For hardware, I picked the APM Mustang system (X-Gene™ Server, 64-bit ARMv8-A compliant implementation) that packs sufficient computing punch in a low power budget. The Mustang has a nice form-factor that doesn’t take up too much space on my desk, though the fan is a bit loud for my taste.
Everything Just Works
Once the Red Hat Enterprise Linux Server for ARM Developer Preview was installed on the Mustang, I enabled the subscription and added the repo rhel-7-for-arm-optional-rpms to enable the access to the ARM architecture packages. From there on, I simply followed the steps for the lab as I would for any x86 system. Everything just worked. The Gateway was up and running with the sensor application sending data to the Gateway that routed it per the business rules. Logging into the Fuse admin console, I could see the messages flowing to expected destinations (see below).
How the Gateway lab Works
In this lab, we build and deploy the routing and business rules services on Red Hat Fuse. The sensor application sends temperature data using MQTT to the Red Hat JBoss A-MQ broker. These messages will be forwarded to the services that we started earlier. The business rules trigger the desired action when the sensor value reaches a threshold.
You can download the lab here: https://github.com/ishuverma/Virtual_IoT_Gateway
This little exercise made me appreciate the often un-touted benefit of using Red Hat Enterprise Linux: everything worked out of the box. This is only possible because it uses a common userspace and core packages for both architectures instead of creating a custom distribution for each architecture.
For me, it was an ease of use that saved me a trip to dependency hell. But for an enterprise, this could have huge implications. By choosing Red Hat Enterprise Linux, one gets a standardized environment that stays consistent across architectures, from IoT devices to data center. Having access to packages that are provided through a Red Hat supported repo significantly improves developer productivity (not having to hunt for packages) and eliminates security risks of installing these packages from unknown sources.
ARM architecture’s near dominance in mobile and IoT segments can also be translated to enterprise-grade systems, datacenters and cloud. Although, not many ARM servers are currently available in the market, several silicon vendors like Cavium and Qualcomm are working on delivering compelling server-class products to the market. Standardizing on Red Hat Enterprise Linux in your environment future-proofs your infrastructure investments as it allows Java applications to easily run across multiple architectures (x86_64, ARM, IBM Power, etc.). Applications written in other languages will likely require recompiling code for a given architecture, but likely Red Hat Enterprise Linux provides the same set of tools across all architectures delivering a consistent developer experience.