Some six years before Amazon kicked off the cloud era with the introduction of its compute and storage primitives, there were companies rushing to roll out fleets of servers onto networks all over the world. The web as we know it today was in its infancy at that point, but even so the concerns were similar: performance, speed, latency – particularly where audio or visual media was concerned.
The response was Content Delivery Networks, perhaps the most visible of which was the dot com darling Akamai. Over the past twenty plus years, CDNs like these pushed to spread their networks far and wide, to get points of presence ever closer to literally any potential internet user in the world. The goal of CDNs, historically, has been to make sure that any given piece of content is as geographically close to you as is practically achievable.
Having been constructed to deliver content, the CDN networks were typically wide but shallow. This was a contrast to the IaaS players, that tended be more narrow, but deeper in the functional sense. The former was a specialized wide area network optimized for a single purpose, the latter was more accurately characterized as regionalized seas of vast general purpose computing power.
Over time, however, the principles of convergent evolution – in which unrelated organisms evolve similar features in response to environmental pressures – have gradually been driving these two fundamentally dissimilar approaches towards one other. A wide gap remains, of course, and no one is likely to mistake a CDN player for a hyperscale cloud vendor, though notably the reverse is not true.
But with the demand for CDN capabilities robust and constant, all of the major cloud services have launched their own native functionality (AWS CloudFront, Azure CDN, Google Cloud CDN) – though it should be noted that customers, particularly large ones, still generally prefer specialized providers for their CDN needs. The CDNs have also been facing competition from the hyperscale providers around static site hosting. Microsoft has not one but two entries in market in GitHub Pages and Azure Static Web Apps, AWS has Amplify Console and GCP has Firebase Hosting. They don’t receive the focus or attention that the specialist players do because they’re but one among hundreds of services, but the demand is clearly evidenced by the cloud provider offerings.
The CDN players, for their part, have over the last thirty-six months or so begun to expand from their delivery roots into execution, courting compute workloads for the first time. With offerings such as Akamai EdgeWorkers (introduced 10/2019), Cloudflare Workers (9/2017), Fastly Compute@Edge (11/2019), Netlify Functions (3/2018) or Vercel Now v2 (11/2018), the CDNs have begun to slowly make their way back down the stack to compute – or in cases like Vercel were already there and pivoted slightly, though not in the general purpose arena but most commonly the relative greenfields of serverless computing. Other players such as StackPath are more directly targeting the intersection of the two, by offering services that are broader and more general purpose than serverless but with distribution closer to that of a traditional CDN.
While IaaS providers introducing their own native CDNs was inevitable, CDN vendors emerging as legitimate workload targets would seem to be an improbable development in an era utterly dominated by the presence of massive, hyperscale cloud providers but for two developments.
- First, the introduction of AWS Lambda in 2014. As with the ascent of Node.js in late 2009 and early 2010, a lot of the initial reactions to Lambda following its introduction were consternation. It was distinct enough in its approach, that it was – and arguably still is – less approachable than other competitive platforms. But, again like Node, its merits have turned legions of skeptics into active users.
Lambda is important to the CDN’s emerging runtime ambitions because it, in part by virtue of AWS’s size and dominance, singularly reshaped the definition of what an “application” was and how it was hosted.
The platform progression over the years has been towards smaller, ever more composable atomic units. Mainframes gave way to client server, client server gave way to virtual machines, and virtual machines in turn have been deposed, in certain areas at least, by containers. The applications, for their part, were large, usually written in Java, comprehensive in their functional scope and run around the clock.
In the post-Lambda world, applications of that class have no server or even container exposed to the user, typically, and the applications are decomposed into functions that run only when called upon. Which is why enterprises all over the world are getting as creative as Tik-Tok users in how the platform can be bent to serve a wider and wider array of use cases.
On the one hand, this is bad for would be serverless competitors because it has led to more of a direct association between the terms “Lambda” and “serverless” than would be AWS competitors would want. But at the same time it creates market permission for serverless vendors of all shapes and sizes to have conversations with customers about serverless as a platform in ways that would have been difficult if not impossible prior to AWS’ introduction of the service.
-
Second, the rise of Static Site Generators and their gradual expansion into application territory via the JAMstack concept. If you’re interested in the subject, my colleague has an excellent primer on both the history of the category and the current trajectory of some of its defining projects. The short version is that static site generators are a means of ingesting barebones text files authored in Markdown and outputting a website. JAMstack, which stands for the JavaScript/API/Markdown-stack, meanwhile, extends these core capabilities by allowing static sites to invoke back end services and dynamically render them for delivery.
For many years, as mobile developers have been aware, much of the heavy lifting for applications has been outsourced to server side applications. From authentication and authorization to geographical lookups to calls to back ends for account management, inventory and countless other core business services, thanks to APIs the front end requires very little intelligence – just the ability to adjust the delivery and presentation layer dynamically. Which is what the JavaScript is for.
What the JAMstack represents, therefore, is an application style that while clearly not suitable for every application type, is increasingly versatile and offers advantages that range from concrete to theoretical with respect to everything from speed to security. Enterprises can increasingly look at the JAMstack and conclude that it could easily have a role, and potentially a significant one, in its application delivery portfolio.
Which is nothing but opportunity for JAMstack players; small wonder that Netlify is responsible for the term. The combination of the emerging serverless products and the innate capabilities of the various CDNs to host JavaScript, API and Markdown driven applications begins to position CDNs as a target not just for last mile delivery of hashed content but as a first class destination for a sizable and growing subset of enterprise application workloads.
One way to read all of this from the CDN providers’ perspective is serendipity; a unique and unrelated set of market conditions that appeared just in time for CDNs to expand the addressable market beyond their original roots. Another way to look at it, however, is necessity. The CDN providers may be technically preferred at present, but the market has demonstrated conclusively that the appetite of the large scale infrastructure providers is limitless. If enough of the latter’s customers want a service, the hyperscale providers will supply it, one way or another – and those services will improve over time, as will their reach.
Which leads to an obvious question, which is whether this convergence will lead one or more of the largest cloud suppliers to conclude that inorganic growth via acquisition is a more efficient means of growing share. This, in turn, explains why the expansion into application territory cannot come quickly enough for the CDN players. It’s important because they’re facing increased competition from the hyperscale providers, but more because it’s the shortest path towards increasing their own market value. It would be difficult, at this point, for CDNs to move the needle from a market perspective by being a wider or more distributed network. A CDN that is able to parlay its initial investments in a global network into a compelling serverless and JAMstack emerging application style story, however, is another matter entirely.
Betting that a major cloud provider will acquire a major CDN is something of a risk, because the clouds have, with exceptions, been much less inclined towards M&A as a means of market growth than the dominant technology providers from past generations. It is safe to conclude, however, that those CDNs that can successfully execute and deliver an application platform on top of their global networks, even if that application platform is specialized, will be far more valuable for the exercise and better positioned for the competition ahead.
Disclosure: Amazon, Cloudflare, Fastly, GitHub, Google, Microsoft and StackPath are RedMonk customers. Akamai, Netlify and Vercel are not currently customers.
