Deploying our first 5G application at the edge

 

5G Edge demystified

Verizon’s 5G Edge with AWS Wavelength service allows customers to experience the benefits and utilize the capabilities of the Verizon 5G network and MEC. In partnership with AWS, 5G Edge enables applications and services to run closer to where mobile device users are located. This lowers service latency and can offload compute-intensive operations from mobile devices. And AWS makes it easy to extend existing infrastructure from regional cloud locations to Wavelength Zones, which reside at the edge of Verizon’s wireless network.

There are some new considerations when deploying applications and services to an MEC environment, such as:

• A Wavelength Zone is a single-fault domain with a Parent Region.
  You can use the Parent Region as fallback for your 5G Edge app
• AWS Wavelength supports a limited number of EC2 instance types
• To expose 5G Edge applications to the carrier network, additional resources are needed. Fortunately, AWS Virtual Private Cloud (VPC) constructs make this easy to do — and do securely. Security groups, network access control lists (NACLs), and route tables work the same way in both Wavelength Zones and Regions

Why Verzon selects EKS

Prior to deploying our application, we extended our AWS Elastic Kubernetes Service (EKS) to mobile edge computing in order to standardize our deployment and infrastructure strategy for applications. EKS allowed us to use a managed Kubernetes service to deploy, run and scale all of our applications in the same manner. Applications are deployed in containers, meaning we can build our infrastructure once and then turn our focus to performance and scalability.

So, what’s the difference between EKS at the edge vs. in the Parent Region? In truth, it really isn’t that different. At the edge, Kubernetes is very much the same as in a regional cloud. Teams can still provision compute, storage and networking resources for Kubernetes, and declaratively deploy applications to 5G Edge, just as in the far cloud. Constructing the edge components of a Kubernetes cluster requires extra AWS resources. Labeling EKS nodes in the edge differently from nodes in the cloud helps to target deployments effectively.

Verizon 5G Edge and EKS

Here are all of the key components of EKS extended to 5G Edge:

• Edge Proxy ASG: Exposes applications using a minimum of carrier IP addresses
• NodePort Service: Exposes Edge Ingress ports to the Edge proxy ASG
• Edge Ingress: Exposes apps running on EKS MEC nodes to Wavelength
• EKS Worker ASG: Provides the compute environment for MEC-based apps
• Cloud Ingress ELB: Exposes apps running on EKS worker nodes in the far cloud
• EC2 VPC Endpoints: Provide the ability to extend EKS to Wavelength
• S3 Gateway Endpoint: Provides an optimal path for S3 API calls
• EKS control plane: Exposes the k8s API on multiple subnets for the Wavelength Zone to reach it with fault tolerance
• Node Labels: Permit selective deployment of apps to the cloud or to MEC

In 5G Edge, infrastructure considerations include when to Separate, Save and Scale.

Separate services running in the regional cloud from those in the edge.

In the regional cloud, you’re building for failure tolerance when you move from datacenter to Amazon. From traditional AWS to MEC, you’re refining your application to separate the low-latency components from the ones that can handle longer round-trip times for handling requests. Generic compute instances in an Amazon Region are sufficient for that, so you don’t put every service in the MEC. Instead, focus on use cases that need low latency and near-edge compute vs. everything else the regional cloud provides.

So where should developers start? Think about the problem domain of your application, and break it down into two parts:

1. Those that are latency-sensitive and compute-intensive
2. Those that require more data to be stored and can handle longer retrieval times

The former would be best to go into MEC; the latter into the regional cloud or traditional data center. Think about where the components of your application will function optimally.

Saving up-front costs vs. making long-term investments

At this time, Wavelength Zones only provide on-demand instances, or savings plans to budget ahead for either one year or three years of use. As a result, utilizing fewer, bigger instances will likely pay off in the long run, and be enough to cover fault cases and run most workloads. Ever-changing latency baselines will also affect decision-making about how much compute is needed to meet or exceed those baselines.

Scaling for both ad hoc and planned events

In the regional cloud, compute instances scale according to seasonal needs (e.g., Prime Day); they scale up and then down, after the season passes. But what should happen at the edge? What do scaling events look like there? How high can we scale and how quickly? With MEC nodes deployed to sporting arenas, scaling around scheduled events in these arenas could be one such strategy. New features of AWS Auto Scaling provide more intelligent scaling options.

Learning from our deployment challenges

We had to start with the AWS command-line interface (CLI) and then the AWS console. Initially, some aspects were visible in one toolset that weren’t in the other.

Our requirements also drove the specs for automation; eventually, we were able to provision both Wavelength-based VPC components and EC2s, via AWS CloudFormation. Some preparatory steps were still done in AWS CLI, as CloudFormation isn’t always as up to speed on new AWS features.

AWS has not yet made a load balancer resource available in Wavelength. Our workaround was to deploy a HAProxy Auto Scaling Group of EC2 instances. This was our reverse proxy bearing a carrier IP address that forwarded traffic to a backend running the reverse geocode application. We were able to use a Lambda function to add/remove hosts from the HAProxy config to simulate a very basic ELB.

Finally, deploying an application to 5G Edge with AWS Wavelength isn’t just about the application — it’s about the data that will accompany it. We generated a dataset that contained mappings of lat-long pairs to street addresses that were pertinent to the coverage area of the MEC node.