Cloudflare announced it is rebuilding its infrastructure, moving portions of it from native Linux services to its own Cloudflare Workers developer platform.

Cloudflare is one of the leading content delivery networks (CDN), used by companies in a range of industries. The company’s Richard Boulton said it originally built its platform on native Linux services, but outlined some of the challenges the company faced:

The structure of the code limits the ease of making changes. While some changes are easy to make, other things run into surprising limits due to the underlying platform. For example, it is not possible to perform I/O in many parts of the code which handle HTTP response processing, leading to complex workarounds to preload resources in case they are needed.

Deploying updates to the software is high risk, so is done slowly and with care. Massive improvements have been made in the past years to our processes here, but it’s not uncommon to have to wait a week to see changes reach production, and changes tend to be deployed in large batches, making it hard to isolate the effect of each change in a release.

Finally, the code has a modular structure, but once in production there is limited isolation and sandboxing, so tracing potential side effects is hard, and debugging often requires knowledge of the whole system, which takes years of experience to obtain.

Boulton says the company is taking a cautious approach to the rebuild, tackling those parts of its infrastructure that make the most sense to swap out:

Our systems are a lot more complicated than they were in 2013. The approach we’re taking is one of gradual change. We will not rebuild our systems as a new, standalone reimplementation. Instead, we will identify separable parts of our systems, where we can have a concrete benefit in the immediate future, and migrate these to new architectures. We’ll then learn from these experiences, feed them back into improving our platform and tooling, and identify further areas to work on.

Modularity of our code is of key importance; we are designing a system that we expect to be modified by many teams. To control this complexity, we need to introduce strong boundaries between code modules, allowing reasoning about the system to be done at a local level, rather than needing global knowledge.

The entire blog post is extremely detailed and a recommended read for anyone interested in better understanding the ins and outs of CDN infrastructure design.