DIY CDN – Friend or Foe

We are witnessing a hyperconnectivity era with everything and anything pushed to the Internet to take advantage of its broad footprint. Users are scattered everywhere and they all want consistent service independent of connected device or medium. Everyone has high expectations and no one is willing to wait for a slow page load or buffered video. Nowadays, service performance is critical but are today’s protocols prepared for this new age of connectivity?

The old protocols of the Internet are still in use today. Yes, there are tweaks and optimisations in an attempt to match current conditions, but the base mechanisms are the same. As they were never optimized since inception, it’s always going to be a cat and mouse game when it comes to performance. If protocols were initially optimised for long RTT, we wouldn’t have some of the application performance problems we see today.

IP is a simple protocol, consisting of only a few fields. However, the TCP applications that run on top of it are very advanced, some requiring strict performance metrics to operate at peak levels. The content that is carried for the application is no longer tied to single area deployments. More often than not, we have dispersed server and user base locations, creating performance challenges as to how content is optimally served.

So now we have high expectations and performance requirements from a variety of locations; however, the Internet is an unreliable place with unpredictable asymmetric patterns, bufferbloat and many other performances related challenges. So how did we all get here?

WE CAN’T CHANGE THE SPEED OF LIGHT!

The foundation of the Internet was based on the principle that everyone could talk to everyone. The original vision was universal reachability; networks were classed as equal citizens. There was an element of trust, and performance was never too much of an issue. We moved to segment networks by putting clients behind Network Address Translation (NAT) devices and a class A-B citizen design relationship emerged; the client-server model.

Throughout these movements, the role of the Internet stayed the same; connectivity regardless of location. With this type of connectivity model, distance and physical proximity plays a significant role in application performance. Over time, connectivity models change, but one thing engineers can’t change are the laws of physics. The closer to content, the better performance the user experiences. The days of having all content in the same location, while an attractive option from a data management perspective, from a performance perspective, would satisfy only a small proportion of customers. Dispersed users with content in one location does nothing for anyone.

Users on the other side of the planet to their content will suffer regardless of buffer sizes or other device optimisations. Everything is stuffed into HTTP that rides on top of TCP. However, TCP is chatty with a lot of back and forth communication inadequate for serving content. Long RTT are experienced as packets go back and forward many times before actual data transmission. Caching and traffic redirection are used on the long distance links but have limitations. The only real way forward is to move data right under the user’s nose.

Not all content is pushed to the edge, only content that is most used. CDN have a similar analogy to that of a user going to a library or a bookstore. One goes to a bookstore to buy a particular book; if it’s not there the bookstore owner can order it. There is no need to go to a library if you know which book you want.

Similarly to the operations of a CDN, if users requests require a piece of content not cached, the CDN network fetches it. This style of networking offers an entirely different perspective to connectivity. Instead of a simple universal reachability and connectivity model where everyone speaks to everyone, we are now looking at intelligent ways to deliver content close to user locations. The money on the Internet is taking a shift from transit to content providers, and we are experiencing a lot of cross network communication flowing through CDN providers. If you want to move 200GB around a network, then a CDN is the way to do that.

For optimised content delivery we need a CDN. There is no doubting this as there is no other way to delivering content closer to the user. And as much as we would like to we can’t control the speed of light. So the next question becomes, how do we go about doing this?

ARGUING BUILD VS BUY

There is a lot of misconception regarding the best way to implement a CDN. Is it better to build or buy from a trusted source? The availability of open source and the variety of cloud providers should enable quick and cheap engineering, right? These days it’s easy to build a CDN. But this wasn’t always the case. Just turn the clocks 10 years ago to the physical world of networking.

The traditional world of physical appliances presents a significant barrier for a global footprint build phase. CDN builders require vendor specific appliances for firewalling, load balancing, and other network services. PoP locations require a costly and time-consuming physical build, not to mention the human element necessary to engineer all of this.

Back in those days, it was expensive to build any network; most often, venture capitalists were required. There was plenty of vendor lock-in, and open source was not too much of an option. Networking was static and lacked any agility.

It became easier with the push for open source products and x86 platforms. The birth of virtualization gives rise to the Virtual Machine (VM) and virtual appliance in VM format enable Network Function Virtualisation (NFV) environments with the ability to chain services. The cloud allows ready-made low-cost data centres.

Simply install your VM’s in different cloud provider high-availability zones, implement Varnish, deploy Pingdom and GTmetrix for monitoring. Now, we have the capability to turn up a CDN in under an hour at very little cost. To build a CDN these days takes a little time and engineering skill, but the misconception is that everyone thinks the building is the hard part! This part is easy.

In these trying Internet times, it’s harder to achieve what you initially set out to do when you first built the CDN. If you’re not careful, you will end up with a CDN that performs worse than content stored in a single location. The cost of cloud VM’s is practically nothing, but you will also require an outsourced traffic management solution requiring new relationship touch points and at a cost.

The most challenging part is not the build phase, but the operation and monitoring side of things. What do you do if your CDN is not performing well? How do you know? And who is responsible? – this is the hard part.

WHAT MAKES A SUCCESSFUL CDN?

It’s not about the build and buy phase; it’s all about running one. A CDN is a serious technological infrastructure investment that needs care and feeding. To make a successful CDN you need an experienced operations team with the right monitoring, so when something goes wrong, it’s detected and fixed.

Performance related goals must be set for the type of content you are serving. These metrics are only derived from sound knowledge and history of working within CDNs. This is key to operating a successful CDN. If you don’t have performance goals and aren’t measuring performance, why are you trying to build a CDN? If you want to be faster than everyone, then how much more faster? And more importantly, what steps do you take when you are not reaching performance targets?

CacheFly has been in operation for 12 years. That’s a long time to focus on one technology set, the lessons learned are priceless to an operations team. This type of experience gives you the power to make the right decisions. Through various CacheFly customer engagements and hands-on Internet knowledge has led them to focus on core technology sets, making them the leader in that class.

CacheFly’s promise is superior performance all the time with 100% availability. To achieve this, they have made core technology decisions and stuck to them. They don’t spread their operations and monitoring departments to implement every optimisation available instead focus on static content, performance and 100% reliability.

STREAMLINED OPERATIONS

Any sized CDN will have plenty of monitoring and backend systems used for the technical representation of their network. These could either be open source or commercial based platforms. Commercial based tools are expensive to buy, requiring recurring costs and relationship touch points. Many that build a CDN as part of their overlay network may have to choose a combination of open source tools that only fulfil a subset of functionality to that of a commercial based platform. Each tool may also require a different skillset and engineer.

What makes a successful streamlined operations department is the full integration of these tools and the automation around the process. Is the billing system fully integrated and does the billing start at the correct time – by activations and not order date? A single call from a backend system should signal device provisioning/changes and all these should be fully integrated with all other systems for better operations.

If you build a bespoke CDN, many operational duties operate with a manual approach which is cumbersome and time-consuming. Instead of having a manual approach requiring human intervention, all process such as billing should be integrated as part of the overlay delivery, with automatic notification of any network changes that affect the billing.

Successful networks are never just about configurations. Streamlined operations should be present right from order delivery to operational support. Device configurations and network monitoring are just part of running a CDN. The entire systems, departments and process must be aligned and integrated. Once the system and process are streamlined, automation of these events leads to a fully fledged mature CDN. This is never usually the case with CDN quickly spun up. It takes many years of lessons learnt to formulate and fine tune.

Building a CDN is easy!! It’s the operational activities that pose the biggest challenges.

Contact CacheFly to schedule an appointment with their CDN experts, who can evaluate your needs and determine a custom-fit solution for you.

This guest contribution is written by Matt Conran, Network Architect for Network Insight. Matt Conran has more than 17 years of networking industry with entrepreneurial start-ups, government organisations and others. He is a lead Network Architect and successfully delivered major global green field service provider and data centre networks.