
What Experts Love and Hate About CDNs - kawera
https://www.maxcdn.com/blog/cdn-experts-on-cdns/
======
codegeek
MaxCDN user here. I have my love and hate with CDNs in general but one thing I
hate specifically about maxcdn is that once you create a "pull zone", they
will continue to charge you for it even if not being used. In fact, even if
you delete a pull zone, it remains active for billing in the background and
have to call them to terminate completely. That is shady. Other than this,
pretty good service.

~~~
mxpxrocks10
Hi - Chris here from MaxCDN. That's a really good point and unintentional!
Will get it fixed ASAP. Thanks for the feedback. Drop me a line if anything
else comes up. chris at maxcdn

~~~
elcct
Are you Chris from MaxCDN or chris at maxcdn? Sorry I am case sensitive...

~~~
chucksmash
Pretty clearly just providing his email address in a way intended to avoid
scrapers.

~~~
mreiland
does that even work nowadays?

------
nadaviv
I'm surprised no one mentioned the obvious security issues arising from the
use of CDNs, especially when used to deliver JavaScript source code.

When you serve your JavaScript over a CDN rather than directly from your
server, the CDN has access to pretty much everything your users have access to
- the CDN can read cookies and local tokens, make actions on behalf of users
(such as updating the profile, messaging users, deleting content, making
payments), read out financial/sensitive information, and more. A permanent and
impossible to fix XSS attack vector that can be abused by your CDN, or anyone
who hacks to your CDN.

This, in addition to security issues caused when the CDN proxies requests to
your main hostname and not only to your static files (requiring you to
surrender your SSL keys to them).

While working on Bitrated, a Bitcoin service that deals with users' private
keys and funds on the client-side, this stood out as a very serious issue. We
opted to not serve any content from 3rd-party providers, at all (including
Analytic services, which suffer from the very same issue), and configured a
strict Content-Security-Policy that forbids anything other than hostnames
controlled directly by us over SSL.

Edit: I'm aware of SRI, but it is brand new and not yet supported by the
majority of browsers in use, so its not really a realistic solution just yet.

~~~
ryan-c
What you can do with some CDNs is have a self-served loader that pulls the
files from the CDN using XHR (requiring CORS headers...), verifies the content
hash, then injects it into the page if it looks good. I have a PoC on github
[https://github.com/ryancdotorg/verifyjs](https://github.com/ryancdotorg/verifyjs)
\- same sort of thing could be modified to support signed files rather than
hashed, which SRI can't do.

~~~
mxpxrocks10
that's a pretty cool POC Ryan. Do you know @jdorfman? You guys should hook up

~~~
ryan-c
I do not - I mainly do arcane infosec work and only in the past two years or
so (I've gotten better with javascript in that time) have I been doing non-
trivial client side stuff. Consequently, most of my professional contacts are
in infosec.

~~~
mxpxrocks10
cool. I asked him to drop you a line

------
boundlessdreamz
One thing to watch out for with some CDNs (cloudfront & fastly for ex) is per
request pricing. it was the biggest component of our cloudfront bill because
we have lot of small resources (js/css files) which had to be served with
short expiry times. We moved to edgecast and it was cheaper & faster but
recently they seem to be having ISP/PoP level outages which we are not able to
pinpoint.

So we are on the lookout for good CDN. Came across
[https://www.keycdn.com/](https://www.keycdn.com/) which checks a lot of boxes
but I can't find any reviews of it. Has anyone here used it?

~~~
astral303
Here using Fastly with great results. Consistently fast, including SSL
negotiation. Truly fast invalidation. A ton of control available with Custom
VCLs (they run a custom Varnish version). E.g. you can generate an "Expires:"
header automatically on the CDN edge based on the Cache-Control header. You
can serve a static resource if the backend times out. Best of all _stale
refresh_ and soft purge means that you can update resources "in the
background" on the CDN and avoid exposing your clients to "miss latency"
(backend server latency).

I feel that the ultimate answer is a multi-CDN solution. If your assets are
critical to be always available, I think you are going to want to diversify
your CDNs. The challenge comes in how to load balance and/or failover across
CDNs--whether that's easy or not depends on your use case. Doing so
automatically at the time of trouble is a challenge too. Dyn just rolled out a
product called Internet Intelligence that monitors all the CDN's performances
(with end-user perf measurements) and can help you determine whether one of
your CDNs is slow (and whether it's slow only in certain parts of the world).
Theoretically, then you can combine geo-aware DNS with congestion-aware CDN
selection and BAM, diversified, less-congestion-sensitive content delivery.

~~~
jamescun
My faith in Fastly was shaken after earlier this year, we experienced
connections intermittently failed (HTTP 5xx) to any service behind Fastly
(ours and third party) in our Amsterdam datacentre. We contacted their support
but told us repeatedly it must be our fault (like a proxy). Long story short
after investigation it was confirmed to be their fault and most likely a
machine-gone-bad in their PoP and the intermittent nature was related to
balancing across them. This was not resolved until their team woke up and we
pinged their team on IRC. It shook my support from the obvious lack of
monitoring or on-call system.

------
junto
One of the best APIs I've used is the one from Rackspace on top of their Cloud
Files offering. Their documentation is really rather good too. They are simply
sitting on top of Akamai and you get a nice REST API to talk to.

~~~
boundlessdreamz
If I remember right, when you use Cloud Files you don't get access to all of
Akamai's PoPs

------
devhxinc
I love the flexibility and speed that CDNs provide however I hate the fact
that if you are outside the US CDNs get very flaky very quickly. Most of the
large providers don't have a Point of Presence (POP) in Africa and large parts
of Europe, Russia and Asia are not covered (i.e don't have a close POP).
CloudFlare and Akamai are the only companies that have POPs in Africa, it's
unfortunate that small players can't use really use Akamai. Aside from the
location problems, the lack and / or pricing of HTTPS / TLS really sucks.

~~~
curun1r
> it's unfortunate that small players can't use really use Akamai

Small players can't use Akamai _directly_ , but there are providers (Netflify
and probably some others) that use Akamai that are more accessible to the
downmarket crowd.

~~~
acdha
The most prominent example being Rackspace, which claims to offer the full
Akamai network with simpler pricing & APIs:

[http://www.rackspace.com/cloud/cdn-content-delivery-
network/](http://www.rackspace.com/cloud/cdn-content-delivery-network/)

~~~
jread
Not the full Akamai network - only 219 edge locations out of many thousands on
Akamai's full network:

[http://go.rackspace.com/cdn.html?cm_mmc=PPC_NonBrand-_-
US_Cl...](http://go.rackspace.com/cdn.html?cm_mmc=PPC_NonBrand-_-US_Cloud_NB-
_-Exact-_-avirex%20host)

------
latch
reporting:

cache hit ratios at different POPs and different types of resources (don't
lump my .js files with my mp4s, let me give you patterns / routes to group
by)).

fine grained latency numbers (95, 99, 99.9 percentiles) per region, per
resource type.

~~~
mxpxrocks10
this is a really good idea.

------
k__
lol, how no one even mentions privacy issues.

~~~
virmundi
Given that they don't, would you explain the topic?

~~~
walrus
Given that CDNs are used on many different sites, it's easy for people running
CDNs to track other people around the internet.

There are also security issues: if you're referencing some JavaScript from a
CDN, you're trusting the people running the CDN to actually serve the
JavaScript you request.

~~~
reacweb
Do not trust the CDN:

link(href='//maxcdn.bootstrapcdn.com/bootstrap/3.3.5/css/bootstrap.min.css',
rel='stylesheet'
integrity='sha256-MfvZlkHCEqatNoGiOXveE8FIwMzZg4W85qfrfIFBfYc=
sha512-dTfge/zgoMYpP7QbHy4gWMEGsbsdZeCXz7irItjcC3sPUFtf0kuFbDz/ixG7ArTxmDjLXDmezHubeNikyKGVyQ=='
crossorigin='anonymous')

script(src='//maxcdn.bootstrapcdn.com/bootstrap/3.3.5/js/bootstrap.min.js'
integrity='sha256-Sk3nkD6mLTMOF0EOpNtsIry+s1CsaqQC1rVLTAy+0yc=
sha512-K1qjQ+NcF2TYO/eI3M6v8EiNYZfA95pQumfvcVrTHtwQVDG+aHRqLi/ETn2uB+1JqwYqVG3LIvdm9lj6imS/pQ=='
crossorigin='anonymous')

~~~
ejcx
To be fair SRI is brand new and doesn't exist yet in most browsers (just went
live in chrome in the last..month?). It isn't realistic to expect most people
to already be using it..

You can check a particular browser for SRI support using
[https://ejj.io/sri/](https://ejj.io/sri/)

~~~
smithclay
Despite minimal browser support, it's still nice to start seeing projects like
this that make it very easy to implement SRI (for Wordpress users, in this
case):

[https://id.wordpress.org/plugins/wp-
sri/](https://id.wordpress.org/plugins/wp-sri/)

------
jack9
Why people use shitty CDNs like Akamai or Highwinds (kinda) or MaxCDN, is
beyond me. Does nobody do testing? Pick someone with a sane API and you don't
have these problems. I happen to like CDN77.

~~~
astral303
What don't you like about those CDNs? In particular Akamai?

~~~
jack9
Almost every single one has borderline nonsensical services, leading to some
very "creative" APIs or workarounds for weaknesses.

The pitches that I have heard in regards to a lack of initiated prewarming or
synchronization/transfer methods or architecture optimizations is pathetic at
best and fraudulent at worst (Highwinds CDN, shame on you). Akamai has been
inconsistent or failed to meet any sort of standard on a given test run from
2005-2008 (the last time I was considering them). Akamai continues to be
opaque and stonewalls any attempt to assess why individual failures occur.
Whatever your particular needs are, there is absolutely NO REASON that you
should have to do any kind of workaround, without a discount in price where
you can measure a tradeoff. As per my original comment, a shitty CDN is not an
objective assessment. Being unhappy with your CDN because of an API is just
plain laziness. I don't want to go to a CDN host website, ever. The API should
be robust and performant. Storage, caching, availability by geo, pricing.
These are solved problems. If you are using a CDN and are unhappy, go find a
new one and move. If you can't do that, you have larger problems.

