The next Project Teams Gathering (PTG) event is approaching quickly. We are all looking forward to see contributors and technology enthusiasts gathering together online on October 18 – 22, 2021 to discuss how to take open infrastructure projects to the next level. But you can’t talk about infrastructure without debating about edge computing! This is why the OpenInfra Edge Computing Group is meeting on three consecutive days to turn conundrums into solutions.
Since there is so much to cover, here we will give an overview of the sessions to help you navigate through our agenda.
Monday, October 18, 2021 (1400 UTC – 1600 UTC)
We will start the week with a session on a key topic: Portable Automation – What is needed to create automation that works “universally” across a diverse hardware and software distributed system?
We know that automation and orchestration are hard. Without automated lifecycle management tools, the Edge becomes that much harder to manage. In this session, we will get down to brass tacks to figure out what is needed to make it actually work for real use cases. This topic will be of interest to anyone who is working on edge applications and use cases and wants to optimize their investment in management tools. Our chats will be about, but not limited to items such as
- Versioning automation – Managing the cats across your network
- Dependency graphs for modular automation
- O/S Install & Repaving across the WAN
- Validation and trust
- Management of mixed architecture and hardware environments
And as you can see in the list above we can’t really discuss automation and remote management without touching on security, so our next session is: Trust and Verification for the Edge
It is clear that the edge has some unique security challenges related to isolation and distributed nature of the edge nodes. In this session we will focus on methods for managing trust and verification where the edge is by its very nature vulnerable to attack, either through direct physical access or because the nodes are on untrusted networks. This topic will be of interest to anyone who is working on edge applications and use cases and wants to reduce their security exposure. To give you more ideas, we will be talking about things like
- Trust & Verification of components for external/(temporarily isolated)/edge sites
- Best practices for methods of Zero-trust authentication/authorization – is there one or does it depend on the use case?
- How to secure nodes that are not on a private network? – i.e. not on a VPN, SD-WAN or MPLS network.
- Do we need a specific API to deal with/configure those nodes?
- Can we trust the hardware when there is potential for physical access? – Trusted operation: Secure Boot / TPM
Covering these two areas will use up all our time on the first day, so we will drill into some important areas of detail on Day 2.
Tuesday, October 19, 2021 (1400 UTC – 1600 UTC)
hinking about cloud-to-edge and edge-to-cloud communication makes you realize that the Edge sites are not standalone, isolated environments, they are part of a geographically distributed system often on a massive scale. To ensure stable and reliable connectivity, we just have to talk about our next key topic, networking.
Our first session on the second day is: Do you know what your network is doing at the Edge?? How the network affects edge and how can we make them more integrated with the applications they support?
Our objective is to gather requirements for both applications and networking elements to improve how edge applications perform at the Edge by collecting input from an audience who know enough about the differences between wireless transports/access and wireline transports/access delivery systems. an example, let’s take a look at the reinvented Radio Access Networks (RAN). The edge device t has a Distributed Unit (DU) with a guaranteed response behaves differently 5G/LTE wireless connection, MEC IoT devices. Centralized Units (CU) can also be set up at the edge, and there are different configurations to build this architecture. But, what do you do with edge devices that need to support both protocols and how does it affect the applications? As part of this discussion, we will touch on items such as
- What Networking APIs are needed to achieve the objective, and should they be dedicated?
- How is networking managed and reported on?
- Every telco configure their networks slightly differently that can affect the stability of the network connections to edge nodes – How can this issue be addressed?
to details and practicalities as we discuss tools that you’re already depending on: DDI (DHCP, DNS, IPAM) Automation and Integration
When you are managing edge nodes they are going to be distributed there is no workaround for that. In this session we will discuss the requirements for managing DDI components that are needed to maintain the access to the edge applications for management and support of the application lifecycle and CI/CD processes:
- Criticality of DHCP for bootstrap
- Criticality of DNS for certificate management
- Criticality of DNS for validation
- Criticality of DNS for traffic isolation
This concludes our second day. The good news is that we have some more time for debate and we kept some of the most exciting sessions to our third and final day.
Wednesday, October 20, 2021 (1300 UTC – 1600 UTC)
our last day to cover edge computing related topicsyou probably wonder why we haven’t touched on containers yet. We kept some of thse to the last day where the first topic is: Containers suck at the Edge – What can we do to make them actually work?
Our objective for this session is to identify container elements that are needed to make better edge applications. They are appealing because of their light footprint and efficient use of resources, but management tools to manage cWAN distributed containers and containerized applications at the edge are woefully inadequate. This topic will be of interest to anyone who is working in the container ecosystem to improve how containers are managed as well as how they are using the enhanced hardware resources that are available for them on the edge. Our discussion will include items like
- Challenge of container repos and distributing container images
- What is missing to be able to manage containers at the edge?
- Is Kubernetes too big for your edge?
As we talk about how to run workloads at the edge it is also important to shed light on a contin challengeinteroperability. To explore how far we can go to standardize our interfaces and communication, the next session is: Do we need edge specific APIs or…?
It is always a conundrum to find the optimal balance of standardized APIs while still keeping flexibility. Knowing the large variety of edge use cases this challenges just became a tad bit tougher than usual. During this session we are are going to explore what APIs are potentially specific to edge applications and use cases. You can think of the APIs of tools that are responsible for the management of edge sites, but we cannot miss out on discussing the potential of enabling application workload distribution (from within the application itself). The objective of this segment is to define requirements for APIs to support edge use cases with a primary focus on management interfaces and as time allows to look into the application layer as well. The questions we are looking to answer include:
- If you are using OpenStack to build your edge solution, are the APIs suitable out of the box?
- How can we tackle the application space? What are constraints/requirements of an application that are specific to edge?
- How do approaches like DevOps affect APIs and interfaces?
To use all that we learned and decided during the three days of sessions we chose to close our discussions by taking a look at architecture choices for the end-to-end distributed edge infrastructure. Our last session is: Centralized/decentralized/federated/multiple control planes
When you broaden your focus from an edge site to the whole end-to-end solution you get to realize that building a geographically distributed system on a massive scale is still not an easy task. Especially when we look into expanding our systems and solutions to grow beyond the borders of countries and continents as the different rules and regulations all affect our design and implementation choices. Taking all that into account and adding that to the management challenges our objective is to summarize the previous discussion and apply our learnings to be abe to give guidance on decisions such as:
- How to manage a massively distributed edge system?
- Is federation an option and if so, what ways there are to implement it?
- How to make the best choice when you choose components such as databases and message queue?
This concludes our packed agenda to discuss many aspects of edge computing that are relevant to consider when you pick your architectures and build your edge infrastructures. The topics during these three days are organized to provide for a fruitful discussion individuals and organizations from the wide ecosystem including open source communities, standards bodies, vendors, architects, developers and anyone, who has an interest edge computing into a thriving reality
About 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 open infrastructure technologies, not exclusive to OpenStack.