March 12th, 2019
Written by Curtis Collicutt
Tagged in , , ,

Predictions for Edge Computing in 2019

The edge is a new and important place to be. In 2019 edge and 5G related technologies will steadily improve. Here are a few predictions:

1. Hardware: More Important Than Ever

Some edge deployments will be relatively small, as small as a couple of servers. With such limited resources and considerable application performance requirements, it’s imperative that edge systems are utilized to their fullest, which means getting the most of the hardware. For example, the use of the Data Plane Development Kit (DPDK) and similar concepts to improve network application performance while considerably reducing CPU requirements. Further, due to the slowing of Moore’s law, to continually increase performance, specialized hardware is required. Examples: FPGAs, GPUs, and Smart NICs. Finally, expect to see diverse CPUs deployed.

2. Evolution of Who Should/Could/Can Provide 5G and Related Services

The Citizen Broadband Radio Spectrum (CBRS) in the US has the potential to allow new, smaller, localized and innovative entries into the telecom space. These entities will be additive and supportive to traditional telecoms. The CBRS spectrum model will be developed in countries where similar concepts don’t currently exist. In combination with shared edge data centers and innovative, smaller providers, there will the potential to create smart, shared infrastructure for providing diverse 5G services. 2019 will be the year CBRS style models get started rolling.

3. Public Clouds Move into the Edge…Somehow

Public clouds are already doing very well in the IoT arena, but edge locations are another matter. Will hyperscalers step towards the edge either directly or via partnerships? Certainly, organizations such as Google are familiar with deploying services into Internet exchanges, ala Netflix Open Connect, but will they want to own the edge or instead work collaboratively with partners? Further, both AWS (with Outpost) and Azure (through Azure Stack) have on-premise solutions that can extend the public cloud. What exactly will happen remains to be seen, but certainly some movement will occur, and these questions will begin to be answered. We will also see “Cloud to edge” interoperability improvement.

4. The Heat Moves to VNF Vendors

NFV tooling will continue to improve. In 2018 Telecoms often repeated the concern that open source tooling was not yet ready for 5G or edge deployments. These complaints will continue in 2019, but open source systems such as ONAP and OSM will improve and see production deployments. However, more importantly, advancements in these systems will push vendors to not only improve their management and orchestration systems but also to support cloud-native deployment models. In short, the heat will move off open source systems and onto VNF vendors.

5. Telecoms Begin to Alter Core Infrastructure to Support Edge Use Cases

As telecoms improve their capability to deploy data center automation, they will begin to complete major deployments in large data centers. Next, deployments into smaller localized data centers will also finish, and telecoms will begin being preparing for edge models, such as Central Office Re-Architected as Datacenter (CORD) and similar concepts. Also, look to see large telecoms partner with new edge players for deployments.

6. Containers and Virtual Machines (Confusingly) Blur

OpenStack is a preferred infrastructure manager for telecommunications. However, containerized workloads and Cloud Native Virtual Network Functions (CNVNF) are also on their way up the slope to the “peak of inflated expectations.”

 

CNVNF typically means container-based systems orchestrated by Kubernetes. That being said, there is little difference between a cloud-native VNF that is deployed into virtual machines as opposed to containers, at least in terms of automation…it’s just that different APIs and/or runtimes will be utilized based on needs. Through the use of container runtimes such as Kata Containers, systems such as Kubernetes can deploy virtual machines instead of a standard container. Confusing matters is software like Kubert, which create an API within Kubernetes for managing virtual machines, and technologies like AWS’s open source virtual machine monitor Firecracker.

 

Throughout 2019, the blurring of containers and VMs will continue and organizations will begin to understand the subtle, and not so subtle, differences between OpenStack, Kubernetes, Kata Containers, and Kubervirt-like technologies.

Bitnami