I'm happy to go through the thinking in deciding to EOL DreamSpeed CDN. There are several reasons why it didn't live up to our expectations, but the main reason is that a CDN didn't match most customers' use case – primarily backup, archive, and disaster recovery. These customers need reliable storage in an offsite location and they make up the majority of DreamObjects customers.
We also saw a lot of customers wasting money on DreamSpeed CDN because they didn't use enough traffic. Customers would enable the CDN, but traffic levels wouldn't be enough to keep the cache warm. That meant data was constantly being resent to the CDN to warm the cache and then delivered to the end user, adding an extra step and defeating the purpose of having a CDN in the first place.
There were also several technical issues that contributed to the decision. We created a temporary "kludge" to get the mapping redirection to work because of an imperfect integration with the provider. An ideal integration API was never created and the kludge became permanent. We were also never able to implement additional features like single key purging, restricting CDN hits to specific regions, and automating setting of cache headers.
Yes, we are going to continue supporting the existing CDN URLs any aliases that point to them to make the EOL as seamless as possible.