The LF Edge Interactive Landscape is a community-driven Linux Foundation project designed to provide a holistic overview of the edge computing ecosystem. It’s based on the same open source code as the Linux Foundation’s popular Cloud Native Landscape and anyone in the community can request an addition via a pull request on GitHub.
The main benefit of the LF Edge Landscape to developers is simple: it provides a single reference point for providers of edge solutions from content delivery networks (CDNs) and distributed caches to physical infrastructure and service providers. As a result, the landscape can be a useful source of information for finding the right tool for an edge computing project or even identifying all the pieces required to design an end-to-end solution.
Here, we’ll review the software and networking layers of the landscape and provide some practical examples of how they work together.
LF Edge Landscape Categories
The LF Edge Landscape covers everything from the groups that facilitate discussion among edge stakeholders, to system integrators, to LF Edge Member Companies. In this section, we’ll focus on the landscape categories most relevant to developers.
As you’d expect, the traffic routing category is all about DNS and routing. In many edge applications such as driverless cars, technology like geo-proximate DNS can help slice precious milliseconds off latency numbers.
One of the more interesting projects in this category, and one that should arguably be in the “networking” category, is VyOS, an open source (GPL v2.0) network operating system. VyOS provides developers of edge solutions with an open source option for features such as BGP, VPN, NAT, DHCP servers, and DNS forwarding.
The platforms category of the LF Edge Landscape focuses on platforms related to “deploying, managing, and scaling” edge workloads. That means developers will find solutions like CDN, edge PaaS, and distributed caches. The overarching theme across all the subcategories here is bringing resources closer to where they’re needed and increasing speed for edge applications in a scalable way.
Security is table-stakes for edge compute projects that expect to see production use. Encrypting data in transit and data at rest, using stateful firewalls, protecting against DDoS, implementing policies of zero-trust, and following other security best practices are vital.
Given that importance, it may be surprising to find that the security category in the LF Edge Landscape consists of only two entries today: Aporeto (who have since been acquired by Palo Alto) and Xage Security, a blockchain platform focused on IIoT.
However, while we’d like to see this section expanded, we can also help explain why it’s so empty today.
In most cases, other categories within the landscape have security baked in. For example, at StackPath, we offer security features such as Origin Shield, DDoS protection, Edge Rules, and Edge SSL, but reside in the “Platforms” category of the landscape. Similarly, IaaS platforms like AWS, Digital Ocean, and Google Cloud support plenty of native security features and integrations.
The networking category of the landscape focuses heavily on virtualization and abstraction of traditional network services. Technologies like SDN, SD-WAN, and network functions virtualization (NFV), as well as features like QoS, WAN optimization, and layer 2 switching are the name of the game here.
The benefit this category provides to developers is that software-defined solutions are more extensible and agile than proprietary hardware appliances. For many use cases, locating network functions at the right place can have a positive effect on performance and security.
In the context of the LF Edge Landscape, infrastructure covers everything from IaaS platforms to monitoring and provisioning of virtual machines and containers to the physical infrastructure you’ll find in micro data centers.
Vapor’s Synse stands out as the only entrant in the monitoring subcategory, but the others are full of familiar names. For example, in “provisioning,” Apache Mesos and Kubernetes (K8s) are major players in the container orchestration space. Similarly, in “virtualization,” Docker is the 800-pound gorilla when it comes to containerization, but the category also includes a few promising upstarts like the Edge Virtualization Engine (EVE).
The IaaS subcategory is one of the most mature. It includes RackSpace, AWS, Digital Ocean, Google Cloud, and Alibaba Cloud.
How the Different Layers Work Together
Much like the TCP/IP and OSI models we all had to learn at some point, the landscape is a useful conceptual model. However, as with other conceptual models, the layers can become a bit fluid so a real-world example can help drive the idea home.
To that end, let’s look at an edge computing use case and see how it uses different layers of the edge landscape. For this example, we’ll consider the deployment of MQTT servers at different geographic locations for an IoT application.
In that case, you may use:
- Anycast DNS to reduce latency (Traffic Routing)
- A private backbone to reduce latency between endpoints (Platform)
- Encryption, DDoS protection, and firewalls (Security)
- SD-WAN for policy-based routing of traffic within your WAN (Network)
- Virtual machines to run the MQTT server application (Infrastructure)
You can also use other monitoring, provisioning, and security solutions that fit into different layers of the landscape.
Single vendor vs. suite of vendors
In practice, you may find a single vendor that can deliver many, or even all, of these features. For example, we’re fond of edge virtual machines on our backbone for low-latency edge compute.
In other cases, you may be better served by tying together discrete solutions from vendors across the landscape. For example, when content delivery is in play, some enterprises prefer a multi-CDN approach that would be managed at the traffic routing layer.
The important piece is knowing how to optimize for your use case.
If you’re a developer and currently researching different edge computing technology with which to build a latency- and/or bandwidth-sensitive application, using the LF Edge Landscape as a starting point will save you a lot of time in initial research. Technology researchers and developers have already done this work for us and contributed their findings to the LF Edge Landscape project.
If you do your own research and find something that’s missing from the landscape, you can open a pull request on GitHub to have it included.
The post An Overview of the LF Edge Landscape for Developers appeared first on Articles for Developers Building High Performance Systems.