Extending Clouds to 5G Edge: What’s Next

    Show all

    Extending Clouds to 5G Edge: What’s Next

    clouds and tops of skyscrapers

    Public Clouds and Mobile Network Operators: Peeling Back The Onion

    The recently announced partnership between Amazon AWS and four major mobile operators, Verizon, Vodafone, KDDI and SKT, is a marriage of mutual convenience that follows familiar patterns.

    The operators want application providers to make use of their upcoming 5G networks. The application providers would be loathe to be locked into a specific network provider, or deal with each edge network infrastructure separately. There is also a clear value in extending the existing public cloud infrastructure and architecture to the edge, rather than deal with it separately – if the public cloud providers can offer that. Consequently, the public cloud providers act as a natural and efficient aggregator of edge applications for 5G.

    As much as the operators need the public cloud providers, the need for cooperation is mutual. Without it, the cloud providers cannot offer their customers low-latency, high-bandwidth access to and from 5G end points.

    This kind of network access remains unattainable due to the scarce supply of local, metro-level compute footprint and network interconnect. While the public edge footprint and interconnect is being gradually built up by the edge data center providers like EdgeConnex, Vapor.io and others, local access to mobile networks is something that is in sole control of the network operators.

    Over the years, mobile network operators have built their networks in a highly centralized manner, whereas mobile end points “break out” to the Internet in a limited number of locations. This is primarily for the same reasons that Amazon AWS builds their data centers 50,000 servers apiece – to achieve economies of scale. To offer local, distributed IP access to their 5G networks, the mobile operators would need to distribute their mobile core networks by a factor of at least 10x.

    By hosting their footprint within mobile networks, Amazon checks off all three – local compute footprint, network interconnect to the edge, and IP network access.

    Something Old, Something New

    While the partnership is new and groundbreaking, for operators it takes a page from a familiar, tried-and-true operational playbook. The model of hosting compute footprint managed by Web-scale providers got its start with Content Delivery Network (CDN) service providers like Akamai. As Web-scale content providers like YouTube, Netflix, and Facebook have come to insource content delivery, they’ve also launched programs to host distributed managed cache appliances in the operator networks.

    The CDN market offers a few useful parallels that may help predict the evolution of the budding cloud-operator relationship.

    For one, expect the edge cloud footprint to fragment over time, as Amazon AWS competitors follow suit. Major edge cloud tenants (e.g. autonomous vehicle providers) may end up striking their own deals with operators directly, as they scale their edge operations to the point where public cloud intermediation no longer adds value.

    You can also expect a certain push-and-pull between cloud tenants and operator landlords on how the value is to be divvied up and how deep the public clouds will push into the edge networks.

    But maybe even more importantly, the CDN analogy highlights the shortcomings of the announced edge compute offering.

    Clouds At 5G Edge: What’s Next

    AWS Wavelength extends existing AWS compute and networking abstracts from Web-scale public cloud to the edge “as is”. Metaphorically, the AWS tenants now can move from their cloud mansion into smaller edge apartments, while using the same keys and familiar furniture.

    AWS Wavelength extends existing AWS compute and networking abstracts from Web-scale public cloud to the edge “as is”. Metaphorically, the AWS tenants now can move from their cloud mansion into smaller edge apartments, while using the same keys and familiar furniture.

    The public cloud tenants can assume that for all their purposes the bandwidth is infinite, the latency is zero, and there’s always more compute and storage to scale up and/or fail over – so any parts of the public cloud within same cloud availability zone are interchangeable.

    But none of these assumptions hold at the edge. Because bandwidth is finite, and latency needs to be managed at the edge, not all end points can be served from any cloud location anymore. Moreover, because the compute resources at the edge are finite too, one must account for an edge location outage and/or overload.

    Last, but not least, the edge presents itself to the application providers as a disaggregated footprint spanning dozens and dozens of locations – that they now need to manage themselves.

    Edge applications that involve running cloud native workloads across many distributed, unattended and unreliable locations cannot be deployed by using the same application architecture as in an Amazon data center, but just closer. They require a new type of infrastructure that offers network-level abstractions to both application end points and application providers, just like CDNs do for content.

    No meaningful adoption of edge cloud and roll-out of 5G applications would happen without it, and that is what we are hard at work to build at 2You.io.

    Learn more about 2You.io Edge Mesh.

    Leave a Reply

    Your email address will not be published. Required fields are marked *