Remember Larry, Darryl, and that other brother Darryl? The question, from our point of view, is: are we looking at Larry or one of the Darryl's? The question comes up again in an article in Fortune yesterday. The article argues that this is Darryl (one of them, anyway) we're dealing with, the one who cares only about software.
What's interesting is that among the commenters (by my count, the heavy majority agreeing with my thesis that Sun's value is the hardware business) is this link. In sum, Larry is calling IBM/DB2 out into the street for a gunfight. Which is the sheriff and which the bad guy?? Depends on which coast you live, I guess.
Larry has known for a long time that Oracle is faster than DB2, in the arenas he cares about. And that it is better adapted to the web world.
As I've said a few times: Larry has always wanted to bury the 370. With Sun's hardware business, he now has the equivalent of IBM's infrastructure. They've had that infrastructure, in one form or another, since the mid 1950's when Univac took months to decide on a name for their machine. That infrastructure has always been based on CPU's, files, and COBOL (on the mainframe, DB2 is just a veil over VSAM, which is one reason Oracle is a dog there; the notion that the 360 could do the full circle of computing from scientific to business didn't last very long ending with an early 370 one-off - it's a COBOL machine). Larry now has an infrastructure based on CPU's, a database, and java. IBM is facing the first threat to its mainframe cash cow, ever. Armonk, you have a problem.
28 August 2009
24 August 2009
A Bird on the Plate is Worth Two in the Cloud
There is a report today which amounts to a small, tiny, fledgling crow. Yummy, lightly saute'd with a good chianti.
It is a discussion of Clouding with SSD. As I have talked about here, I never expected Clouding to go SSD, just because the allure of Cloud is cheap and dirty. SSD is neither of those. Although, the justification given in the article is not the nirvana I have discussed, BCNF databases, but simple brute force speed with existing bloated data.
The discussion is also not a vindication of STEC, the loudest (well in some parts of the world, anyway) proponent. In fact, they talk about PCIe form factor, and that is in the wheelhouse of Fusion-io. My suspicion that the distributed machine with attached SSD in the PCIe slot will be at least as important as massive arrays of the EMC/IBM/Sun style looks to be getting stronger. Of course, it too could end up being a bit feathery in a few months.
The nature of the discussion is in terms, not of open Clouds (Amazon, et al), but of MySpace and the like. In other words, providers of Cloudy stuff to their own users. Who happen to want to store their data off-site. To me, that isn't quite what Cloud means, but redefining words to fit reality is characteristic.
I guess you can't have everything, but it does amount to a foot in the door. In time, the smart database folks will see the opportunity to have their cake and eat it too: SSD serving BCNF data will always be faster than serving the un-normalized stuff.
Another couple of steps forward.
It is a discussion of Clouding with SSD. As I have talked about here, I never expected Clouding to go SSD, just because the allure of Cloud is cheap and dirty. SSD is neither of those. Although, the justification given in the article is not the nirvana I have discussed, BCNF databases, but simple brute force speed with existing bloated data.
The discussion is also not a vindication of STEC, the loudest (well in some parts of the world, anyway) proponent. In fact, they talk about PCIe form factor, and that is in the wheelhouse of Fusion-io. My suspicion that the distributed machine with attached SSD in the PCIe slot will be at least as important as massive arrays of the EMC/IBM/Sun style looks to be getting stronger. Of course, it too could end up being a bit feathery in a few months.
The nature of the discussion is in terms, not of open Clouds (Amazon, et al), but of MySpace and the like. In other words, providers of Cloudy stuff to their own users. Who happen to want to store their data off-site. To me, that isn't quite what Cloud means, but redefining words to fit reality is characteristic.
I guess you can't have everything, but it does amount to a foot in the door. In time, the smart database folks will see the opportunity to have their cake and eat it too: SSD serving BCNF data will always be faster than serving the un-normalized stuff.
Another couple of steps forward.
18 August 2009
It was a Cloudy day, not a Sun was in the sky
Well, mangled Paul Simon a bit there, but this tid bit (via O'Reilly) from one Carl Hewitt set off the "The Thought Leaders Have Finally Figured Out the Obvious" bell:
As Jim Gray noted in "Distributed Computing Economics" (MSR-TR-2003-24) there is a growing imbalance between the computation power of billions of cores in aggregator datacenters and the relatively feeble fiber optic communications coming out of aggregator datacenters. This problem has now become so severe that Amazon has been forced to introduce a commercial service that lets users of their cloud import and export data through the post--as in, put it on storage devices and ship it by land, sea, or air.
For those who haven't been following along, I am among those who've been calling bullshit on the whole "we'll put our data in the (Amazon/Google/Microsoft/Grace L. Ferguson) cloud, save lots of money, and not have to worry about the annoying data any more" crowd. One needs to consider the bait and switch tactic of hucksters. Just because Google's motto is "don't be evil" doesn't mean they aren't. They are young and naive, and quite greedy. Their corporate clients are just greedy, and generally stupid. Witness the meltdown they have caused.
It used to be that business schools taught from a prime directive: don't buy (or outsource, same difference) your core competence. The same is true of your data. It is the life blood of your business (or life, if you are just a person). The dumbest thing you can do is hand it over to "the others". There will be hell to pay for those that do.
Read the article, and the comments. Some are intelligent, others very much less so.
An Update:
here is today's next step along the way to dissipating the Clouds so we have just the sky. The argument boils down to what those of us who were around when Service Bureaus (the real first one was created before my time by IBM) were all the rage: you can't have it both ways. You can't have interchangeable resources and anything like performance and security specific to each client. They all have to accept lunch as "Cheeseburger, Cheeseburger, no Coke, Pepsi", no hot dogs or quiche. And Cloud will fail for that reason. Well, it is failing in the sense that those who would be providers continue to backpedal. And they will keep doing it. Suits are such knuckleheads. How DID they get to make decisions?
Update II:
TheStreet.com has a story on 3 September about Boeing. Toward the end is this:
As far as the extensive 787 program outsourcing to suppliers, [CEO Jim] McNerney was asked whether he would do it the same way again. He said he would not.
As Jim Gray noted in "Distributed Computing Economics" (MSR-TR-2003-24) there is a growing imbalance between the computation power of billions of cores in aggregator datacenters and the relatively feeble fiber optic communications coming out of aggregator datacenters. This problem has now become so severe that Amazon has been forced to introduce a commercial service that lets users of their cloud import and export data through the post--as in, put it on storage devices and ship it by land, sea, or air.
For those who haven't been following along, I am among those who've been calling bullshit on the whole "we'll put our data in the (Amazon/Google/Microsoft/Grace L. Ferguson) cloud, save lots of money, and not have to worry about the annoying data any more" crowd. One needs to consider the bait and switch tactic of hucksters. Just because Google's motto is "don't be evil" doesn't mean they aren't. They are young and naive, and quite greedy. Their corporate clients are just greedy, and generally stupid. Witness the meltdown they have caused.
It used to be that business schools taught from a prime directive: don't buy (or outsource, same difference) your core competence. The same is true of your data. It is the life blood of your business (or life, if you are just a person). The dumbest thing you can do is hand it over to "the others". There will be hell to pay for those that do.
Read the article, and the comments. Some are intelligent, others very much less so.
An Update:
here is today's next step along the way to dissipating the Clouds so we have just the sky. The argument boils down to what those of us who were around when Service Bureaus (the real first one was created before my time by IBM) were all the rage: you can't have it both ways. You can't have interchangeable resources and anything like performance and security specific to each client. They all have to accept lunch as "Cheeseburger, Cheeseburger, no Coke, Pepsi", no hot dogs or quiche. And Cloud will fail for that reason. Well, it is failing in the sense that those who would be providers continue to backpedal. And they will keep doing it. Suits are such knuckleheads. How DID they get to make decisions?
Update II:
TheStreet.com has a story on 3 September about Boeing. Toward the end is this:
As far as the extensive 787 program outsourcing to suppliers, [CEO Jim] McNerney was asked whether he would do it the same way again. He said he would not.
13 August 2009
Two steps forward (one step back?)
In order to reach nirvana, fully normalized databases blazing through joined rows, it is necessary that application users, hardware vendors, and those vendors' suppliers all be enamoured of SSD. The issue has always been: which end of the string is the head and which the tail. In normal life, one can't push a string, only pull it. This argues for the notion that users must demand SSD systems rather than vendors offering them unbidden.
It seems to be working out the other way. May be.
We're most of the way through earnings season, and some clues are now evident. STEC is, by all lights, the pioneer in SSD at the enterprise level. They've been working on these devices since 2005, and have only now had significant shipments. They have been qualified to EMC, HP, IBM, Compellent, Hitachi, Fujitsu, Sun (that we know about). They've announced a $120 million deal with one of these, assumed to be EMC, to ship starting 3rd quarter.
STEC continues to claim that they are alone as enterprise SSD vendor. Intel's X-25 parts are user PC oriented. Fusion-io's part runs through the PCIe slot, rather then in a separate storage array. Texas Memory Systems has been building SSD (with DRAM for most of the time; they now have NAND parts) for enterprise machines for years.
What's kind of interesting is that STEC has just announced MLC based parts since "...several of our price-sensitive OEM customers are now looking for SSD alternatives which only a true MLC-based SSD can deliver...". What makes this interesting is that until this announcement, STEC was only talking about its SLC parts. Note that the NAND chips are sourced, not built by STEC. Samsung is the likely vendor; in any case, the MLC chips, which were heretofor said to be inferior for enterprise SSD are now kosher. This sounds to me to be a retrenchment; the "enterprise SSD" market wasn't quite as big as thought, or not so price inelastic as thought or ...
The implication is that machine vendors are not flocking to SSD, which means that users are not either. SSD is the future, and the future is closer than it appears in the mirror, but for SSD to be widely (and wildly) successful, it has to be part of a refactoring of the supported datastore. SSD will never be price or data density competitive with spinning rust. Efficiency (an order of magnitude less data retrieved faster) is the big win.
EMC, IBM, and Compellent have reported, and gave guidance for 3rd quarter that isn't skyrocketing. Whether Sun will be serious in the hardware segment under Uncle Larry is still moot; I've bet that hardware is the reason for the purchase, but we'll see. If so, then STEC will benefit. In all for the near term STEC, Intel, Fusion-io, et al are not looking like saloons in a mining town.
Get out there and push for 3NF. It's the only way to fly.
It seems to be working out the other way. May be.
We're most of the way through earnings season, and some clues are now evident. STEC is, by all lights, the pioneer in SSD at the enterprise level. They've been working on these devices since 2005, and have only now had significant shipments. They have been qualified to EMC, HP, IBM, Compellent, Hitachi, Fujitsu, Sun (that we know about). They've announced a $120 million deal with one of these, assumed to be EMC, to ship starting 3rd quarter.
STEC continues to claim that they are alone as enterprise SSD vendor. Intel's X-25 parts are user PC oriented. Fusion-io's part runs through the PCIe slot, rather then in a separate storage array. Texas Memory Systems has been building SSD (with DRAM for most of the time; they now have NAND parts) for enterprise machines for years.
What's kind of interesting is that STEC has just announced MLC based parts since "...several of our price-sensitive OEM customers are now looking for SSD alternatives which only a true MLC-based SSD can deliver...". What makes this interesting is that until this announcement, STEC was only talking about its SLC parts. Note that the NAND chips are sourced, not built by STEC. Samsung is the likely vendor; in any case, the MLC chips, which were heretofor said to be inferior for enterprise SSD are now kosher. This sounds to me to be a retrenchment; the "enterprise SSD" market wasn't quite as big as thought, or not so price inelastic as thought or ...
The implication is that machine vendors are not flocking to SSD, which means that users are not either. SSD is the future, and the future is closer than it appears in the mirror, but for SSD to be widely (and wildly) successful, it has to be part of a refactoring of the supported datastore. SSD will never be price or data density competitive with spinning rust. Efficiency (an order of magnitude less data retrieved faster) is the big win.
EMC, IBM, and Compellent have reported, and gave guidance for 3rd quarter that isn't skyrocketing. Whether Sun will be serious in the hardware segment under Uncle Larry is still moot; I've bet that hardware is the reason for the purchase, but we'll see. If so, then STEC will benefit. In all for the near term STEC, Intel, Fusion-io, et al are not looking like saloons in a mining town.
Get out there and push for 3NF. It's the only way to fly.
Subscribe to:
Posts (Atom)