Explore insights on real-time edge computing, AI, and cloud solutions. Learn how our technology optimizes performance across industries.

Blog

CDNs have been an important cornerstone of Internet infrastructure for the past two decades. By storing and serving popular static content (video, pictures, static web code) from close proximity Points Of Presence (POPs) to users around the world, CDNs have made the Internet usable by de-centralizing and distributing some aspects of the highly centralized architecture of the Internet and the applications that run on it.

The web has of course not stayed static. Web content has become increasingly dynamic, as users expect instant and personalized experiences while using any kind of web or mobile application or service. Delivering personalized content to users requires that significant parts of the content shown by the web application or sites are dynamically assembled - just in time - by looking up things like the user's preferences, history, interests, social connections etc. While we stare into our screens and jump from one click to the next, there's a complex ballet conducted behind the scenes where a co-ordinated dance of services do things like look up databases to fetch your data, analyze the data to extract insight to recommend what song to listen to, what movie to watch or what to buy.

CDNs unfortunately seem to be getting smaller and smaller parts to perform in this dynamic ballet.

 Since CDNs can't handle most types of dynamic content (i.e anything that involves a look up of data or state from a database or a key/value store), they essentially act as bumps on the wire that forward the request to the origin where code and databases work together to perform the numerous lookups, transformations, aggregations and code generation that power modern web applications. (authors note - it is another matter that CDNs have been forced to focus on areas like web security, application firewalls, DDOS protection etc to stay relevant and rightly so. It is analogous to an over the hill ballet dancer now moonlighting as the usher or bouncer at the theater because they are not important to the show anymore)

So why can't CDNs handle dynamic content?

The answer to that is dynamic content requires the storage and manipulation of persistent state (data) at the edge. Most web applications need to store the data that users create or manipulate them somewhere. This somewhere is usually a database like MySQL or Postgres or Oracle. Sometimes they are NoSQL databases like MongoDB or Cassandra, and other times they are cloud databases like Google Big Table or Amazon's DynamoDB. Almost all these databases centralize the web applications data i.e. they put it all in one giant pile in one of their regions or data center locations and every single request to create, lookup or change that data means that your web application has to send a call to that database in that one location where its stored and processed by the database.

Now CDN's can't help here because they cannot cache the contents of the database on their POPs since this data changes very frequently. CDNs run into a classic old distributed systems problem called cache coherency, i.e. keeping a local copy of the data in sync with changes that might be happening elsewhere.

Now there are lots of viable ways to address coherency and certainly using an eventually consistent (or never consistent) database will work for some situations (lots of reading with low frequency of update or that it doesn't matter if the data differs slightly between two copies of the data) but they fall short in situations where a lot of data is written or changed frequently. Almost all these approaches are designed to scale a database out within a datacenter and not across data centers over the WAN or internet because WAN and internet latency is high and network routing is unstable and unpredictable.

CDNs have a very different architecture - for one they are inherently a distributed infrastructure where the CDN service stitches together hundreds of locations into one content acceleration service. Users access their data from anywhere and the CDN secretly serves the data from the POP or location closest to the end user. This means that they don't run in one location - they run in hundreds of locations all at once. Therefore conventional databases don't work to solve the dynamic content look up and generation problem since they only run in one location (and CDNs run on many) and they need a very different and special kind of database. One that is designed to run across all the POPs or edge locations all at once and somehow keep all the copies of the data in sync as it changes across all these edge locations, allowing a user to access or change data anywhere, and the location closest to that user can handle the data operation.

Technically speaking we are describing what is called a 

 system that can work as one logical database across at-least a few hundred locations (ideally across thousands but that is for another blog post in the future) while keeping hundreds or thousands of copies of the same data on different servers in sync with each other, as fast as possible and while providing adequate consistency guarantees of the state of the data. Consistency means resolving what data operations happened (create, update, replace, delete), in what order, by whom and then somehow, every copy of the database arriving at one single version of truth after syncing their latest updates with each other.

As an example, such a mythical database would let a user in in Tokyo change a particular item in the database and it would automatically propagate the change to a hundred other locations while handling any situations where someone else (such as say in Boston) might have changed the same exact item to something different (while the user in Tokyo was also changing it) and doing this sync as fast as the network latency between the two locations will let it.

In short, this kind of a mythical database doesn't exist* and therefore CDNs can't handle dynamic content that involves looking up state.

3rd party independent CDN vendors are confronting an existential threat - public cloud providers are now integrating and delivering CDN capabilities with their own offerings. Cloud providers have a distinct advantage as the origin servers (web server, application logic, database etc) are already running

on their clouds (albeit in a centralized fashion and in one location chosen by the customer) and therefore providing a CDN at the edge is a simple extension for them. More worrying is that AWS for one, already has the ability to run simple apps as serverless functions at the edge on its CDNs with 

. If a customer is willing to roll up her sleeves, has a million dollars or more to experiment with, and is ready to hack at it for six months with a few senior database engineers hired from places like Facebook or Google (hence the million dollars), she might even be able to roll her own dynamic 'content at the edge' solution using AWS DynamoDB's global tables to get some shared data state replicated between regions (albeit limited to 5 regions which is the maximum number of regions supported by global tables - not particularly useful as a data base for CDNs that serve hundreds of global locations).

But CDN vendors have their own strategic advantage - deep capillary networks already in place unlike cloud vendors. Like capillary blood vessels distribute blood from the arteries to even the smallest, most distant parts of the body, CDN vendors distribute content from origin servers to the most distant and remote locations. While cloud vendors boast of having a dozen regions worldwide, typical CDN providers have hundreds of POPs around the world where they run their servers and systems for content delivery and web security. That is a huge advantage for CDN players if they can leverage their deep capillation infrastructure to push not just static content but dynamic data, server side application code to the edge. That now brings the most vital parts of the public cloud to the edge itself and creates multiple scenarios where the need to go to the public cloud to serve dynamic content are eliminated. That is revenue that used to go to the public cloud - now flowing to the CDN provider instead.

The broad global footprints of CDNs along with technology that enables data and dynamic code generation at the edge is a strategic moat for CDN operators. And if they push ahead to this new and exciting frontier of database and dynamic code on the edge - the sky is the limit for their edge clouds.

Public Cloud Is The Apex Predator Of The Internet - CDNs Need To Evolve To Stay Alive

Over the course of the last couple of months, I've had the opportunity to talk to senior leaders in major telecom companies in North America and Europe. In almost every conversation, I'm reminded of the myth of Sisyphus, the Greek king of Corinth, who, because of his deceit, was condemned by the gods to push a large rock up a steep hill, only to see it roll back down again when he got it to the top, and to repeat the same task endlessly till the end of time. Like Sisyphus, telecom operators seem condemned to an endless task of investing magnificent sums of money in bigger, faster pipes with denser capacity, to bring new services over their networks to their customers, only to see it all roll down the hill when Over-The-Top (OTT) providers swoop in with their apps and commoditize the telecom network to just bit pipes and take revenue directly from the end users bypassing the telecom provider entirely.

So what is OTT? Simply put, OTT is telecom parlance for any online service you use over the network of your internet service provider (ISP), whether cable, fixed line or wireless (on your phone or on your computer). Most of us already use OTT services like Netflix, Hulu, YouTube, Spotify, WhatsApp, Skype, iMessage, and Facetime without actually realizing it. OTT services built on cheap, elastic public clouds deliver voice, messaging, and streaming audio/video content directly to consumers over the internet, and are dominating the media and telecom markets today. In core telecommunication services, messaging and voice apps like WhatsApp, Viber, and Apple’s iMessage account for more than 80 percent of all messaging traffic on their networks, while Skype alone accounts for more than a third of all international voice traffic minutes (and is the world's largest long-distance voice provider). This pattern has led to steep declines in the average revenue per user; with minimal revenue growth; and ever-tightening margins for telecom providers in their core business.

With data, the story is even more frightening (especially if you are a telecom executive or shareholder). Almost every telecom operator, whether wireless or wireline, has been pushed to become just another bit pipe provider. Almost 70% of the data traffic of a telecom provider is video content coming from OTT services, like Netflix, YouTube, or social media. And it’s a perfect catch 22 situation for the telecom provider: either provide a fast bit pipe to keep your customers or see them go to a competitor willing to live on thinner margins. What makes OTT a particularly challenging contender to deal with is that it’s built on the public cloud and thus enjoys a very strong set of economic benefits in being able to scale up and down without the need to own any of the infrastructure needed to deliver the OTT service. OTTs are just one of the many manifestations of the disruption that the public cloud has created in telecom providers’ core business by enabling applications to be built cheaply and quickly with little to no dependence on the underlying infrastructure.

To remain relevant in this hyper-disruption unleashed by the public cloud via OTTs, telecom providers need to identify new growth areas that combine the great potential of a brand new addressable market and telecom providers’ existing core competencies. Edge computing sits squarely at the intersection of these two criteria, and telecom providers who embrace it could possibly end up successfully surfing the tsunami unleashed by OTT apps and services on top of cheap public cloud computing.

 that edge computing has the potential to eclipse what we call cloud computing today: a centralized architecture built on hyperscale data centers located in places with access to cheap and abundant power and, conversely, far away from most humans and devices and therefore unfit for emerging applications that need low latency, that process large data streams in real time closer to the data sources, or that have bi-directional traffic (instead of just downstream cloud-to-client traffic patterns). Edge computing, unlike the public cloud, will be built on either infrastructure owned by telecom providers or on new bespoke microdata centers with direct access to Radio Access Networks (RANS) (like 

Vapor IO's incredibly exciting vapor edge offering

) in dense urban environments where most humans and their devices are within 50 ms of latency.

Turning the Edge into a strategic weapon against public clouds and OTT apps

To succeed with edge computing, telecom providers need to co-opt application developers away from public cloud platforms to using their edge platforms to write future applications and to pre-empt OTTs from commoditizing their next generation infrastructure.

These edge native applications can then be delivered as managed services by the telecom vendors themselves, creating new revenue streams and competitive moats to fend off the threat of public clouds and OTT apps and services.

Co-opting the developers away from public clouds will not be an easy problem and will require telecom providers to solve three key technology challenges, either by acquiring or partnering suitable software providers:

: The edge, unlike centralized hyper-scale data centers, is a geographically distributed and massively decentralized infrastructure (with no single locus of centralization) and at its core is a massively scalable decentralized and distributed database. Today's distributed database and storage systems are not sufficiently scalable to solve the data consistency and consensus when running across thousands of distributed nodes as a single logical programmable database (I plan to make a future post to elaborate on this aspect).

: The edge must be programmable like a public cloud by offering a Container or Platform As A Service (CAAS/PAAS) abstractions for application developers to work with while hiding the complexities of the distributed architecture across apps running and storing states on tens/hundreds or even thousands of edge nodes. This is the central technology problem that will need to be unlocked to truly turn edge computing into a mainstream offering and a contender to take on the current model of centralized public clouds and OTT apps and services that run on them.

: Telecom providers, by their nature, are regional and don't operate globally the way public cloud providers do (due in part to the legacy of deregulation and licensing of the spectrum). Therefore telecom providers will need to form one or more global alliances to provide one contiguous global service across networks for edge computing and to hide the complexities of disparate networks and infrastructures from end users. The good news is that the telecom providers already have deep expertise in this: global roaming, for example, is one way that telecom providers currently provide seamless voice and data connectivity across national boundaries for their subscribers.

Bringing together such an edge cloud architecture that tightly couples (1) a globally available database with (2) a rich CAAS/PAAS platform in (3) a global federation of edge clouds stitched together to provide data and code mobility would enable telecom providers to provide a true alternative to public clouds for app developers, but with the benefit of allowing applications to run in very close proximity to end users and devices—an advantage that hyperscale centralized public clouds will find very hard to compete against. With such a combination in place, telecom providers would serve as the critical platform for the complex data flow that links machine sensors to back-end services, in real-time analytics or cybersecurity, and the transportation supply-chain infrastructure to navigation, factory floors, social media, online multiplayer gaming, and autonomous consumer and business logistics apps (such as self-driving vehicles). Machine-to-machine revenues are projected to grow by double digits over the next few years, so they could potentially create massive new revenue streams in areas that are core to telecom providers and provide new greenfield opportunities to build and fortify activity away from public cloud providers and their OTT offerings.

But let me end this post by pointing out the obvious: the edge is too important for telecom providers to ignore. In the previous innings of the cloud game, everyone (including yours truly) underestimated the potential of the public cloud to change how we consume media and apps, and was taken by surprise at how quickly it went mainstream as an application development platform and created brand new billion dollar OTT businesses while rapidly commoditizing and disrupting so many incumbents (I will spare you the recanting of various tales, such as Blockbuster vs. Netflix or WhatsApp vs. SMS). Telecom providers cannot afford to make that mistake with the edge. It's now the proverbial bottom of the 9th innings, the bases are loaded, and the telecom providers are at the bat—it’s anyone's game to win.

Telecom Providers Need To Win The Battle For THE EDGE To Be More Than Just Data Pipe Providers

I recently had the pleasure of sitting down with the smart folks at GSMA, to share my take on how edge computing will evolve for their global mobile radar report (you can find a copy of the material from the report below). Edge computing and its step-sibling, "fog computing", are shrouded in the excitement and mystery of a new frontier, where trillions in a new addressable market will open up: and makers of digital picks and shovels are busy lighting the hearth of their software-defined forges, to design and build the edge infrastructure of tomorrow. Bold predictions are being made about the disruptive new applications that edge computing will unleash on willing and supplicant enterprises and consumers, who will lap it up unquestioningly with the hyper-energetic enthusiasm of your average, lovable, but slightly dim Labrador retriever.

It's my rather controversial view that the edge will, over the longer term (10+ years), eclipse what we call the cloud: the giant centralized hyper-scale data centers, which offer a progressive set of abstractions as a service for running applications and storing data. These hyper-scale data centers are built on a simple zero-sum premise: whatever money you have in your budget, Amazon Web Services (AWS) will take it all by trading off your desire for simplicity against cost. Jokes about AWS aside: the cloud is a becoming a horrible place to compute. Its too far away from the most interesting things that are happening around us. It's too slow to react to change in the real world. It's too picky about what data structures it wants to eat and needs everything to be batched into giant balls of columnar data for it to map-reduce on.

The edge, on the other hand, is right next to where the action is. It's already in the densest urban areas where 83% of humans and their devices live, and where commerce happens. Its there for metro data centers, cellular base station controllers, and radio network controllers and milliseconds away from your phone, drone, car, game console, and 3D-printing robot. The challenge is that the abstractions that serve us so well in building and running applications on the centralized clouds don't work well (or at all) on the edge.

Edge Computing is a Distributed Data Problem

Edge computing is a distributed data problem

 (and not simply a distributed computing problem that spinning up containers on the edge will solve). Data (or state, to be more precise) is a pain in the *** (PITA) and our most advanced technologies for storing and processing data are built around models and architectures of centralizing it. If you can take your data (state) and make giant piles of it in one data center, it's easy to do useful things with it: but, if you have a little bit of it spread everywhere, there is a horrendous problem of keeping everything consistent and coordinated across the locations that its stored on, so that you can achieve idempotent computing. For edge computing to become a reality, the distributed data, at large scales, must be solved. Once this is solved, we will see the edge eclipse the central cloud, to become the place where the world computes.

, at a very large scale, for the edge is a killer opportunity for edge computing (planet-scale where multitudes of edge locations around the world act in concert to provide a single coherent database). Being able to create an edge database with thousands (if not tens of thousands) of edge nodes that are able to achieve real-time consensus, provide idempotent computing across a multi-home, multi-master architecture is the holy grail, and, once that is solved, everything changes. There will no longer be a need to build massive piles of data in one location to compute on it, as you can move the compute to wherever the data is being created to unlock value from it.

Solving this challenge creates a progression of advancement in four phases.

In phase one, we see edge applications being deployed to solve esoteric use cases which central clouds simply can't solve.

In phase two, we start to see hybrid edge and central cloud apps, where speciation and specialization emerge for things that are currently being done in batches in the central clouds or in real time in the edge.

In phase three, we see the rise of native edge apps, where traditional "

" apps are rebuilt to take advantage of the versatility of the edge, to create revenue streams from new services that only the edge can provide.

In phase four, we reach a point of parity, where most apps are edge by default and the centralized cloud is the secondary tier for computing, much like how tape backup is for storing and archiving data.

I'll end this post with a cautionary note on the dangers of "edge washing":

The edge is not a simple re-skinning of what worked in the cloud. If that were the case, the edge would already be here.

Running code in containers on an edge device, like an IoT gateway or a metro data center, doesn't solve the distributed data problem because it does not unbundle state and make it distributed.

Calling something "real-time" doesn't make it real-time unless the edge platform actually schedules processing with guarantees and prioritization of requests.

But, most importantly, the edge is a distributed data problem: no matter how much one wishes that cloud architectures will generalize to the edge and that it's simply a question of getting your containers to run on the edge, it's not.

A Controversial Take On Edge Computing

Macrometa is the hyper distributed cloud platform for enterprises building global applications at the Edge. 

PhotonIQ

Global Data Network

Learning Hub

Case Studies

Developer Hub

Demos

Support

About

Partners

Press

Careers

Contact Us

Terms of Service

Privacy Policy

Trust Center

Macrometa vs. Edgio

Are you an Edgio customer facing uncertainty? Discover how Macrometa ensures continuity and delivers high-performance solutions for your business.

Archive

Public Cloud Is The Apex Predator Of The Internet - CDNs Need To Evolve To Stay Alive

Telecom Providers Need To Win The Battle For THE EDGE To Be More Than Just Data Pipe Providers

A Controversial Take On Edge Computing