In 1984, John Gage from Sun Microsystems coined the phrase "The Network is the Computer". In making the statement, he was putting a stake into the ground that computers should be networked otherwise they are not utilizing their full potential. Ever since then, people have been connecting their servers, desktops and small devices to the network to provide connectivity and compute to a variety of locations for varying business purposes.
Take, for example, when I worked at BAE Systems back in the 2008-2010 period. We already had remote unmanned sites where we had compute that was ingesting data from tests and sensors. Further, we had to ensure that data was kept integral for compliance and business reasons. Developing an architecture around this to ensure reliable operation and resiliency was no small feat. It involved the integration solution of multiple products to ensure the systems were monitored, the data was stored locally, backed up, deduplicated and then transferred offsite via the network for a remote stored copy. No small feat given some of these sites only had a T1 for connectivity. However, it was a feat we were able to accomplish and did it all without using the ever popular "edge" marketing moniker.
Fast forward today and all the rage is on edge, edge workloads and edge management. As a marketing tool, the use of the word "edge" has become synonymous with making decisions closer to where a business needs them made. But I was already doing that back in 2008-2010 at BAE Systems.
The story marketing departments and product owners are missing is that, in order for me to do what I did back then, it took a highly technical resource to architect and build out the solution. In today's world, many businesses do not have the luxury of those skilled resources to take the building blocks to build such systems. These businesses, in various industries, are looking for turnkey solutions that will allow them to achieve what I did years ago in a quick and cost efficient manner while leveraging potentially non-technical staff. However, the integration of what I did into a turnkey product that is universally palatable across differing industries and customers seems daunting.
Businesses vary in how they define edge and what they are doing at the edge. Take, for example, connectivity. In some edge use cases like my BAE Systems story or even retail, connectivity is usually fairly consistent and always there. However, for some edge use cases like mining where vehicles might have the edge systems onboard, the connectivity could be intermittent or be dynamic in that the ip address of the device might change during the course of operation. This makes the old push model method and telemetry data gathering more difficult because the once known ip address could have changed and yet the central collector system back in the datacenter has no idea about the devices new ip address identity. Edge, in this case, requires a different mindset when approaching the problem. Instead of using a push or pull model, a better solution would be leveraging a message broker architecture like the one below.
In the architecture above, I leverage an agent on our edge device that subscribes and publishes to a MQTT broker and on the server side I do the same. That way, neither side needs to be aware of the other end's network topology, which is ideal when the edge devices might be roaming and changing. This also gives us the ability to scale the MQTT broker via a content delivery network so we can take it globally. Not to mention, the use of a message broker also provides a bonus of being able to allow the business to subscribe to it, enabling further data manipulation and enhancing business logic flexibility.
Besides rethinking the current technological challenges at the edge, we also have to rethink the user experience. The user experience needs to be easy to instantiate and consume. In the architecture above, I provided both a UI and an API. This provides the user with both an initial UI experience to help them understand how the product operates but also an easy way to do everyday tasks. Again, this is needed because not everyone using the product will have technical abilities, so it has to be easy and consumable. The video below shows a demonstration of how to do an upgrade of a device from the UI. The UI will use the message broker architecture to make the upgrade happen on a device. In the demo, I also show on the bottom left a terminal screen of what is happening on the device as the upgrade is rolling out. I also provide a console view of the device on the lower right so we can view when the device is rebooted.
After watching the demo, it becomes apparent that the ease of use and simple requests is a must for our non-technical consumers at the edge. Also, as I mentioned above, I do have an API, so one could write automation against this if the business has those resources available. The bottom line, though, is that it has to be easy and intuitive.
Summarizing what we just covered, let's recognize edge is not a new concept in the computing world. It has existed since the time computers were able to be networked together. Edge in itself is a difficult term to define given the variances of how different industries and the businesses within them consume edge. However, what should be apparent is the need to simplify and streamline how edge solutions are designed given that many edge scenarios involve the use of non-technical staff. If a technology vendor can solve this challenge either on their own or with a few partners, then they will own the market.
