In Part 1, we discussed the challenges of building, deploying and managing highly distributed systems at the edge or otherwise. As the world becomes more aware of the importance of sustainability, edge solutions need to consider that as well. The key to sustainable solutions is automated management, which is collecting and analyzing the correct data. While this sounds easy, in reality, it is not without intentional system design. Organically growing and evolving systems, such as a telecom backbone infrastructure, still have far too many pieces that require human interaction, because, surprisingly enough, computers are not good at troubleshooting complex systems.
The maintenance and management challenges grow exponentially applied to massively distributed systems and their components, i.e., the edge. For instance, it is nearly impossible to keep the hardware at every site in sync with the latest hardware resources, which has the knock-on effect of not being able to deploy uniform software components. Further, as with any complex system, it is not uncommon for different components to be supplied by multiple vendors, who have their own management and orchestration tools. This variation causes further integration headaches. Some software components get released frequently, while others do not.
Testing also deserves its own focus (or book). Without careful design, the overhead of testing and verification often prevents the deployment of the latest versions, because the management system is not designed for non-production use cases. Since the only reliable assumption to make these days is that a newly delivered component will likely be buggy, testing needs to happen throughout every phase of a software or hardware component’s lifecycle! The company or organization operating the infrastructure, must be prepared to act as the integrator and own the validation of all the pieces, which can affect the efficiency of the overall pipeline significantly.
There are ongoing efforts in the open source software (OSS) ecosystem to address this challenge. For example, many communities are working on conformance testing frameworks and test suites. These programs can help with reducing the amount of testing that’s needed on the integrator’s side, or provide them with the test suites they need, while also helping with increasing interoperability and reducing vendor lock-in. Sadly, these OSS programs are often challenged in achieving their objectives when it comes to vendor integration.he industry test suites
Meanwhile, Europe is building a multi-provider cloud-edge continuum with an EU-wide marketplace running on different Internet Service Provider (ISP) networks. While this is an ambitious goal, having open standards and APIs is an industry-wide desire. It is also critical to success, which this effort is targeting as well with the silent hope of reducing vendor lock-in at the end. If everything goes as planned, the federation layer will be open source.
Finally, we would be remiss to overlook the hardware and sustainability challenges. For instance, acceleration is important in resource-constrained edge systems, but should it be implemented in hardware, software or both? While the answer always depends on the workload, the development work feeds into the integration challenge, and with the dominance of heterogeneous systems the result often ends up being both. At the same time, it is often the case that some components are running old chip versions or purpose-built boxes. This makes it challenging to deploy new software components, especially when they are provided by a different vendor, with different tools and architectures.
With the latest technology evolutions and the massive wave of digitalization, we are dependent on not just large energy-efficient data centers, but also all sorts of increasingly power-hungry personal devices. This requires the ability to efficiently monitor the system and carry out both reactive actions and proactive measures to plan for energy consumption, for instance, spread the charging of the electric cars throughout the grid. Efforts to design and develop more efficient infrastructure solutions and more energy-aware applications are not enough, we need solutions today, or rather yesterday to manage the peak demands on the power grid.
If you are curious about what was discussed during our PTG session, you can find the recording on the OpenInfra Edge Computing Group wiki. If you have an edge orchestration story or challenge to share and discuss, we want to hear it, join our conversations on our weekly calls or mailing list!
About OpenInfra Edge Computing Group:
The Edge Computing Group is a working group comprised of architects and engineers across large enterprises, telecoms and technology vendors working to define and advance edge cloud computing. The focus is on open infrastructure technologies, not exclusive to OpenStack.
Get Involved and Join Our Discussions: