Operator CDN pitfalls

Pitfall 1) Build it from scratch
We have seen telecom operators try to build their own CDN from scratch. R&D departments started research, most often copying how they think Global CDNs designed their platforms. They start from an IP network engineering point of view, so they locked their CDN into the network, threw in some caches, hacked their DNS and... well, years go by, they never developed a working solution and missed the point of the commercial and strategic reasons for a CDN. A waste of time and money.

We have also seen quite some telcos who had built their home brewn CDN that went into a successful operational stage. They however ended up with a platform that had grown organically but with hardcoded designs, hardcoded technology as a glue between the servers. They were essentially locked into their own platform, which they needed to manage through dozens of screens. Once they realized they needed to scale and unify, they were blocking themselves and they and their customers faced a heavy migration phase which in many cases costs more than what they saved.

Pitfall 2) Partner with a Global CDN for wholesale
We have seen telecom operators partner with a CDN 'to at least get into the game'. This is a typical short-term sales strategy where the telco tries to make some money by reselling a third party CDN, sometimes letting the CDN deploy some servers or utilize their infrastructure a bit. This model doesn't really generate any real revenue for the telco and it doesn't bring the telco CDN specific sales expertise. This model also does not offload their network. A Global CDN is for wholesale only and cannot be used as a retail CDN so there is no real added value. Except for the Global CDN who gets a free sales channel and cheap traffic.

Pitfall 3) Partner with a Global CDN for an on-net CDN
Some Global CDNs offer licensed models, which in reality are not purely about licensing but about deploying a managed service. They wrap a marketing package around technology that was never designed to be run inside telco networks and was never designed to be operated by a third party. Global CDN technology was designed in the late nineties: the Internet stone age. Basically Akamai conceptualized this in the nineties and all other 'me-too' Global CDNs use similar generic technologies. 

The first problem that these telcos have gotten into is that Global CDNs have been built around best effort global internet wholesale delivery technologies such as caching and DNS, while a premium telco with premium retail services and that wants to target premium OTT content, can only really differentiate with premium CDN technologies that offer managed distribution, managed request routing, intelligent business rules and much finer granularity.

The second problem is that these CDNs are typicaly not easy to operate. That's why global CDNs push for a managed environment. It is not a matter of train, install and operate. How do telcos think ever to be able to run a commercially successful CDN when they use the same technologies and need to spend as much as Global CDNs on operations? Remember that most Global CDNs have never been profitable, especially not for video services. The sole reason for that is that because their technologies are too expensive to operate.

It is also important to look at the reasons why Global CDNs start licensing their technology. It is a defensive strategy. They want to be in control of delivery, also in your network. If they can't manage this through peering and on-net servers, then they offer licensing and managed models. Their interest is the opposite of the telcos interest. It's a trojan horse.

Pitfall 4) Vendor lock-in
Traditional telco vendors have started to offer CDN appliances to telecom operators. Their entire business model is based on selling appliances that build digital roads. CDNs are not in their interest. More traffic: good, logistics: bad. CDNs mean that you can pump much more traffic over the same pipes. When telcos deploy massive CDNs, traditional vendors will not sell more routers and switches. So their choice to offer CDNs is also a defensive move, not necessarily in the interest of the telco. 

It gets worse: their strategy is focussed on locking telecom operators into their technology. By embedding their CDN technology in their routers and switches, telcos will effectively be locked out of other vendors for routing and switching gear. Once your network is 100% vendor A or vendor B, they completely own you. Cisco started this and as always typically all other vendors don't step back and rethink but just try to copy whatever Cisco does. If you look at the history of some vendors they constantly changed their strategy from being a failing cache vendor to a failing CDN to a failing CDN vendor.

Another problem is that all vendor technologies are based around closed and proprietary stacks of appliances. They want to sell you routers, switches, streamers, caches, vaults, pop heads, control planes and so on. Each PoP will become so expensive that these CDNs simply don't scale financially. And we have seen to many examples where telcos are spending years to get this stuff really working: a bunch of appliances does not make a proper CDN, these telcos still need to do a lot of R&D on workflow integration and management themselves. You will be locked into appliances that are outdated and outperformed in two years. Expensive and time consuming.

Pitfall 5) Assumptions
In our office we have a giant poster on the wall: "Assumption is the mother of all screw ups". We have seen RFIs and RFPs from telecom operators with hundreds of pages about caching, DNS and IP networking, but not a word about operations, workflow integration, CDN design philosophies. They assumed that a CDN is about these basic technologies. While a CDN is about strategy, operation, driving down costs and content. We have encountered telcos which assumed that a delivery appliance from a specific vendor could solve all their problems. The box turned out to be a nightmare and the telco was left with extremely expensive and outdated bricks. In general these telcos had not really prepared their CDN strategy and had not really discussed their ideas beyond some vendors.

Pitfall 6) No sales, no strategy
Some telco CDNs are purely used for retail services, which means that there is no commercial wholesale requirement. That is relatively easy: deploy, setup the workflows and go. Other CDNs are built around a wholesale model, which is much harder. Even though deployed CDNs can be a success from a deployment, project, technology and operational point of view, that alone does not guarantee commercial success. We have seen telcos underestimate the experience they needed in CDN expertise, streaming expertise and commercial expertise. Offering a CDN as a wholesale service requires telcos to invest in knowledge, marketing and sales as well. Don't bother to purchase a CDN if you're not willing to invest in commercial training and commercial resources.

Pitfall 7) See CDNs as a static environment
Many telcos, vendors and system integrators see CDNs as an extension of the IP network or as an extension of the IPTV platform. Which are both quite static environments. An IP network is a matter of deploying switches and routers and fiber. These components don't change overnight. An IPTV platform is a matter of integrating once and when it works, never touch it again. But a CDN is like an organic entity. Traffic patterns can change so CDNs have to instantly adapt without the need for human intervention. New technologies emerge every six months which need to be adopted, developed, tested, deployed and supported. CDNs tend to scale from a small number of PoPs at the start to new PoPs every few months. Especially wholesale CDNs sign up new customers per month, per week, per day and sometimes per hour. Each customer has their own specific workflow which needs to be integrated in an automated way. A proper CDN needs to support all these changes without any downtime and without any negative effect on other users. Telcos are not helped with a CDN that on paper does what it should, their CDN partner needs to take them by the hand and help them through the process of their strategy, technology choice, flexible architecture design, operation and sales.