During CDN World Summit, Jet-Stream founder Stef van der Ziel introduced Open Play CDN federation in his Keynote speech. This topic was also one of the CDN Academy courses presented during the event.
(Important: read the article About Federation first) and download the slides here (PDF 1.3MB). This article by Stef describes the background of how Jet-Stream conceptualized, materialized and developed full CDN integration:
CDN interconnection has been on our agenda for many years. We built the first federated CDN in 2000 and had taken part of many discussions in the early years of CDN around the concept of federation on all levels: business, strategy, technology, standardization, business logic. However CDN interconnection is one of the hardest problems to solve. It is so complex, because you need to oversee and consider the entire spectrum of the CDN space. The pitfalls are easy, you can completely lose yourself in theoretical business models and scenarios which will never materialize, but you can also very quickly develop a blinding focus on too narrow scenarios. You can completely lose yourselves in feature hell for years, but you can also make too easy architecture decisions that will have dramatic impact in the future, rendering a solution useless when the industry evolves. The CDN interconnection feature was put on our roadmap many years ago but we felt the ideas were not materialized enough to start development. Sometimes it just takes time to execute things right.
We knew that a locked in Jet-Stream-to-Jet-Stream solution would be a lock-in and unacceptable for the industry. We knew that it would take too much time for standards to become usable and that standards would be limiting us and our customers. We knew that developing a separate translation layer between CDNs was not a good option, too many elements. We also knew that overlaying was too simple, we needed actual integration with CDNs. We knew that a solution should be usable both as an upstream and a downstream CDN.
We also knew that we wanted to treat other CDNs as a logical server node, just as if it was an actual edge server or edge PoP. That was an important decision. Which we actually could do, since we had designed our architecture quite abstracted. We had done quite some core innovations before which helped us implement a true holistic CDN integration environment. Many prior Jet-Stream inventions helped us to implement a true holistic integrated multi-CDN solution:
Before we started implementing the additional required technologies, I started to analyze business scenarios. Jet-Stream is not a regular vendor that innovates technology, we always start from strategic and business analysis and then R&D technologies that can be optimally used to support these business opportunities. This process took a long time. I’ve always known we were thinking in the right direction but the ideas were not clear enough to start development.
The ideas materialized beginning this year. Our own StreamZilla CDN service was only focussing on Europe: our customers typically have a European audience and our performance to the US was ok. However a number of customers asked for improved performance in the USA. So we looked at our options:
We decided to kill option one, go for option two in the short term and investigate options 3 and 4 as well. We litterally ordered and paid for the virtual machines through an online store, got access within four hours and two hours later the edges were configured, tested and added to our pool of resources. That is the power of cloud. That is the power of software CDNs.
At around the same time we had meetings with various telecom operators who were sharing their ideas about Network Function Virtualization, and that fully aligned with our ideas to run CDNs on clouds. Jet-Stream demonstrated the ability to run both the control and data planes fully on Amazon years ago. After some technical and business sessions both Jet-Stream and the operators concluded that the need for the complex, expensive and limiting CDN federation standards was rendered useless by the ease of use of commoditized cloud infrastructures. The appliance is dead, CDN federation unnecessary and software CDNs were the future. A future Jet-Stream invented over ten years ago :)
When we started to investigate the capabilities of other CDNs for integration purposes it was actually the first time we encountered the features and APIs of other CDNs. And we had mixed feelings. On one side it was a shock to see how poor the feature set of regular CDNs typically is. You can set some parameters like C-naming and TTL and hopefully you can get some logs out of these systems, but that is about it. If you compare that to our advanced media workflow management environment and rich APIs it’s really a shocker. On the other hand we managed to make integrated offloading work with a number of CDNs in a few days time, with some hacks in an isolated development environment: our management system didn’t know any better than that it was talking to a physical edge node, while in reality it was an account on a third party CDN. And live streams flowed through. Score!
So we reached out to a number of CDNs and asked them to implement some additional features, or to explain why basic features such as anti-deep-linking token management didn’t work according to their documentation, or to ask adjustments to logs, et cetera.
It was interesting to hear that these CDNs were very open to cooperate. We had always seen other CDNs as competition for StreamZilla. However, we started to see other CDNs as commoditized infrastructures which we could use to offload (overflow) to. And they were happy to become a resource supplier they have overcapacity, need volume and liked us adding unique value to their systems.
It also aligned with my vision with StreamZilla: do not invest in commodities, invest in innovation instead. Regular CDNs invest millions in PoPs, operational staff, sales staff. StreamZilla’s strategy has always been to outsource commodities and automate everything via software to reduce costs.
And that was where all ideas came together: the ability to really integrate multiple CDNs in a rich CDN management system. Suddenly we could support a whole range of new business options. One of the benefits of running your own CDN is that you pragmatically encounter content owner requests and operational challenges on a daily basis which you immediately can translate into innovations. Not that many vendors who can do that.
The actual development of integrated 3rd party CDN support in our technology took less than three months to implement, including the framework, the enhancements of existing technologies and basic support of a limited number of CDNs:
We found out that the access logs and the access management tokens were the hardest nut to crack, and they still are with several CDNs. Many CDNs have quite exotic and limited implementations which in some cases makes access control and log processing impossible. We also encountered CDNs who claim to support HTTP adaptive streaming but in reality they have quite some caching issues and also struggle with the Thundering Herd problem for HTTP live streaming. But in general my (amazing!) development team was able to make basic integration and basic functionality work with some CDNs and got things working. Compared to having to implement proposed CDN interconnectivity implementation was a breeze on Jet-Stream side an almost nonexistent on the third party CDNs sides while Jet-Stream can offer much higher standards in terms of features, flexibility and performance.
The most important is that the core foundation for integrated third party CDN support as overflow or edge nodes within the Jet-Stream CDN is fully implemented. No additional screens, no separate tools. Between our list of delivery nodes you will find third party CDNs. Just as if they were always there.
This means that it is now relatively simple to add support for new CDNs and also simple to enhance the feature set with pre-integrated CDNs. And it is very easy to keep adding additional business logic to further optimize costs and performance, and offer more USPs compared to relatively simple overlay systems. Oh and we don’t force anyone to run code within clients. CDNs cannot enforce this, remember?
(slides 10 and 11) In less than three months time, our system had become a meta-CDN management system, that allows you to mix all kinds of resources within one CDN: mix physical servers, virtual servers, cloud based servers and 3rd party CDNs as if they are logical building blocks. All our existing logic applies to all delivery nodes. It is not a bolted-on feature.
All premium features apply, and the CDN management system is intelligent so it knows which services and features are and are not supported per logical delivery resource. It automatically geo load balances requests dynamically over any mix of nodes, including 3rd party CDNs, based upon business logic, popularity, performance and many other static and dynamic values.
(slides 13 and the rest) Some interesting new business scenarios thanks to Open Play:
Oh and of course virtually all 3rd party CDNs, clouds and hosted services can be used as a remote origin for the Jet-Stream CDN. So it can also be used as a downstream CDN.
Open Play is the first real CDN interconnectivity technology and it is executed in a beautiful integrated way. Contact us for information and a demo! The new StreamZilla CDN will be the first CDN to operationally implement it. The technology includes many unique Jet-Stream innovations and these are protected. Note that all described technologies are unique Jet-Stream IPR, we explicitly do not give you the right to mimick or replicate any of the described mechanisms or technologies in any way. Jet-Stream is opening up our code through licensing to anyone. Stealing is intellectual poverty. License and let’s share innovation!0