<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Blades Won&#8217;t Die, But They Will Change</title>
	<atom:link href="http://blog.scottlowe.org/2009/06/29/blades-wont-die-but-they-will-change/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.scottlowe.org/2009/06/29/blades-wont-die-but-they-will-change/</link>
	<description>The weblog of an IT pro specializing in virtualization, storage, and servers</description>
	<lastBuildDate>Wed, 08 Feb 2012 17:13:47 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=</generator>
	<item>
		<title>By: Brent</title>
		<link>http://blog.scottlowe.org/2009/06/29/blades-wont-die-but-they-will-change/comment-page-1/#comment-48275</link>
		<dc:creator>Brent</dc:creator>
		<pubDate>Mon, 03 May 2010 16:28:54 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/?p=1429#comment-48275</guid>
		<description>One word that I didn&#039;t see in post was &quot;cost&quot;.  I do feel that there have been times were blade servers make sense  That being said as engineers and architects, many times the cost component of the equation is somewhat on the back burner, but obviously so someone, and in most cases the decision maker of a solution, it&#039;s on the front burner.

In my experience a like for like (as much as it can be) blade vs traditional servers design, traditional servers will win nearly every time when looking at the dollars.  Also looking at future business and needs as the environment grows the reoccuring cost is certainly less on traditional servers.  Factor in the added complexity of the blades, and for me the decision is obvious.  

I suspect the original thought in this post was more around the engineering of the solution and the differences between blades and traditional servers, and can the business problems be solved.  If that was the case certainly I would say it doesn&#039;t really matter at the end of the day, either will work.  As the server hardware becomes more and more of a commodity, this discussion evoloves to how much money will &quot;x&quot; resources cost (cpu, memory, connectivity, etc) what it physically looks like is not relevant.</description>
		<content:encoded><![CDATA[<p>One word that I didn&#8217;t see in post was &#8220;cost&#8221;.  I do feel that there have been times were blade servers make sense  That being said as engineers and architects, many times the cost component of the equation is somewhat on the back burner, but obviously so someone, and in most cases the decision maker of a solution, it&#8217;s on the front burner.</p>
<p>In my experience a like for like (as much as it can be) blade vs traditional servers design, traditional servers will win nearly every time when looking at the dollars.  Also looking at future business and needs as the environment grows the reoccuring cost is certainly less on traditional servers.  Factor in the added complexity of the blades, and for me the decision is obvious.  </p>
<p>I suspect the original thought in this post was more around the engineering of the solution and the differences between blades and traditional servers, and can the business problems be solved.  If that was the case certainly I would say it doesn&#8217;t really matter at the end of the day, either will work.  As the server hardware becomes more and more of a commodity, this discussion evoloves to how much money will &#8220;x&#8221; resources cost (cpu, memory, connectivity, etc) what it physically looks like is not relevant.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nate</title>
		<link>http://blog.scottlowe.org/2009/06/29/blades-wont-die-but-they-will-change/comment-page-1/#comment-45005</link>
		<dc:creator>Nate</dc:creator>
		<pubDate>Tue, 30 Jun 2009 18:36:03 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/?p=1429#comment-45005</guid>
		<description>Matt, you also might want to consider the change that 10gig brings to the table. You do not need as many individual NICs to get the same (or generally better) bandwidth.</description>
		<content:encoded><![CDATA[<p>Matt, you also might want to consider the change that 10gig brings to the table. You do not need as many individual NICs to get the same (or generally better) bandwidth.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: VMIC</title>
		<link>http://blog.scottlowe.org/2009/06/29/blades-wont-die-but-they-will-change/comment-page-1/#comment-45003</link>
		<dc:creator>VMIC</dc:creator>
		<pubDate>Tue, 30 Jun 2009 17:26:28 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/?p=1429#comment-45003</guid>
		<description>HP BL685C, up to 12 Nics per blade; 256GB of ram; 16 cores; FC... you name it... and with the HP virtual connect... sweet for VMware...</description>
		<content:encoded><![CDATA[<p>HP BL685C, up to 12 Nics per blade; 256GB of ram; 16 cores; FC&#8230; you name it&#8230; and with the HP virtual connect&#8230; sweet for VMware&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: slowe</title>
		<link>http://blog.scottlowe.org/2009/06/29/blades-wont-die-but-they-will-change/comment-page-1/#comment-44999</link>
		<dc:creator>slowe</dc:creator>
		<pubDate>Tue, 30 Jun 2009 14:28:02 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/?p=1429#comment-44999</guid>
		<description>Matt,

You haven&#039;t looked closely enough at blade options--blades from IBM and HP have far more connectivity options than the Dell blades you&#039;re describing to me. Have a look at Aaron&#039;s articles linked above; they provide an excellent overview of the expansion options available.</description>
		<content:encoded><![CDATA[<p>Matt,</p>
<p>You haven&#8217;t looked closely enough at blade options&#8211;blades from IBM and HP have far more connectivity options than the Dell blades you&#8217;re describing to me. Have a look at Aaron&#8217;s articles linked above; they provide an excellent overview of the expansion options available.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Matt Simmons</title>
		<link>http://blog.scottlowe.org/2009/06/29/blades-wont-die-but-they-will-change/comment-page-1/#comment-44997</link>
		<dc:creator>Matt Simmons</dc:creator>
		<pubDate>Tue, 30 Jun 2009 14:22:40 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/?p=1429#comment-44997</guid>
		<description>The only drawback I see from blades is the relatively limited I/O options. My Dell blades have a maximum of 4 NICs, and that&#039;s at the expense of FC daughter cards that I&#039;d have to take out to get there. If I remember correctly, the &quot;best practices&quot; for VMware infrastructure utilizing iSCSI is something like 6 NICS. 

I happen to like the blade form factor a lot, and I&#039;m willing to overlook these limitations to gain easy unified management and compactness. Or it could be that I just used piecemeal servers for so long that having ten identical machines in the same rack seems miraculous to me.</description>
		<content:encoded><![CDATA[<p>The only drawback I see from blades is the relatively limited I/O options. My Dell blades have a maximum of 4 NICs, and that&#8217;s at the expense of FC daughter cards that I&#8217;d have to take out to get there. If I remember correctly, the &#8220;best practices&#8221; for VMware infrastructure utilizing iSCSI is something like 6 NICS. </p>
<p>I happen to like the blade form factor a lot, and I&#8217;m willing to overlook these limitations to gain easy unified management and compactness. Or it could be that I just used piecemeal servers for so long that having ten identical machines in the same rack seems miraculous to me.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Francisco Muniz</title>
		<link>http://blog.scottlowe.org/2009/06/29/blades-wont-die-but-they-will-change/comment-page-1/#comment-44994</link>
		<dc:creator>Francisco Muniz</dc:creator>
		<pubDate>Tue, 30 Jun 2009 13:40:25 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/?p=1429#comment-44994</guid>
		<description>The IBM iDataPlex would be one such system (the rack as a chassis).
http://www-03.ibm.com/systems/x/hardware/idataplex/</description>
		<content:encoded><![CDATA[<p>The IBM iDataPlex would be one such system (the rack as a chassis).<br />
<a href="http://www-03.ibm.com/systems/x/hardware/idataplex/" rel="nofollow">http://www-03.ibm.com/systems/x/hardware/idataplex/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nate</title>
		<link>http://blog.scottlowe.org/2009/06/29/blades-wont-die-but-they-will-change/comment-page-1/#comment-44993</link>
		<dc:creator>Nate</dc:creator>
		<pubDate>Tue, 30 Jun 2009 13:37:45 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/?p=1429#comment-44993</guid>
		<description>I find this fella either clueless or short sighted. The claim that virtualization removes the need for hardware density seems very short sighted to me. Server sprawl has been going since the beginning and is always going faster than we thought it would. Virtualization only worsen server sprawl as it is so easy to just &#039;fire up another one&#039;. Combined consolodation therefore would seem smartest to me. Anyone who tries to claim you can;t get comparible hardware in a blade that you can get in a rack form factor either hasn&#039;t spec&#039;d a server recently or is looking at the wrong vendor. From what I&#039;ve been seeing you an spec as good if not better hardware in a blade as a rack unit. His power claims are funky to me as well. Yes you may use more power per rack, but you use less power per server. Isn&#039;t the latter the more important? The later results in a lower power bill at the end of the year, and hey maybe you saved the planet a little bit too. I also don&#039;t get his lvoe for Nexus and UCS, which in my opinion is just Cisco garbage. I don&#039;t see that proprietary locked in hardware and networking is the way of the future.</description>
		<content:encoded><![CDATA[<p>I find this fella either clueless or short sighted. The claim that virtualization removes the need for hardware density seems very short sighted to me. Server sprawl has been going since the beginning and is always going faster than we thought it would. Virtualization only worsen server sprawl as it is so easy to just &#8216;fire up another one&#8217;. Combined consolodation therefore would seem smartest to me. Anyone who tries to claim you can;t get comparible hardware in a blade that you can get in a rack form factor either hasn&#8217;t spec&#8217;d a server recently or is looking at the wrong vendor. From what I&#8217;ve been seeing you an spec as good if not better hardware in a blade as a rack unit. His power claims are funky to me as well. Yes you may use more power per rack, but you use less power per server. Isn&#8217;t the latter the more important? The later results in a lower power bill at the end of the year, and hey maybe you saved the planet a little bit too. I also don&#8217;t get his lvoe for Nexus and UCS, which in my opinion is just Cisco garbage. I don&#8217;t see that proprietary locked in hardware and networking is the way of the future.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Neil</title>
		<link>http://blog.scottlowe.org/2009/06/29/blades-wont-die-but-they-will-change/comment-page-1/#comment-44986</link>
		<dc:creator>Chris Neil</dc:creator>
		<pubDate>Tue, 30 Jun 2009 10:34:33 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/?p=1429#comment-44986</guid>
		<description>I disagree with his first assumptions. I still think processor dense rack space is an issue and hardware swapout is also important. They are not negated by virtualisation. 

Current blades are bit low end for large scale virtualisations, but I doubt we&#039;ll re-embrace mainframes quite yet. I expect the rack to become a chassis and the blades to look like traditional rackmount servers in form.

As for Cisco UCS, I can&#039;t see that taking off. They&#039;ve out-stretched themselves this time. IOS versioning has been a long running joke and they show no signs of addressing it. Imagine server firmware like that.</description>
		<content:encoded><![CDATA[<p>I disagree with his first assumptions. I still think processor dense rack space is an issue and hardware swapout is also important. They are not negated by virtualisation. </p>
<p>Current blades are bit low end for large scale virtualisations, but I doubt we&#8217;ll re-embrace mainframes quite yet. I expect the rack to become a chassis and the blades to look like traditional rackmount servers in form.</p>
<p>As for Cisco UCS, I can&#8217;t see that taking off. They&#8217;ve out-stretched themselves this time. IOS versioning has been a long running joke and they show no signs of addressing it. Imagine server firmware like that.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: rodos</title>
		<link>http://blog.scottlowe.org/2009/06/29/blades-wont-die-but-they-will-change/comment-page-1/#comment-44982</link>
		<dc:creator>rodos</dc:creator>
		<pubDate>Tue, 30 Jun 2009 04:22:42 +0000</pubDate>
		<guid isPermaLink="false">http://blog.scottlowe.org/?p=1429#comment-44982</guid>
		<description>In reference to the blades and BIOS/firmware updates I think Cisco with UCS have made some good ground here by making firmware etc part of the service profile.

Check out &quot;Cisco Unified Computing System Manager and Firmware Profiles&quot; http://blogs.cisco.com/datacenter/comments/cisco_unified_computing_system_manager_and_firmware_profiles/

Rodos</description>
		<content:encoded><![CDATA[<p>In reference to the blades and BIOS/firmware updates I think Cisco with UCS have made some good ground here by making firmware etc part of the service profile.</p>
<p>Check out &#8220;Cisco Unified Computing System Manager and Firmware Profiles&#8221; <a href="http://blogs.cisco.com/datacenter/comments/cisco_unified_computing_system_manager_and_firmware_profiles/" rel="nofollow">http://blogs.cisco.com/datacenter/comments/cisco_unified_computing_system_manager_and_firmware_profiles/</a></p>
<p>Rodos</p>
]]></content:encoded>
	</item>
</channel>
</rss>

