<?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: Sun&#8217;s storage announcement</title>
	<atom:link href="http://storagemojo.com/2007/10/04/suns-storage-announcement/feed/" rel="self" type="application/rss+xml" />
	<link>http://storagemojo.com/2007/10/04/suns-storage-announcement/</link>
	<description>Data storage info &#38; analysis</description>
	<pubDate>Fri, 21 Nov 2008 23:48:00 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: Robin Harris</title>
		<link>http://storagemojo.com/2007/10/04/suns-storage-announcement/#comment-129820</link>
		<dc:creator>Robin Harris</dc:creator>
		<pubDate>Fri, 05 Oct 2007 22:11:55 +0000</pubDate>
		<guid isPermaLink="false">http://storagemojo.com/2007/10/04/suns-storage-announcement/#comment-129820</guid>
		<description>Mark,

I like your analysis. I hope Jonathan gets the time to make the strategy work.

As for the A5000. . . .

I was the product and marketing manager for the A5000. I wrote the product requirements document - which included a requirement for a RAID controller - but the decision was made to use Veritas software RAID. At that point, before the OpenVision acquisition, the Veritas guys had very little knowledge of the enterprise and were pretty cavalier about testing. The RAID controller would have saved a lot of headaches. Sun did rush out an s-bus write cache card, but that wasn't much help.

Later I and the engineering team tried to get a switch option for the A5000, essential for tracking down problems in a big FC-AL system. Again, no dice, only a little hub that carefully propagated any problems.

I have to differ with you on the Encore front end - maybe someone entertained that idea, but the Encore code never got beyond Alpha quality - as the return of every unit proved. I worked on a similar idea using Sun servers, but the I/O limitations of the servers made it un-economic, as I think IBM's Shark guys finally concluded as well.

The storage group had multiple opportunities to build on their FC leadership and refused them all. Why a company with the hardware expertise required for SunFire and the software expertise for Solaris couldn't build a decent storage controller has always been a mystery to me. The A5000 problems were a symptom of a deeper problem: the inability of upper management to make good business decisions. I lay it at Scott's door - he just never got storage despite all the money it made Sun. Weird.

The good news is that they have a second bite at the apple and, other than EMC, are the best positioned to go after it in a big way. 

Robin</description>
		<content:encoded><![CDATA[<p>Mark,</p>
<p>I like your analysis. I hope Jonathan gets the time to make the strategy work.</p>
<p>As for the A5000. . . .</p>
<p>I was the product and marketing manager for the A5000. I wrote the product requirements document - which included a requirement for a RAID controller - but the decision was made to use Veritas software RAID. At that point, before the OpenVision acquisition, the Veritas guys had very little knowledge of the enterprise and were pretty cavalier about testing. The RAID controller would have saved a lot of headaches. Sun did rush out an s-bus write cache card, but that wasn&#8217;t much help.</p>
<p>Later I and the engineering team tried to get a switch option for the A5000, essential for tracking down problems in a big FC-AL system. Again, no dice, only a little hub that carefully propagated any problems.</p>
<p>I have to differ with you on the Encore front end - maybe someone entertained that idea, but the Encore code never got beyond Alpha quality - as the return of every unit proved. I worked on a similar idea using Sun servers, but the I/O limitations of the servers made it un-economic, as I think IBM&#8217;s Shark guys finally concluded as well.</p>
<p>The storage group had multiple opportunities to build on their FC leadership and refused them all. Why a company with the hardware expertise required for SunFire and the software expertise for Solaris couldn&#8217;t build a decent storage controller has always been a mystery to me. The A5000 problems were a symptom of a deeper problem: the inability of upper management to make good business decisions. I lay it at Scott&#8217;s door - he just never got storage despite all the money it made Sun. Weird.</p>
<p>The good news is that they have a second bite at the apple and, other than EMC, are the best positioned to go after it in a big way. </p>
<p>Robin</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark</title>
		<link>http://storagemojo.com/2007/10/04/suns-storage-announcement/#comment-129798</link>
		<dc:creator>Mark</dc:creator>
		<pubDate>Fri, 05 Oct 2007 21:35:19 +0000</pubDate>
		<guid isPermaLink="false">http://storagemojo.com/2007/10/04/suns-storage-announcement/#comment-129798</guid>
		<description>"We think what Google and Amazon are doing, integrating cheap storage into Internet-scale systems, is the future. And we’re SOL in the present."

Excellent observation.  I recently spoke to a friend who works at Sun, and think I finally understand Jonathan Schwartz's strategy.  It is to target the "next big thing", while managing the current thing and the installed base a well as possible.

"10 years ago the A5000 FC array rocketed to a $750,000,000 run rate in two quarters - almost an order of magnitude better."

True, but the A5000 also caused most of Sun's problems in storage today.  The A5000 had serious reliability problems, in large part because it simply overpowered the capacity of early Fibre-Channel infrastructure.  These problems disrupted Sun's R&#38;D away from the plan to create an Encore derived HW RAID front end for the A5000 JBODs.  Even after the "Photon" matured with the A5200, as an uncached JBOD, it was unsuitable for OLTP ERP databases, significantly disappointing customers.

"The data center is sorely in need of re-invention, especially the storage piece. Who better to do it than the vendor with the least investment in the current paradigm?"

I 100% agree.

I think the future of data center networked storage is filesystem based, specifically parallel NFS.  I think technologies like FCoE are more likely to be enabling technologies for pNFS than a primary access technology on their own.

I believe Jonathan Schwartz has a "crazy like a fox" strategy.  I still think Sun has significant shortcomings in some areas, but I also think the ball is in Sun's court to become a major player in the next evolution of storage.</description>
		<content:encoded><![CDATA[<p>&#8220;We think what Google and Amazon are doing, integrating cheap storage into Internet-scale systems, is the future. And we’re SOL in the present.&#8221;</p>
<p>Excellent observation.  I recently spoke to a friend who works at Sun, and think I finally understand Jonathan Schwartz&#8217;s strategy.  It is to target the &#8220;next big thing&#8221;, while managing the current thing and the installed base a well as possible.</p>
<p>&#8220;10 years ago the A5000 FC array rocketed to a $750,000,000 run rate in two quarters - almost an order of magnitude better.&#8221;</p>
<p>True, but the A5000 also caused most of Sun&#8217;s problems in storage today.  The A5000 had serious reliability problems, in large part because it simply overpowered the capacity of early Fibre-Channel infrastructure.  These problems disrupted Sun&#8217;s R&amp;D away from the plan to create an Encore derived HW RAID front end for the A5000 JBODs.  Even after the &#8220;Photon&#8221; matured with the A5200, as an uncached JBOD, it was unsuitable for OLTP ERP databases, significantly disappointing customers.</p>
<p>&#8220;The data center is sorely in need of re-invention, especially the storage piece. Who better to do it than the vendor with the least investment in the current paradigm?&#8221;</p>
<p>I 100% agree.</p>
<p>I think the future of data center networked storage is filesystem based, specifically parallel NFS.  I think technologies like FCoE are more likely to be enabling technologies for pNFS than a primary access technology on their own.</p>
<p>I believe Jonathan Schwartz has a &#8220;crazy like a fox&#8221; strategy.  I still think Sun has significant shortcomings in some areas, but I also think the ball is in Sun&#8217;s court to become a major player in the next evolution of storage.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Oracle DBAs Should Care About Sun&#8217;s Storage and Server Group Merge. At Least For IT Architectural Reasons. &#171; Kevin Closson&#8217;s Oracle Blog: Platform, Storage &#38; Clustering Topics Related to Oracle Databases</title>
		<link>http://storagemojo.com/2007/10/04/suns-storage-announcement/#comment-129350</link>
		<dc:creator>Oracle DBAs Should Care About Sun&#8217;s Storage and Server Group Merge. At Least For IT Architectural Reasons. &#171; Kevin Closson&#8217;s Oracle Blog: Platform, Storage &#38; Clustering Topics Related to Oracle Databases</dc:creator>
		<pubDate>Thu, 04 Oct 2007 17:24:57 +0000</pubDate>
		<guid isPermaLink="false">http://storagemojo.com/2007/10/04/suns-storage-announcement/#comment-129350</guid>
		<description>[...] Oracle DBAs Should Care About Sun&#8217;s Storage and Server Group Merge. At Least For IT Architectural&#160;Reasons.   Published October 4th, 2007   oracle       Just a quick post here to point out an interesting StorageMojo.com blog entry about Jonathan Schwartz&#8217; blog entry announcing the server and storage group merge at Sun. It seems Robin Harris thinks it is too little, too late. I think it is a no-brainer and looks like a follow-the-leader move. [...]</description>
		<content:encoded><![CDATA[<p>[...] Oracle DBAs Should Care About Sun&#8217;s Storage and Server Group Merge. At Least For IT Architectural&nbsp;Reasons.   Published October 4th, 2007   oracle       Just a quick post here to point out an interesting StorageMojo.com blog entry about Jonathan Schwartz&#8217; blog entry announcing the server and storage group merge at Sun. It seems Robin Harris thinks it is too little, too late. I think it is a no-brainer and looks like a follow-the-leader move. [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 2.011 seconds -->
