Edge Cloud and network details

Our last post—”Cloud at the Edge“—introduced the concept of Edge Cloud. In this post, we explore some network details, because Edge Cloud is highly dependent on network and network functions. For further reading, see the third part of this series—”Architecting at the Edge“—for more info on how to bring all these components together and create a deployable architecture.

While most of us are familiar with the deployment models in cloud computing—namely private, public, hybrid, and multicloud—where does edge fit in? Is edge a new deployment model? Is it part of public cloud or private cloud or another architecture in a multicloud topology? Or is it something totally different?

Adding another layer of complexity, we also consider NaaS (or Networking-as-a-Service), where customers who don’t want to build their own networking infrastructure can get networking services from cloud vendors or third parties for a contracted period. NaaS uses virtualized network infrastructure to provide network services to the customer. It is the responsibility of NaaS providers to maintain and manage the network resources.

Please make sure to check out all the installments in this series of blog posts on edge computing:

• Part 1: “Cloud at the edge”
• Part 2: “Rounding out the edges”
• Part 3: “Architecting at the edge”
• Part 4: “DevOps at the edge”
• Part 5: “Policies at the edge”
• Part 6: “Models Deployed at the edge”
• Part 7: “Security at the edge”
• Part 8: “Analytics at the edge”
• Part 9: “5G at the edge”
• Part 10: “Clusters at the edge”
• Part 11: “Automation at the edge”
• Part 12: “Network slicing at the edge”
• Part 13: “Data at the edge”
• Part 14: “Architectural decisions at the edge”
• Part 15: “GitOps at the edge”
• Part 17: “Storage services at the edge”
• Part 18: “Cloud services at the edge”
• Part 19: “Distributed cloud: Empowerment at the edge”
• Part 20: “Data sovereignty at the edge”
• Part 21: “Solutioning at the edge”
• Part 22: “Connected products at the edge”
• Part 23: “Foundational models at the edge”

Network function virtualization (NFV) and software-defined networks (SDN)

NFV and SDN play key roles in edge computing. Virtualization provides the capability to share and sell just about any platform component, including cloud infrastructure or networking. For an overview of virtualization, see our video, “Virtualization in 2019.”

NFV virtualizes network services traditionally run on proprietary, dedicated hardware. With NFV, functions like routing, load balancing, and firewalls are packaged as virtual machines (VMs) on commodity hardware. Individual virtual network functions, or VNFs, are an essential component of NFV architecture.

Software-defined networking makes NaaS services more prevalent as service providers look to leverage their hardware infrastructure so that it can be sold as enterprise network services.

NFV and SDN are complementary technologies. NFV moves services to a virtual environment but doesn’t include policies to automate the environment. SDNs, however, offer centralized management functions.

Internet of Things Devices

Wireless sensors, actuators, cameras, etc. make up what we call Internet of Things (IoT) devices. They can be free-standing or attached to a particular object and are programmed to automatically send data to other objects or people without human intervention. IoT sensors are key components in creating “sensemaking systems with situational awareness.” An IoT platform on the other hand, facilitates communication and data flow between these devices and also helps with device management. It is fair to say that these IoT devices are the primary drivers of edge computing.

Wearables

Wearables commonly refer to smart electronic devices that contain micro-controllers being incorporated into clothing or worn on the body as implants or as fashion accessories. Incidentally, the recent explosion of wearable tech isn’t just about humans anymore; it has given people new ways to find, monitor and connect with their pets.

MEC

Multi-Access Edge Compute (MEC) centers are becoming increasingly common among the network providers. These could be a single tier of distributed regional data centers or multiple tiers incorporating more localized hub centers that are often aggregating multiple celltower base stations. These centers are characterized by ultra-low latency and high bandwidth as well as real-time access to radio network information that can be leveraged by applications. We should note that the term “MEC” is used in different ways by different wireless and 5G carriers. Some of them use it to describe architectures deployed on customer premises.

Defining edge

Edge can mean different things to different people. In speaking with IBM edge stakeholders and our customers, we’ve found it helpful to define four broad segments (or ‘four corners of edge’): Industrial, Telco, Consumer, and Enterprise. See the figure below.

While this is just one perspective, it’s an approach that has been immensely helpful in avoiding apples-to-oranges terminology miscommunication and focusing on types of technologies and use cases.

Many use cases will, of course, touch on more than one segment. For example, a factory IoT “Brownfield” sensor modernization project might happen concurrently with Enterprise Network Cloud upgrade and/or a private 5G network rollout. So it behooves us to ask clients the question—which segment of edge are they focused on?

Sensible and Sensible

We often use the word “sensible” when talking about edge. There are actually two quite valid applications of the word for edge.

One is where we still deal with traditional sensors (e.g., IoT/accelerometers or thermometers) as architectural components that acquire data and help create signal. With new technologies like edge and artificial intelligence (AI) there are many new ways of designing and deploying technology and thus improving and automating situational awareness with sense-making systems.

We increasingly hear about intelligent edge or intelligence at the edge. It is the ability to process, analyze, and aggregate data at the spot close to where it is captured in a network and allowing systems to make some operational decisions right there—possibly semi-autonomously, if not autonomously. This is quite contrary to sending the data to a data center or to the larger cloud, processing it there and then pushing operational decisions back to the edge platform. Take, for example, smart cameras or accelerometers with edge-deployed inference or deep-learning models. The signal from the data allows humans to take actionable insights where the action is.

This brings us to the second definition of sensible—logical, wise or prudent. For example, is the “wise and logical” architecture one that sends every frame of high-definition data from 50 cameras from Alberta to Texas for analysis? Or is it logical to move some of the compute closer to the activity? In many cases, the latter is most logical and desirable…and quite sensible.

Role of edge

The evolution of edge and edge cloud and changes with distributed networks and Internet of Things (IoT) will play a role in substantial changes around bandwidth, latency, and decentralization:

• Bandwidth and traffic from IoT platforms that is no longer being sent to central locations
• Latency affecting critical applications will be addressed in new ways
• Decentralization of workload and compute (including AI and models) to the physical edges

This will open up new business opportunities.

The IBM Cloud Architecture Center offers up many hybrid and multicloud reference architectures. Look for the addition of new edge cloud reference architectures addressing the four segments we alluded to earlier. IBM Multicloud Manager will be central in these architectures.

Learn more about IBM artificial intelligence solutions.

More posts in this series on edge computing:

• Part 1: “Cloud at the edge”
• Part 2: “Rounding out the edges”
• Part 3: “Architecting at the edge”
• Part 4: “DevOps at the edge”
• Part 5: “Policies at the edge”
• Part 6: “Models Deployed at the edge”
• Part 7: “Security at the edge”
• Part 8: “Analytics at the edge”
• Part 9: “5G at the edge”
• Part 10: “Clusters at the edge”
• Part 11: “Automation at the edge”
• Part 12: “Network slicing at the edge”
• Part 13: “Data at the edge”
• Part 14: “Architectural decisions at the edge”
• Part 15: “GitOps at the edge”
• Part 17: “Storage services at the edge”
• Part 18: “Cloud services at the edge”
• Part 19: “Distributed cloud: Empowerment at the edge”
• Part 20: “Data sovereignty at the edge”
• Part 21: “Solutioning at the edge”
• Part 22: “Connected products at the edge”
• Part 23: “Foundational models at the edge”