DevOps & Cloud
Introducing the Verizon Edge Discovery Service
By Robert Belson, Verizon Corporate Strategy & Raghuram Parvataneni, Verizon Technology Leader
We want to make it easier than ever for you to orchestrate application traffic for your mobile edge computing (MEC) applications. The power of MEC resides in part in its ability to provide local computing with low latency, by having mobile clients use the nearest MEC node to handle application traffic. Until now, doing so has been unnecessarily complex and has relied on undifferentiated heavy lifting, including identifying client geolocation through best-effort services or, even worse, manually mapping carrier IP addresses.
Introducing the Verizon Edge Discovery Service
Today, we are excited to announce the launch of the Verizon Edge Discovery Service (EDS), which addresses the most fundamental challenge of the rapidly evolving edge-computing landscape to date: optimizing dynamic routing from mobile devices to an ever-changing set of MEC nodes.
Available for use on the 5G Edge developer portal, EDS can be used to seamlessly create service registries associated with the fleet of allocated Carrier IPs for their service — across any number of Wavelength Zones — and Verizon takes care of the rest.
Why service discovery is not enough
With the advent of microservice-based architectures, service discovery has been a critical feature for well-architected applications. When decoupling the component services of a monolithic application, the services in the resulting architecture might frequently have multiple copies of themselves. These are potentially spread across multiple AWS Availability Zones, or even regions.
Two popular solutions have emerged to address this challenge:
- In rudimentary cases, managed DNS services such as AWS Route53 using geolocation-based routing coupled with load balancers can effectively route clients to the closest instance of a service and distribute traffic evenly. However, as the volume of services increases, this method becomes increasingly unwieldy due to the operational burden it takes to maintain health checks of target groups, load balancer routing and security between every pair of endpoints.
- Recently, open-source solutions such as Istio and Consul have created efficient, easy-to-use approaches to deploy a service mesh using a dedicated infrastructure layer for intra-service routing, most often using a proxy.
While these solutions are incredibly powerful for most infrastructure patterns, MEC throws a wrench into these models because of its inherent network design.
EDS in action
In a MEC world, there are two types of network traffic flows.
- East-west traffic refers to traffic within the Wavelength Zone or more broadly across a virtual private cloud (VPC). Given that VPCs can span both traditional Availability Zones and Wavelength Zones, inter-AZ traffic via Private IP addresses can also be seen as east-west traffic. As you think about inter-VPC communication and coordination, existing service discovery tools such as CloudMap are the perfect choice for east-west traffic.
- North-south traffic, which refers more broadly to client-server communication, requires network intelligence more than ever before to help make decisions that are far beyond the scope of geo-lookups.
Let’s start with a practical example.
If a mobile device in the Boston metropolitan area needs to connect to an application, should it:
- Connect to the Boston Wavelength Zone
- Connect to the NYC Wavelength Zone, the next geographically closest mobile edge zone
- Fallback to the parent region?
This non-exhaustive list of scenarios and client decision-making depends on several factors, including:
- Where the app is deployed. It could be that the service is only deployed in some Wavelength Zones and not others, or none at all
- The state of the network. It could be that the network path to the NYC Wavelength Zone is faster than the one to the Boston Wavelength Zone, despite being in Boston. This would occur if the mobile IP address is anchored to a NYC-based packet gateway. The mobile device alone, however, would have no way of knowing that
In a non-carrier IP world, these questions could be seamlessly addressed by a combination of Route53 and CloudMap and can continue to be used for micro services traffic within the Wavelength Zone (i.e., east-west traffic).
However, for north-south traffic, a new service mesh is needed: one that is intimately aware of the state of the network, the location of the mobile client and the relative topological distance of each Wavelength Zone relative to the client.
Why geo-lookups can’t solve the north-south traffic problem
Today, determining the optimal server across a cloud deployment typically occurs by leveraging well-maintained databases of <IP address, geolocation> to identify the coarse location of the user device, and then calculating the closest server from the user. While GeoIP lookups perform well for traditional CDNs and cloud datacenters, this method falls short in a world of hyper-localized edge deployments.
In essence, geolocating IPs is 99.8% accurate on a country level, 80% accurate on a state level in the U.S. and 68% accurate for cities in the U.S. within a 50-kilometer radius [Source: MaxMind].
This means that, in an edge computing world — one where nodes may be separated by less than 50 kilometers — the accuracy of geolocation-based routing solutions drops to 68% , meaning that MEC service routing based on geolocation may fail up to 32% of the time.
To realize the true potential of edge computing, a new service discovery method is needed. One where selection of the optimal endpoint is calculated not from a static database but rather from live network intelligence by dynamically evaluating the state of the network and making routing decisions based on latency, connectivity, load and other unique characteristics of the application profile.
How to use Verizon Edge Discovery Service
In this example, let’s assume we have a web application exposed on port 443 across all 6 active Wavelength Zones in us-east-1 region:
155.146.0.225: Boston Wavelength Zone
155.146.65.19: NYC Wavelength Zone
155.146.37.12: Washington, DC Wavelength Zone
155.146.50.174: Atlanta Wavelength Zone
155.146.81.91: Miami Wavelength Zone
155.146.96.195: Dallas Wavelength Zone
Using the Edge Discovery Service, developers can populate a service registry, test_app_web_service, and append the <IP,port>, mapping for each of the IP addresses to the service registry.
Note that the IP addresses could be EC2 instance hosts, load balancers (e.g., HAProxy, Nginx), ingress controllers or NodePorts — it’s up to you.
Now, when a mobile client tries to connect to this web app, it has no working knowledge of the deployment topology. Through the Edge Discovery Service, the client passes their Carrier IP address and, using the underlying network intelligence associated with the latency from the client to each potential endpoint, is presented with the best and topologically closest endpoint.
Even if you remove 155.146.0.225, add a second Carrier IP to the Boston Wavelength Zone (155.146.0.218), or remove a Wavelength Zone altogether, Verizon’s network intelligence will dynamically select the most optimal route.
To get started, sign up and see for yourself the power of network intelligence to orchestrate edge applications and visit our website to discover ways to Verizon 5G Edge and MEC to work for your organization.
For more information, please check out our documentation or let us know your feedback directly at verizon5gedge[at]verizon.com.
About the Authors
Robert Belson joined Verizon’s Corporate Strategy team in October 2019, and is principally focused on leading their Developer Relations efforts for 5G Edge. Robert has a passion for 5G networks, distributed systems, serverless architectures, and working with customers on designing cloud-native solutions. Robert can be found maintaining the Verizon 5G Edge Blog on Medium and engaging the developer community through tutorials, Immersion Days, and meetups.
Raghuram Parvataneni is a technology leader bringing years of networking and software expertise from many industry verticals in cloud, edge, and on-premise environments to the Verizon team, backed by a solid academic background. Raghu specializes in software-defined networking, cloud and edge-native applications architecture and design and holds several patents in the cloud and edge compute domain. He is currently working as a distinguished member of technical staff, leading strategic projects across functional organizations and developing edge technology architecture solutions.
