<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Are CDNs really necessary?</title>
	<atom:link href="http://blog.broadbandmechanics.com/2007/01/are-cdns-really-necessary/feed" rel="self" type="application/rss+xml" />
	<link>http://blog.broadbandmechanics.com/2007/01/are-cdns-really-necessary</link>
	<description>Digital Lifestyle Aggregation - helping to establish open source infrastructure</description>
	<pubDate>Fri, 21 Nov 2008 17:44:25 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
		<item>
		<title>By: Marc&#8217;s Voice &#187; Blog Archive &#187; Final Friday in January 07 blog links</title>
		<link>http://blog.broadbandmechanics.com/2007/01/are-cdns-really-necessary#comment-238389</link>
		<dc:creator>Marc&#8217;s Voice &#187; Blog Archive &#187; Final Friday in January 07 blog links</dc:creator>
		<pubDate>Fri, 26 Jan 2007 22:36:35 +0000</pubDate>
		<guid isPermaLink="false">http://blog.broadbandmechanics.com/2007/01/are-cdns-really-necessary#comment-238389</guid>
		<description>[...] Good responses to my query on &#8220;Are CDN&#8217;s necessary?&#8221;  Thank guys! [...]</description>
		<content:encoded><![CDATA[<p>[...] Good responses to my query on &#8220;Are CDN&#8217;s necessary?&#8221;  Thank guys! [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: GCO</title>
		<link>http://blog.broadbandmechanics.com/2007/01/are-cdns-really-necessary#comment-238387</link>
		<dc:creator>GCO</dc:creator>
		<pubDate>Fri, 26 Jan 2007 22:02:04 +0000</pubDate>
		<guid isPermaLink="false">http://blog.broadbandmechanics.com/2007/01/are-cdns-really-necessary#comment-238387</guid>
		<description>Doug and Jonathan are right. I'll add a few more things to the list. 

If performance matters then yes multiple mirrored sites are better than one centralized origin. That said, building out a few data centers isn't nearly the same thing as serving content from locations that are within a hop or two of the end user and known to be performing well in real-time. 

Without real-time internet monitoring and traffic shifting the mirrored site can't optimize performance for end users other than on a geography basis. If you've ever looked at traceroutes from one ISP to another within the same city you know that geography has little to do with the way networks communicate with one another. I've seen cases where a request from a client in one city to a host in the same city traversed 24 internet hops to reach it's destination. 

When you're talking about availability, mirrored sites don't automatically route around internet congestion, bottlenecks, and outages (e.g. fiber cuts caused by last month's Taiwanese earthquake). The person who manages the mirrored sites doesn't have partnerships with every major network and they don't know about network specific latencies or packetloss that may be occuring at any given time.   They don't have advanced warning of failed peering agreements. 

Akamai and other CDN's provide instant scalability. No additional purchasing. No installs. No provisioning. Capacity on demand means capacity is already available not capacity could be available if we have some advance notice. If you're not using a CDN then you run the risk of not having enough capcity available when it's needed or you're paying to have extra capacity available that's rarely  needed. 

When it comes to management a CDN means fewer servers (web, app, dns etc.), routers, app acceleration devices, ssl accelerators, firewalls, IPS systems. It means fewer software licenses. Lower bandwidth costs. Less to upgrade. Less to patch. There's less to manage. 

Reporting, analytics, content management, digital rights management, syndication, ad insertion, troubleshooting tools, diagnostics. You get it all with a CDN. Sure you could eventually build most of this out yourself but why would you want to unless that's just your thing?</description>
		<content:encoded><![CDATA[<p>Doug and Jonathan are right. I&#8217;ll add a few more things to the list. </p>
<p>If performance matters then yes multiple mirrored sites are better than one centralized origin. That said, building out a few data centers isn&#8217;t nearly the same thing as serving content from locations that are within a hop or two of the end user and known to be performing well in real-time. </p>
<p>Without real-time internet monitoring and traffic shifting the mirrored site can&#8217;t optimize performance for end users other than on a geography basis. If you&#8217;ve ever looked at traceroutes from one ISP to another within the same city you know that geography has little to do with the way networks communicate with one another. I&#8217;ve seen cases where a request from a client in one city to a host in the same city traversed 24 internet hops to reach it&#8217;s destination. </p>
<p>When you&#8217;re talking about availability, mirrored sites don&#8217;t automatically route around internet congestion, bottlenecks, and outages (e.g. fiber cuts caused by last month&#8217;s Taiwanese earthquake). The person who manages the mirrored sites doesn&#8217;t have partnerships with every major network and they don&#8217;t know about network specific latencies or packetloss that may be occuring at any given time.   They don&#8217;t have advanced warning of failed peering agreements. </p>
<p>Akamai and other CDN&#8217;s provide instant scalability. No additional purchasing. No installs. No provisioning. Capacity on demand means capacity is already available not capacity could be available if we have some advance notice. If you&#8217;re not using a CDN then you run the risk of not having enough capcity available when it&#8217;s needed or you&#8217;re paying to have extra capacity available that&#8217;s rarely  needed. </p>
<p>When it comes to management a CDN means fewer servers (web, app, dns etc.), routers, app acceleration devices, ssl accelerators, firewalls, IPS systems. It means fewer software licenses. Lower bandwidth costs. Less to upgrade. Less to patch. There&#8217;s less to manage. </p>
<p>Reporting, analytics, content management, digital rights management, syndication, ad insertion, troubleshooting tools, diagnostics. You get it all with a CDN. Sure you could eventually build most of this out yourself but why would you want to unless that&#8217;s just your thing?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Doug Kaye</title>
		<link>http://blog.broadbandmechanics.com/2007/01/are-cdns-really-necessary#comment-238373</link>
		<dc:creator>Doug Kaye</dc:creator>
		<pubDate>Fri, 26 Jan 2007 15:58:58 +0000</pubDate>
		<guid isPermaLink="false">http://blog.broadbandmechanics.com/2007/01/are-cdns-really-necessary#comment-238373</guid>
		<description>Hi, Marc. It depends on what's being delivered and why. An architecture like Akamai's can do wonders to speed up interactive sites by hosting all those small, frequently requested files such as images, JavaScript and stylesheets. But other applications have different needs. For example, live streaming needs big pipes and geographical proximity, whereas background downloads such as the media files (podcasts) attached to RSS feeds have very low requirements for which something like Akamai can be overkill and even make things more difficult. In the CDN world, there are also different competing architectures that have substantially different characteristics. Akamai is best known for hundreds of locations with (relatively) small capacity in each, whereas others use perhaps two orders of magnitude fewer locations but much more capacity at each site.

     ...doug (author of "Strategies for Web Hosting and Managed Services" which covers this and other topics)

http://www.rds.com/books/hosting/index.html</description>
		<content:encoded><![CDATA[<p>Hi, Marc. It depends on what&#8217;s being delivered and why. An architecture like Akamai&#8217;s can do wonders to speed up interactive sites by hosting all those small, frequently requested files such as images, JavaScript and stylesheets. But other applications have different needs. For example, live streaming needs big pipes and geographical proximity, whereas background downloads such as the media files (podcasts) attached to RSS feeds have very low requirements for which something like Akamai can be overkill and even make things more difficult. In the CDN world, there are also different competing architectures that have substantially different characteristics. Akamai is best known for hundreds of locations with (relatively) small capacity in each, whereas others use perhaps two orders of magnitude fewer locations but much more capacity at each site.</p>
<p>     &#8230;doug (author of &#8220;Strategies for Web Hosting and Managed Services&#8221; which covers this and other topics)</p>
<p><a href="http://www.rds.com/books/hosting/index.html" rel="nofollow">http://www.rds.com/books/hosting/index.html</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jonathan peterson</title>
		<link>http://blog.broadbandmechanics.com/2007/01/are-cdns-really-necessary#comment-238372</link>
		<dc:creator>jonathan peterson</dc:creator>
		<pubDate>Fri, 26 Jan 2007 15:49:15 +0000</pubDate>
		<guid isPermaLink="false">http://blog.broadbandmechanics.com/2007/01/are-cdns-really-necessary#comment-238372</guid>
		<description>It's a nice thought, but building and managing mirrored sites is a non-trivial task, especially as the number of mirrors grows.  

I'm sure there is a magic formula that incorporates time to market, labor costs, peak expected load to tell you when mirroring would be cheaper, but I'm also sure it's a complex formula.

We use a LOT of akamai for clients, and we're a 150 person shop.  When something is wrong our network gurus can jump in a car and 30 minutes later be at our data center fixing things.  Akamai magically handles everything else.  If we had 10 datacenters scattered around there would be times when fixing things might require jumping on planes, or hiring 12 more gurus, right?</description>
		<content:encoded><![CDATA[<p>It&#8217;s a nice thought, but building and managing mirrored sites is a non-trivial task, especially as the number of mirrors grows.  </p>
<p>I&#8217;m sure there is a magic formula that incorporates time to market, labor costs, peak expected load to tell you when mirroring would be cheaper, but I&#8217;m also sure it&#8217;s a complex formula.</p>
<p>We use a LOT of akamai for clients, and we&#8217;re a 150 person shop.  When something is wrong our network gurus can jump in a car and 30 minutes later be at our data center fixing things.  Akamai magically handles everything else.  If we had 10 datacenters scattered around there would be times when fixing things might require jumping on planes, or hiring 12 more gurus, right?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
