<?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: Shall We “Converge”?</title>
	<atom:link href="http://blog.egenera.com/2008/06/shall-we-%e2%80%9cconverge%e2%80%9d/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.egenera.com/2008/06/shall-we-%e2%80%9cconverge%e2%80%9d/</link>
	<description>Covering Data Center Availability, Responsiveness and Converged Infrastructure</description>
	<pubDate>Wed,  8 Sep 2010 20:35:54 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: Thomas Hoberg</title>
		<link>http://blog.egenera.com/2008/06/shall-we-%e2%80%9cconverge%e2%80%9d/#comment-58</link>
		<dc:creator>Thomas Hoberg</dc:creator>
		<pubDate>Tue, 28 Oct 2008 22:10:21 +0000</pubDate>
		<guid isPermaLink="false">http://blog.egenera.com/?p=72#comment-58</guid>
		<description>Yes, Egenera has set a very fine example, but so did IBM when they invented the 360 architecture, mainly by looking ahead and implementing an expandable and scalable architecture. It's still alive today in a way, but it doesn't fit a very broad range of businesses any more. Similarly Egenera doesn't start small enough for many businesses and doesn't scale far enough for many others. As you outgrow an enclosure, you loose almost all typical Egenera benefits. And an upgrade of the backplane looks urgend to me, if you consider the processing and I/O capabilities of what can be put in to a blade these days. Considering the initial investment and the vendor lock-in risk, it simply doesn't seem an acceptable risk, unless you need to replace a couple of thousand servers in a hurry. 3 leaf systems Infiniband based V-8000 server and now DCE simply offer a far easier migration path towards unified wire and far less dependency on a single vendor.
That's why I welcome your tendency to develop your PAN manager into a generic data center operating system, that is hardware and hypervisor agnostic and your willingness to license that. Going further down the proprietary hardware road seems like a sure way into oblivition to me.

Regards, Thomas</description>
		<content:encoded><![CDATA[<p>Yes, Egenera has set a very fine example, but so did IBM when they invented the 360 architecture, mainly by looking ahead and implementing an expandable and scalable architecture. It&#8217;s still alive today in a way, but it doesn&#8217;t fit a very broad range of businesses any more. Similarly Egenera doesn&#8217;t start small enough for many businesses and doesn&#8217;t scale far enough for many others. As you outgrow an enclosure, you loose almost all typical Egenera benefits. And an upgrade of the backplane looks urgend to me, if you consider the processing and I/O capabilities of what can be put in to a blade these days. Considering the initial investment and the vendor lock-in risk, it simply doesn&#8217;t seem an acceptable risk, unless you need to replace a couple of thousand servers in a hurry. 3 leaf systems Infiniband based V-8000 server and now DCE simply offer a far easier migration path towards unified wire and far less dependency on a single vendor.<br />
That&#8217;s why I welcome your tendency to develop your PAN manager into a generic data center operating system, that is hardware and hypervisor agnostic and your willingness to license that. Going further down the proprietary hardware road seems like a sure way into oblivition to me.</p>
<p>Regards, Thomas</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: sekTallulk</title>
		<link>http://blog.egenera.com/2008/06/shall-we-%e2%80%9cconverge%e2%80%9d/#comment-6</link>
		<dc:creator>sekTallulk</dc:creator>
		<pubDate>Sun, 03 Aug 2008 21:08:31 +0000</pubDate>
		<guid isPermaLink="false">http://blog.egenera.com/?p=72#comment-6</guid>
		<description>Thanks for the post</description>
		<content:encoded><![CDATA[<p>Thanks for the post</p>
]]></content:encoded>
	</item>
</channel>
</rss>
