X
Business

A data center with wings? The cloud isn't dead because the edge is portable

The race to the edge, part 2: Where we come across drones that swarm around tanker trucks like bees, and discover why they need their own content delivery network.
Written by Scott Fulton III, Contributor
scale-002-fig-01.jpg

Someplace in America, a safe distance of several feet from the shoulders of a major highway, drone cameras are flying in parallel with a fleet of tanker trucks. The next time you encounter a fuel truck or a milk truck, take a moment to see if there are any buzzing camera drones in its vicinity.

They've been commissioned to take thermal pictures of these trucks, and transmit them live, in real-time, to a server. There, the server re-processes those images, producing 3D, full-motion heat maps. If one of these trucks is leaking or isn't well-sealed, or if its contents are imbalanced and unsafe, an operations center is notified, and the driver may be told to pull over.

This is actually happening; it's not an excerpt from a rejected script for a basic cable series about mindless drones overthrowing the world. It's part of a trial run commissioned by an undisclosed industrial services firm, as part of an experimental use case for edge computing. The partner company for this trial may not be one of the first companies on your list of suspects: Limelight Networks, a content delivery network (CDN) service for some of the world's premier media brands, including CBS Media Group (sister company to the parent of ZDNet's publisher). By most accounts, Limelight is the world's #2 commercial CDN provider in terms of throughput, after Akamai.

TechRepublic: Edge computing: The smart person's guide

"Because we're a content delivery network, 90 percent of our traffic is outbound," Ersin Galioglu, Limelight Networks' vice president, told ZDNet. "We do egress. That's the nature of our traffic. With a lot of these edge compute initiatives, there is a lot of traffic that is coming inbound. There is an inbound need to get the traffic into edge computing devices. We found this as an opportunity for ourselves, because we have a vast, 26 terabit [per second] network. But it's a two-lane highway, and typically, I only use one lane. So we have a vast amount of idle capacity on the highway."

Lane Change

scale-001-fig-07.jpg

We're at Waypoint #2 in this first four-part journey for Scale, ZDNet's new series on the big engineering efforts in technology, and the people who dream and accomplish those efforts. Today, we find ourselves at the red pin on our map, at the point where the leased lines that connect customers to their data, separate themselves from the public internet. It's the content delivery network, and it's moving to someplace it's never been before: the input side.

Also: The enterprise technologies to watch in 2017

Easily the worst kept secret on and about the internet is that a great deal of it is not actually the internet. Much of the multimedia content you receive spent a major leg of its journey to you on a fast lane, courtesy of your friendly local CDN. It's a set of leased pipes that bypass the public internet, access to which is paid for by the content producer. Up to now, the point of contact between the CDN and the customer receiving these large blocks of data has been generally considered a network "edge." But as CDNs are discovering -- and as a certain financial analyst may have missed -- the edge itself may be portable.

"We don't have to do any major architectural changes to what we have built over the years," said Limelight's Galioglu, "to capitalize on the move to edge compute by customers, that you see around the world. More and more congestion is happening in the middle, and people are trying to push everything to the edge. There is a lot of bandwidth at the last mile, but as you get to the middle, there is a lot of congestion. That's one of the drivers for pushing to the edge."

Galioglu told us Limelight's customer is considering expanding the trial as a means of safely scanning petroleum pipelines from top to bottom, on a regular schedule. There are two drivers here, he said, the first and most obvious being cost reduction. But secondly, the cost of one accident or one leak, not just for containing the incident but also the inevitable public reaction, may be great enough by itself that simply investing in this system should immediately ameliorate the risk factor, driving down insurance costs.

The purpose of edge architectures in networks is to carve direct routes between the sender and recipient of data, bypassing the more tangled mesh of Internet Protocol (IP) routers. While this may sound contradictory to the oft-professed ideals of the internet (e.g., "democratization") the truth is, IP intentionally permits this. Major content providers rely on CDNs to push high-volume data -- especially videos -- along specially leased routes comprised of fewer "hops." If not for CDNs, much of the web as an industry would never have happened.

So edge computing is the same methodology applied to the opposite side of the value chain: input. Limelight operates in about 80 locations worldwide, about 46 of which , by Galioglu's estimate, already possess the depth and variety of connections necessary to serve as private gateways for input data.

TechRepublic: Edge computing deserves a spot in your big data playbook

"We can get somebody a global presence pretty quickly with connectivity," he said. "All these locations we have are interconnected with the backbone, which is private and secure." Essentially the same technology that Limelight has already been using to collect and stream video, he said, can be turned the other direction to stream and store data.

What Limelight's plan requires is something more than connectivity. It needs to back up that connectivity with some compute capacity -- not enough to replace the cloud, but just enough to run critical workloads. Galioglu insists that Limelight does not intend to compete in the co-location market by any means, especially since some of its own capacity is already co-located. Indeed, the company may be considering the possibility that its distance from the core of the distributed network may end up working to its advantage.

But will customers have the same altruistic viewpoint toward what constitutes a "critical workload?" This was a question on investment analysts' minds during Limelight's fiscal Q3 2017 conference call, to which CEO Robert Lento responded by acknowledging the program represented "a change in the mix of the business for us." Since customers have already demonstrated they're willing to pay a premium for quality of service, Lento said, the edge trial could be represented as a premium product.

It's something other participants in the emerging edge spaces, or "edges," have considered as well. Vapor IO CEO Cole Crawford (whom you met at Waypoint #1), told us, "We certainly do not take the view that the edge replaces these big hyperscale data centers."

But there isn't consensus on this point just yet.

Obviousness and obviation

"A self-driving car is effectively a data center on wheels," announced Andreessen Horowitz investment analyst Peter Levine, in a recorded speech to his colleagues in December 2016. "And a drone is a data center with wings, and a robot is a data center with arms and legs, and a boat is a floating data center, and it goes on and on.

"These devices are collecting vast amounts of information, and that information needs to be processed in real-time," Levine went on. "That is, [with] the latency of the network and the amount of information, [with] many of these systems, there isn't the time for that information to go back to the central cloud to get processed in the same way that a Google search gets processed in the cloud right now. And this shift is going to obviate cloud computing as we know it."

Levine effectively explained the allure of edge computing -- the idea that certain functions in the network need to be processed closer to the user, to minimize latency. Of course, if we could hyper-accelerate Moore's Law and shrink data centers down to the size of Dixie Cups, we could reinvent the PC again, and we could truly obviate the cloud.

But to assume cloud computing isn't adaptable to changes in the landscape of computing, in server technology, or the market at large, is to ignore both the concept of the technology itself, and the ingenuity of its biggest and best practitioners. In just the past few years, public cloud providers have adapted from hosts of whole and impregnable virtual machine "instances," to orchestrators of sophisticated microservices-based networks and their infinitely mutable virtual network overlays, all without the cloud market disappearing into history. And if Amazon wasn't capable of turning on a dime in response to huge market shifts, it would not have just acquired a supermarket chain.

Indeed, what could be happening at the edge today is an extension of the cloud we've come to know, to encompass a new and radical idea, and to integrate that idea into its own system of operation in a way that the proprietary operating system models of the 20th century never could.

Consumption Model

171028-m01-scale-w2-fig-03.jpg

The first successful cloud computing consumption model was the instance. It's still the prominent model today: You give the hosting provider an image of a disk drive where your operating system and applications are installed, and the provider stages that image as a virtual machine (VM). With the exception of distance, the VM behaves like your server would behave if it were next to you. It was true virtual co-location.

The fact is, it's as least as hard to stage a distributed application on cloud-hosted VMs as to do it in a 1990s-era client/server environment in your company's basement. You still create a network with a loop of local IP addresses. You still deploy a web server and a load balancer. You don't really gain anything from distance except for the convenience of leasing someone else's infrastructure. But if your operating systems are exactly the same as they were, then your applications will be the same as they were.

171028-m01-scale-w2-fig-04.jpg

The web introduced the concept of RESTful services: functions that can be invoked, executed, and deliver their results using HTTP protocol. Strangely, what the term "RESTful" originally translated to, is no longer what it does at all: Such a function does its work without having to maintain data about the program or the server that called it. There is no "representational state transfer." And because it's stateless, it can perform as part of a distributed application without the need for synchronicity and direct oversight -- two services which the web, by design, cannot provide.

The earliest web functions relieved the burden on servers to run entire applications in a network, just to deliver common, stateless functions. Arguably they were the most scalable functions in production. But prior to the advent of platforms as services (PaaS), they didn't need to be hosted on a massive scale.

171028-m01-scale-w2-fig-05.jpg

Trouble is, truly useful distributed applications require synchronicity and oversight -- or rather, orchestration. In 2013, the ideal of orchestration first revealed itself through Docker, the first viable system for packaging and deploying applications -- in whole or in part -- so they could run essentially anywhere. Entire applications could become subdivided into containers -- packages of functions that could communicate with each other, again using IP protocol. The barriers of the virtual machine that restricted applications to these inescapable VMs, were effectively broken.

But doing so introduced a curious, and heretofore unexplored, concept to the entire field of computing, one that hadn't been explored even during the server/client era: selecting the specific locations where individual functions could run based on real-time measurements of their servers' performance. It's an emerging concept called orchestration, and you're seeing more of it with the rise of the Kubernetes and Apache Mesos platforms. Orchestration makes it not only feasible but practical and valuable to choose where functions go. If they're crafted as so-called microservices, there might be no limitation on where that is -- on-premises, in the public cloud, on an embedded appliance someplace on the factory floor, or inside a CDN.

Also: How Salesforce is using low-code orchestration to save 'floundering IoT projects'

Here is the game changer: If your company's development team is smart and skilled enough to build microservices, then these functions can be delivered and deployed wherever it makes the most sense to be executed and managed -- provided, of course, a service exists there.

As recently as last year -- when Peter Levine proclaimed the death of the cloud -- it would not have been considered rational to consider a CDN as a hosting service for part of a customer's application. But very recent innovations in orchestration have rendered such a scheme not only feasible but practical. All Limelight Networks had to do, according to Galioglu, was switch it on.

Next destinations

scale-002-fig-06.jpg

Stay with Scale as our journey along and through edge computing, continues. Next, Waypoint #3 takes you to a place where you can enter a restaurant's kitchen and run across a data center masquerading as a refrigerator. Then we'll look at the very real prospect that the cloud, such as we know it, will become permanently divided into zones.

Journey Further -- From the CBS Interactive Network

Elsewhere

Editorial standards