Interview with Stewart McGrath, CEO of


Modern web applications and content delivery requirements have changed considerably since content delivery networks first emerged. Agile development practices, DevOps, edge compute and new security requirements are all driving more sophisticated use cases for CDN, including multi-CDN and DIY CDN approaches.

However, these solutions are not without drawbacks. Multi-CDN strategies force their users to normalize CDN behavior across vendors, resulting in lowest common denominator capabilities and the loss of key benefits such as dynamic caching and advanced WAF solutions. In addition, DIY strategies can present even further difficulties for their users due to the difficulties associated with building and operating a global CDN. And while some industry players have insisted that it’s easier to build a CDN than scale it, this isn’t always the case. We’re now in the days of SDN, Kubernetes, Machine Learning, Quantum Computing, and scale-on-demand containerized CDN services. At least, this is what Stewart McGrath believes.

Stewart’s company,, operates a Content Delivery Grid, a software-defined security and web performance platform that allows users to choose the reverse proxies they use and integrate them with DevOps workflows. This allows companies to build and deploy multi-CDN solutions with sophisticated capabilities and centralized control. Recently, we had the opportunity to speak with Stewart about’s platform and its approach to contemporary challenges in the CDN industry. A big thanks to Stewart for all of his insight.

What is the difference between a traditional CDN and

When thinking about CDNs, for simplicity, we like to break them up into three broad elements: the Physical Layer, the Logical Layer, and the Control Layer. The Physical Layer is comprised of computers and networking elements that are distributed around the planet in datacenters and ISPs. The Logical Layer is the software running on these computers, which performs the functionality to receive, interpret, manipulate or serve the requests that might be sent to it. Generally, the logical layer will consist of reverse proxy software such as caching software, image optimization software, Web Application Firewall software and many more. Finally, the Control Layer consists of the elements that allow CDN users to manage, diagnose, configure and measure the reverse proxy software and other elements of the CDN solution, such as SSL certificate management, cache clearing, logs, metrics, etc.

Legacy CDNs have all been built with a tightly coupled physical and logical layer. Even the most recent CDNs to enter the market have approached the CDN landscape from a networking rather than software perspective.

However, tightly coupling the physical and logical layers results in two major drawbacks for legacy CDNs. First, they are production-only networks. This means they do not exist in development environments, so software engineers have to guess how the networks behave in production. Second, they are difficult to upgrade or extend. Each CDN has chosen one particular path with respect to the reverse proxy software running in the logical layer and they are locked into that software. For example, Fastly is built on Varnish cache 2.1 versus the current version 5.1.2 and spent approximately two years building a simple rules-based firewall into that proxy. is different in that we have leveraged container technology to decouple the physical and logical layers of the CDN.  Effectively, is an abstraction of a CDN.

What are the benefits of decoupling the physical and logical layers?

With respect to the Logical Layer, publishes a library of reverse proxies from which customers can choose.  Customers of are not locked into one type of reverse proxy or indeed one version of reverse proxy.  They can make up a logical layer which suit their application at that particular time.  For example, a customer can choose to run Varnish Cache 3 on or the latest version 5.1.2 and when version 6 is available, a customer will be able to choose to upgrade if and when they prefer.

With respect to the physical layer, PoPs can run effectively anywhere a virtual machine can run. This includes major cloud providers such as AWS and Azure or inside the firewall at Enterprises or even on developer machines as part of the software development lifecycle. Customers can build bespoke or multiple networks and software engineers can tune and test the CDN in their development, test and staging environments.

Can you explain how abstracts the CDN from physical and logical and how this new solution works?

That is covering a bit of our secret sauce, but essentially this is about the orchestration and management of containers running reverse proxy workload. To run a reverse proxy workload in containers on federated compute, we need to achieve a number of elements:

  1. Direction of traffic to the appropriate PoP which can execute workload for a particular HTTP request
  2. Propagation of each customer’s defined container configuration to each specific network of PoPs relevant to that customer (note this has to happen in seconds not hours)
  3. Management of the chaining of chosen containers for each customer
  4. Messaging into each container for runtime execution of Control Layer commands such real time cache clearing in the case of Varnish cache or IP whitelisting in the case of WAFs etc
  5. Scaling, health and availability of the infrastructure and container workload
  6. Extraction of HTTP logs and diagnostics from every container to present to users in real time
  7. All of the operational management tooling for a federated compute network  

It seems your platform is similar to what SDN is doing in the telco industry. Would you say that’s accurate?

It would be quite reasonable to translate some of the SDN principles to what is doing in the content delivery space.  For example, the concepts of Open Architecture, Centrally Managed Abstracted Control and Programmatic Configuration of the network are all very consistent with the approach.

In the same way SDN has gained traction to support the dynamic, scalable compute and storage needs of today’s applications,’s new approach to content delivery means we directly support modern agile application development practices, DevOps principles and and the more complex web application security, scalability and performance requirements which now exist.

Could you describe a typical customer setup for us? With a big customer, how many containers are running and what features are deployed?

Our customers run a wide variety of compute configurations to suit their particular application needs. We have customers running on global networks or single PoPs subject to their traffic requirements.  

Customers are running optimization proxies (such as Varnish Cache, PageSpeed or Nginx with LUA) and/or security proxies (such as Threat X, ModSecurity or Signal Sciences) in a variety of configurations. It is difficult to describe a typical customer configuration as customers are running so many different options. We do see more Varnish Cache being deployed than other proxies, but even then we have customers running different versions of Varnish Cache to suit their particular application requirements or their VCL capabilities.

The number of containers running at any one time for a customer will vary subject to the volume of traffic being received for that customer’s application or applications.

Many organizations are now interested in operating a Multi CDN and/or a DIY CDN. Do you help with the operational aspects of the platform?

Most of our customers currently choose to run their container workload on the compute infrastructure we manage, so they rely on the team to manage the operational aspects.

Moving forward however, we know that customers have been especially challenged with operating an effective Multi CDN for complex web applications as they search for increased CDN reliability and performance. As users leverage’s platform, they will be able to build their own Multi CDNs from disparate infrastructure but with a common control layer which includes all the CDN operational control elements. will empower enterprises to benefit from using the right edge compute or reverse proxy software for their application and having common configuration of that software, even in a Multi CDN solution. This means they can develop sophisticated caching, optimization or security configurations, deploy those configurations seamlessly onto their Multi CDN and still retain centralized control. Hence, consistently deliver faster, more scalable and more secure applications.

Scroll to Top