I’ve written before about the power of delivering CDN and related services on virtualized commodity servers deployed deep in operator networks (see Extending the Cloud to the Network Edge and A Perfect Storm). The arguments in favor of such an approach follow directly from the well understood advantages of cloud computing: (1) the availability of elastic resources makes it easy to scale applications as demand increases; (2) a rich ecosystem of programming environments and foundational services lower the barrier-to-entry for building new applications; and (3) the ability to amortize system administration across many users reduces the total cost of ownership.
Cloud computing typically implies data centers, but network operators—Telcos and MSOs that operate access networks—recognize that the same advantages apply to the network edge, albeit with an edge-specific twist:
- With respect to resource elasticity, being able to deploy network services in virtual machines running on commodity processors instead of deploying purpose-built appliances means reducing the time-to-market for new services and making it easy to re-provision the resources allocated to existing services as demand dictates.
- With respect to the software ecosystem, being able to leverage general-purpose building block services instead of integrating stove-piped applications from a limited set of vendors makes it easier to introduce incremental value-added functionality into the network, and as a consequence, opens the space for innovation by third-party service providers.
- With respect to reducing operating costs, extending the cloud into the access network introduces both a risk and an opportunity. Since network operators are both cloud users (they introduce and operate applications running on the cloud platform) and cloud providers (they own and operate the underlying network/computing infrastructure), the risk is that a proliferation of services will introduce a proliferation of OSS/BSS procedures, but at the same time, there is an opportunity to introduce a unified approach to OSS/BSS across a wide set of services.
In telling this story to different audiences, I’m often asked about the relationship between network services running in virtual machines and Software-Defined Networking (SDN), the former not yet having a catchy name and the latter getting significant traction in the cloud community. The short answer is that they are complementary ideas: the former is essentially about replacing purpose-built network appliances with functionally equivalent services implemented in software and running in VMs, while SDN is primarily about decoupling the network control and data planes, and putting the former under the control of software running in a (logically) central location rather than being hard-coded into individual appliances.
The slightly longer answer is that SDN will likely play a role in managing virtualized network services, much in the same way that SDN is starting to play a role in making cloud services easier to manage. Just as in the data center, VMs running services at the network edge must be interconnected (so they can be composed) and isolated (so they do not interfere with each other), new VMs must be brought on-line, unneeded and failed VMs must be taken off-line, and existing VMs must be re-provisioned. SDN can help operators manage these processes.
But when you move beyond network management, and consider the potential of SDN to catalyze new capabilities, it is important to keep in mind that operator networks are very different from data centers. First, it matters where in the network a VM is instantiated, meaning that VM migration will have different constraints at the edge than in the data center. Second, edge resources are not as abundant as in the data center (meaning that VM provisioning is not as fluid), and the multi-tenancy requirement is not as severe at the edge since the operator will want to select (and qualify) the services that run rather than open its edge resources to arbitrary 3rd-party applications. Third, many network services are already scalable and robust—i.e., they are self-balancing and self-healing by design—and so will not need to leverage SDN-enabled load balancing and failure recovery support.
On the other hand, there may also be new opportunities for SDN at the edge that are not relevant in the data center. For example, a service that transparently intercepts HTTP requests might use SDN to dynamically configure the network to pass-through (rather than divert) certain flows once the service determines those flows are not of interest.
Popping up to the 10,000-foot level, two approaches seem to be emerging. In one, the cloud and the operator network are treated as two distinct technologies (with the latter still largely constructed from purpose-built network appliances), where SDN comes into play by moving the network control plane from the individual appliances to software running in the cloud. The other approach goes a step further by extending the cloud into the operator’s network, with virtualized services running in both the data center and at edge sites in the operator’s network. Just as in the first approach, SDN can still be used to simplify management across the resulting center-to-edge cloud, but taking this more expansive approach is essential to fully exploiting the advantages of cloud computing at the edge, which derive from being able to enjoy the cost/performance and elasticity benefits of virtual machines running on commodity processors. (For an analysis of commodity versus not-quite-commodity appliance blades, the interested reader might check out Jim Dolce’s recent blog posting.)
