Technology is constantly changing and evolving. If some pieces of equipment aren’t updated or replaced in a timely manner — they can quickly become outdated, turning them into legacy systems. Such legacy systems are still fully functioning but, due to their age and lack of modern capabilities, sometimes cannot cope with the demands of new business initiatives.
I have a toy car extension board for my Raspberry Pi. While tinkering around with that Raspberry Pi car, I stumbled across the prebuilt remote control functionality. Initially, that sounded great — but the car would only accept commands via low-level network sockets. This hindered my ability to create slick and easy extensions of the car’s capability with my own ideas. The legacy technology in the car limited my ability to innovate — much like enterprise legacy systems does for business.
So let me show you how that technical challenge in my Raspberry Pi car can be directly related to manufacturing, as well as other industries, and how to solve that challenge with MuleSoft.
Legacy hardware in manufacturing
Many manufacturing companies made significant investments to large machines — and it was likely many, many years ago when they purchased these machines. While they may still be operational, the technology inside them might be outdated or insufficient. These legacy technologies often can’t be easily integrated into existing IT landscapes — yet limitations in IT resources and capabilities require more simplicity.
Integrating manufacturing machines into the IT infrastructure may be required for some use cases. Some of those use cases might even be considered experimental and the financial gain of their implementation might be uncertain. If the development investment required for such use cases is high, then prioritization of these developments will be low because there is always some kind of more pressing matter that central IT should pursue instead.
Legacy modernization with a toy car
So what can be done about this kind of legacy hardware or software? Taking my Raspberry Pi car as my legacy system, I used an out-of-the-box functionality to create an integration and API that modernized my Raspberry Pi car. This is typically referred to as “legacy modernization.”
What needed to be updated was how communication was being handled. Communication was happening via low-level network sockets. Network sockets by themselves should not be considered legacy, since most modern protocols use them to create high-level communication protocols and interfaces.
However, using low-level communication instead of using high-level communication protocols is considered ‘legacy.’ One could compare it to using pure fire to cook your meat instead of using a sophisticated charcoal grill. Fire is the basis for both, but this may be inefficient and yields unpredictable results.
So, to get rid of those ‘unpredictable results’ and modernize the Raspberry Pi car, the idea was to create a modern API. I did this using MuleSoft as the broker between the low-level network socket connection of the Raspberry Pi car and other consumers that want to send commands to the car via REST. As an added benefit, I added security and governance policies to the interface effectively, securing the car.
How it works
The issue
So what did I do? The hardware used was a Raspberry Pi 3 and the “Freenove 4WD Smart Car Kit for Raspberry Pi.” The car kit comes with an implementation for the server running on the Raspberry Pi, and the client running on any other computer that wants to remotely control the car. Both implementations are implemented in Python. The client was limited in its capabilities. The client implementation came with a graphical user interface (GUI) and can only send single commands. This is done using buttons in the GUI and some keyboard shortcuts that were bound to some of the buttons.
Probable solutions
I wanted to programmatically control the car via REST. For that I started to investigate the communication interface of the client. It turned out that commands were simple strings sent via network sockets without any encryption or authentication. Ultimately, I had three options to have a remotely controlled car using REST interfaces.
- I could buy a new Raspberry Pi extension board with wheels that already delivers the required code that exposes REST APIs.
- I could refactor and rebuild the whole server side Python code to expose APIs.
- I could use something to encapsulate the existing interface and let that expose the required REST interface. This is also known as the strangler pattern.
Why this is legacy modernization
So let me bring the three possible solutions into relation to the legacy manufacturing systems:
- This would basically mean you buy new machinery.
- This would mean reimplementing the software of the legacy machines.
- This would mean using a middleware implementing the strangler pattern effectively modernizing the old hardware.
The solution
The most obvious choice was choice number three, and I used a standalone Mule runtime on the Raspberry Pi as the middleware to implement the strangler pattern.
As part of the implementation of the interface I created a couple of REST endpoints that represented the original commands that were already there and one special new endpoint. The new special endpoint received multiple commands at once and executed those commands one after another.
The original interface couldn’t handle this kind of chained command execution out of the box. Previously, it would require the client to do multiple calls to the “old” interface to execute multiple commands. Implementing this was quick and easy and enabled me to use REST calls to remotely steer the car with any application capable of sending REST requests.
Since I now have a Mule application that translates REST calls into network socket commands, I can use the API management component of MuleSoft to add a security policy like client ID enforcement to effectively remove every unauthorized access to that interface. This is done with a couple of clicks and a small configuration.
Conclusion
I quickly implemented a modern communication interface with minimal effort. This basically unlocked my legacy hardware for new initiatives. This was done using a low cost alternative to labor or investment intensive modernization approaches, such as buying new hardware or refactoring and reimplementing software of the legacy hardware.
To learn more about legacy modernization download this whitepaper.
