Carcinization, CDNs and Clouds

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

Photo Credit: J. Antonio Baeza

Once upon a time, HBO and Netflix looked very different from one another. The former had content, but no independent delivery platform. The latter had less content, but a highly refined delivery platform. Interviewed in 2013, then Chief Content Officer Ted Sarandos said “The goal is to become HBO faster than HBO can become us.” Implicitly embedded in this statement was an assumption that principles of convergent evolution applied, the idea that a given environment will drive the “independent evolution of similar features in species of different periods or epochs in time” – which, as an aside, carcinization must inarguably be the single most horrifying example of. Sarandos may have made mistakes since then, but he was right about the direction of travel for both HBO and Netflix. Both companies now develop original content and possess the means to distribute it directly, all of which was predictable if only because the principles of convergent evolution would not allow for any other outcome.

Just as they continue to remorselessly drive the general purpose cloud and CDN providers towards one another.

When last surveyed in this space two years ago, the hyperscale cloud providers all had their respective CDN market offerings (AWS CloudFront, Azure CDN, Google Cloud CDN), while the CDN providers were still in the early stages of ramping up their compute capabilities (Akamai EdgeWorkers (introduced 10/2019), Cloudflare Workers (9/2017), Fastly Compute@Edge (11/2019), Netlify Functions (3/2018) or Vercel Now v2 (11/2018)). A great deal has happened since then.

While there has been some progress from the hyperscalers in expanding their CDN competencies – see, for example, AWS’ announcement about a CloudFront partner play, Google Cloud’s recent announcement of Media CDN or the deprecation of its original Azure CDN product in favor of a second gen Front Door – the most aggressive movement has come from the CDN vendors intruding into the general compute space. Consider the following moves:

  • The original possibility floated here was that one or more of the large cloud providers – based on their immense capitalizations – would augment itself with the acquisition of a CDN provider. Instead, Akamai, the CDN vendor, presumably at least partially in response to the lack of visibility for EdgeWorkers, went out and acquired Linode. One of the smaller tier, well regarded cloud providers along with competitors like Digital Ocean, Linode brings with it both raw primitives like compute, databases and storage as well as the kind of relationships with application developers that Akamai lacked. Acquisitions are hard and often unsuccessful, but on paper, if you have already have a world-class CDN business and want to play in the general purpose compute space, this offers Akamai the ability to get there much faster than if they had attempted to build that business themselves. Few businesses can iterate technically at the speed necessary to play in the general purpose compute market. Interestingly, one of Akamai’s competitors Cloudflare is one of them.

  • Of all of the CDN players, Cloudflare is the closest to AWS in its ruthless efficiency and ability to churn out new services.

Nor is it just RedMonk who thinks of Cloudflare in the same breath as AWS.

From Pages to Workers (which Cloudflare announced will be open sourced) to Pub/Sub to R2 to – most recently – the fascinating SQLite-based D1, Cloudflare has few peers in the industry in the velocity of its overall development. This obviates the need for an inorganic, acquisitive approach, but does put pressure on the company to ramp up quickly to meet the demand for customers in the far broader and more demanding mainstream, general purpose computing space.

  • Fastly, meanwhile, followed Akamai’s lead in its macro approach of inorganic rather than organic growth, but zigged where Akamai zagged. Whereas Akamai acquired a traditional supplier of mainstream cloud primitives, Fastly picked up Glitch – née Fog Creek – a higher level abstraction built to host web applications. This is an interesting bet for Fastly on two fronts. First, that in betting on an abstraction rather than primitives that they’re skating to where the puck is going rather than where it is today – unlike, say, AWS. And second, assuming that is in fact the direction of travel in the industry, that Glitch is the answer that that burgeoning customer segment looking for higher levels of abstraction is looking for. On the plus side, Glitch’s explicit and visible inclusivity in its approach and community building sets it apart in an industry that largely pays lip service to such ideals. On the other hand, however, Glitch’s current functional band is narrow: web, Node, React and SQLite. Popular projects all, but historically platforms that have been similarly constrained in the workloads they target – think Heroku – have mostly failed to go mainstream. This is, in part, what has dictated the approach that either large cloud providers have taken by embracing domain specific abstractions (e.g. Amplify or App Runner) or that startups like Render or TinyStacks are taking in trying to bring broader workloads to higher levels of abstraction.

The interesting thing to watch in all of this, then, is no longer whether the hypothesis of convergent evolution applies. To date, at least, the evidence in that direction is clear. The question now is whether and how the hypercloud providers will respond to these intrusions onto what had unambiguously been their turf. It will be some time before some if any of these CDN strategies have a measurable market impact for cloud providers, but if they don’t preemptively respond the price for doing so later can only become more costly.

Disclosure: AWS, Azure (Microsoft), Cloudflare, Fastly, Google, Heroku (Salesforce), Linode (Akamai), Render and TinyStacks are all RedMonk customers. Digital Ocean, Glitch, Netlify and Vercel are not current customers.

No Comments

Leave a Reply

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