Package Delivery Networks: How They Differ From CDNs

A crucial part of effective package management is package distribution. Whether you are dealing with distributed development teams, deploying a distributed application or even if you are a software vendor, you need efficient, performant and reliable delivery of your software packages or artifacts.

And for that, you need infrastructure. Lots of infrastructure.   To deliver software globally, at low latencies, you’ll need infrastructure in many regions, preferably as many as possible. There is no beating the laws of physics; it still takes a finite amount of time for packets to travel a distance, which means that the closer your users/systems are to where your infrastructure is, the better.

So, to accommodate all these distributed users and systems, you’ll need infrastructure in as many data centers or points of presence as you can, ideally co-located alongside or within internet exchange points, giving you the best possible network access.

No small task at all!

Enter the Content Delivery Network

A Content Delivery Network (CDN) is precisely that. It is servers and infrastructure at many locations globally which are used to deliver content quickly. Many websites and services use a CDN to deliver assets such as pictures, HTML and javascript files to users, without the request for these assets having to go back to the primary hosting infrastructure.

A CDN caches this content at the network edge; it doesn’t host it.  And typically, the CDN infrastructure has direct connectivity to internet backbones and exchanges, delivering these assets in the most performant way possible.

So instead of building out, managing and maintaining all this infrastructure yourself, you can use a CDN to distribute your software artifacts and packages, right? Yes, you can, but that’s only going to get you so far.

Why?

Well, software package management can be a “mucky” business.  Each language, OS, framework or platform has its own package format, client tooling, APIs and communication protocols.  It’s not unusual for a modern software development process to use many of these package types, which introduces the problem of managing all these different concerns.

Simply dropping a CDN in front of your package hosting will not accommodate all these differences effectively. It may help, but it’s not optimal. Distributing packages to client tooling is very different from distributing JPEGs or HTML via plain old HTTP.

This is a problem.

Introducing the Package Delivery Network: a CDN evolved.

It’s a problem that Cloudsmith was built to solve.   From the beginning, Cloudsmith was made with package distribution in mind.  We don’t believe that package distribution is a different problem from package management – it’s an essential part of it.

The ability to efficiently distribute software artifacts globally is a fundamental core component of effective package management.  It’s more important now than ever, with the rise of distributed teams, working from home, and distributed cloud-native applications.

It’s simply no longer acceptable that your geographic region determines the performance of your development, deployment, or commercial distribution processes.  The world has moved on, and we need to adapt to keep up.

And that’s where the Package Delivery Network (PDN) comes in.

So, what is it?

Well, the TL:DR is that it’s a highly customized CDN. It’s a CDN that is specialized in the delivery of software artifacts.  It knows that it is serving software packages, it’s context-aware, it’s not just blindly serving assets and treating them all as equals. It’s an intelligent CDN.

A primary example of this is our edge caching rules feature.

Edge Caching Rules

The first benefit of our package delivery network is that your software packages and artifacts are cached at the edge, reducing the need to retrieve them from primary storage locations and then deliver them to the consumers.

Of course, that’s great that your artifacts and packages are cached at the PDN edge nodes; it’s straightforward to understand how that can improve performance.  But what about control? Who decides how this caching is performed? What level of caching do you need? You are best placed to make these decisions, and edge caching rules give you the ability to do so.

You get to define the Time-To-Live (TTL) for packages cached at the edge, and you can cache packages and metadata differently. Maybe you want a very short TTL for something frequently updated, like a Maven snapshot repository. Conversely, you can set a very high TTL for packages that infrequently change, perhaps a new software release or update.

And you can do this on a per-package-format basis as well – as we said previously, the PDN is context-aware.

Also, thanks to the continued improvements in CDN offerings, we can now run some of our application logic directly on the CDN edge nodes themselves.  This effectively means that Cloudsmith, as a distributed cloud-native application, is distributed right out to the network edge.  Our code can run next to our users and across all the CDN points of presence, giving us greater reach than would be possible with multiple cloud provider regions alone.

This goes above and beyond the basics of caching software packages and metadata at the edge nodes and has brought particular benefits, like authentication at the edge (among others).

Auth at the Edge

Securely storing packages and controlling access to those packages is of paramount importance. With the focus now on software supply chain security, you must ensure that your package repositories are secure and tightly controlled. Private repositories and reducing your reliance on public package repositories are an absolute must.

This brings us to the issue of authentication. Now, authentication in and of itself may seem like a solved problem, and in many ways, it is.  What changes things is scale. The problem again is the globally distributed nature of the package use. You need to handle authentication requests from users and consumers anywhere and still deliver the same performance for all.

Some package protocols are extremely “Chatty” - NuGet and Maven, to name just a couple.  Authentication requests and responses can add significant overhead if they need to be routed back to infrastructure in a cloud region.  At Cloudsmith, we handle this authentication “at the edge”, with application code deployed to the edge nodes.

This significantly reduces the round trip times for these requests, and the difference adds up with the more requests you have.

For example, If two users with different API keys request the same package and have permission to access that package, we can determine that at the edge node and serve the package directly from the PDN cache. No trips back to primary storage, no multiple auth requests back to other infrastructure.  Those milliseconds all add up at scale!

Summary

Modern software development and distribution processes require modern package storage and delivery methods.

Traditional CDNs have evolved, and secure package management solutions have evolved right along with them.

By taking advantage of the latest developments in CDN technology, Cloudsmith has developed a Package Delivery Network (PDN) - a highly customized, smart CDN specializing in delivering your software artifacts.

Gone are the days of blindly serving assets and treating them as equals.  As far as software artifacts are concerned, the PDN is here to stay.

Liked this article? Don\'t be selfish (:-), share with others:   Tweet