The complexity of the Edge
There is a lot of literature about the edge, its benefits and the new services that is going to provide and even more when we mix it with 5G capabilities. But to create an Edge ecosystem where we can handle the correct execution of these new edge capabilities is not so simple. Let me explain my point of view.
Edge is related mainly to two concepts: latency to act and throughput of information. Let’s first start describing why we need edge. We are used to act to certain context of information in a really high speed without thinking about it. If we are driving a car and we detect danger we hit the brakes, if we see someone on the street that we want to talk to, we try to get their attention, etc. We have already patterns in our brain, already trained, that we use to react to certain situations or context of information. To translate this to computers capabilities we need to have some analytic algorithms (let’s call it applications) that are capable to retrieve information from the environment, understand the information, correlate relevant data, generate a conclusion and act based on the different possible actions related to a conclusion. Taken this analysis to the two examples I described before, all of this must be that really fast, otherwise the brakes of the car will be pushed too late to stop the car or we will miss the person that we want to talk to. Another important topic is that most of the information we analyse are images, and not even images but a sequence of images or video where changes are happening. So, we end up in an environment where we have to react quickly to something that is happening on real-time and we have a huge amount of information to analyse. This take us to the two concepts we have started this analysis with, latency and throughput.
Using the cloud to build these analytic solutions, latency increases by the distance between the place were information is generated to the public cloud and also the same distance to send back the action to execute. It is a matter of testing each of the use cases if the latency cost of going to the public cloud is valid or not. Throughput is another issue, since in order to have a real-time system that needs to react to what is happing in a specific context, we will have to send the cloud the stream of video of one or more cameras and others source of information coming from other sensors. Again, it is a matter of testing each use case to know if the throughput needed is valid in terms of capacity of the network and its cost to use the public cloud. If both constrains are valid and we have a scenario where our use case could be resolved with the public cloud, forget about the Edge. It is going to be much simpler, cleaner and easier to manage a solution using the public cloud than to generate an Edge architecture for getting the same results.
The problem comes when we do not meet the requirement of latency or throughput. In this case what we need to do is to close the distance between the source of information and the application. We achieve that putting our process capacity closer to the data. In other words, expanding our cloud and putting points of presence or smaller data centers closer enough to the data to avoid higher latency and to permit high throughput.
Our next issue is related to the issue of having a distributed cloud. We have to spread our applications to all points of presence (PoP) in the edge where we want to cove a certain use case. A management solution for the edge is needed here. To this scenario we have to add that most of the time the applications used are generated in background by engineers of data that know how to program them. The management solution that we mention before has to be capable of retrieving the applications and send them to the Edge PoPs where are needed. It could be not all PoPs but just a subset of them. The specifications of each PoP could be the same at the beginning but probably as time pass the hardware in each PoP might be different and the requirements to execute a new application could not make it work in an old PoP. This end up in a heterogeneous environment where we not only need a management solution for the Edge but a solution that is also capable of managing all PoPs based on deployment policies that cover all the combinations that a PoP/Application can have.
With the improvement of IoT solution we can have devices that are capable of executing small applications. So, we can add to our application distribution management all devices, as PoPs, where we can run an application. This scales the number of PoPs from a few thousand at most, to millions or even billions of possible PoPs. There is no way to coordinate all this deployments and need of management manually. We need an automatic solution that is capable of reading the policies we set and execute a continuous deployment in an autonomous way.
Another important topic is that all we have described must work as a single solution in order to scale and to have a simpler environment to manage. As owners of the edge, we are the builders of all applications. but most of the time that is not the case, we normally end up with an ecosystem where we can have multiple providers and multiple consumer of those applications that are capable of covering different use cases for the edge. Our management and deployment solution must coordinate the relation between providers and consumer of applications.
Even it is not mandatory but highly recommended that our management solution is not centralised. That will make it a single point of failure and a security risk for the whole environment in case that the management solution security is compromised. We need to have a distributed management solution that coordinates providers and consumers of edge applications.
Ignacio Perez Gonzalez
