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.
18 July 2009
Common Sense isn't always common
I have been meaning to write about common table expressions (CTE), since this syntax (sugar, some say) explicitly implements hierarchies, and given the reactionaries out there pining for IMS and such won't be quiet. I first used them on DB2/LUW years ago. SQLServer 2005 added support, and now Postgres 8.4 has, too. Oracle has had its CONNECT BY syntax much longer. CTE syntax got added to SQL-2003.
I read various database sites and blogs; among my favorites is PostgreSQL.org. (Note to self; add to Good Stuff.) It has a rotating set of links, and today there is an article discussing CTE in postgres. Since I haven't got around to installing 8.4 yet, the work is done for me. Read it. The article compares using CTE versus functions, which is a neat idea in and of itself. They demonstrate that CTE can run faster than standard syntax on a HDD machine. Very neat.
CTE is germane to the main point of this endeavor, SSD multi-machines, since a CTE is just massive joining behind the scenes. You get the point. What would be somewhat inefficient on HDD, becomes trivial on SSD. One more reason to put 1960's datastore behind. Paul McCartney played on the marquis of the Ed Sullivan theater a few days ago, but he still looked as ancient as Ozzie Osbourne. Hierarchy is from the same time. Dump it. XML is IMS in drag; all sequins and rhinestones.
I read various database sites and blogs; among my favorites is PostgreSQL.org. (Note to self; add to Good Stuff.) It has a rotating set of links, and today there is an article discussing CTE in postgres. Since I haven't got around to installing 8.4 yet, the work is done for me. Read it. The article compares using CTE versus functions, which is a neat idea in and of itself. They demonstrate that CTE can run faster than standard syntax on a HDD machine. Very neat.
CTE is germane to the main point of this endeavor, SSD multi-machines, since a CTE is just massive joining behind the scenes. You get the point. What would be somewhat inefficient on HDD, becomes trivial on SSD. One more reason to put 1960's datastore behind. Paul McCartney played on the marquis of the Ed Sullivan theater a few days ago, but he still looked as ancient as Ozzie Osbourne. Hierarchy is from the same time. Dump it. XML is IMS in drag; all sequins and rhinestones.
16 July 2009
Sunrise, Sunset. Game, Set, Match. Part 2.
As (what now turns out to be) Part 1 began:
Well, the other shoe dropped. Oracle has bid for Sun. In my tracking of speculation, Oracle had more weight than IBM. And so it has turned out. This might end up being a problem for IBM.
The buyout/merger/lunch is official (so far as shareholders go; DoJ might vomit, but we'll have to wait on that) today, and since yesterday's post about file systems is still fresh in my brain, I thought I'd take a minute or two to expand on why I believe Oracle wants Sun.
It's not java.
It never was java, to my way of thinking. So, here's my way of thinking.
Larry has been buying up applications for a few years. What to do next? Or should he just keep doing that? What is the next Everest?
IBM has been diligent in transforming itself (as has GE, by the way) from a maker of things to a finance and body shop. The reason for doing so is apparent: services require little (real) capital investment. All you do is rent some office space, some computer time (or cloud it? may be that, too), find some minimally competent bodies; and sell the hell out of the "organization". IBM was, is, and always will be, a sales organization. It needed mainframes in the beginning because the US economy had not yet made the transition to de-industrialization (2007: 40% of corporate profit is finance). And to that point, the company had a history of making bespoke machines; in no small motivation to lock-in its customers. Sales staff's major duty was "client management"; squeeze the last dollar out of each of them, and make damn sure clients didn't go someplace else.
The last place that Larry has not been able to take Oracle (the database) is the IBM mainframe. There are technical reasons (mostly due to how IBM designed those things decades ago) why Oracle has never run all that well on the IBM mainframe. Consider that rather than try to climb Everest, may be you could nuke the sucker, stroll over the debris and say that you've climbed Everest. Kind of true.
How, then, does Larry nuke IBM on the mainframe? That's where Sun comes in. Rather than trying to get Oracle (the database) to run as well on the mainframe doing COBOL support as DB2 does, why not build an alternative which is cheaper, faster, easier, and runs Oracle? Cool. Oracle and Sun have been together for years. Now Larry can get the hardware folks to do exactly what he wants. He has HP doing sort of what he wants; but he doesn't own them. And the Sun processors, some tech folk assert, are better than what IBM now uses.
Which brings us to btrfs. It was developed by Oracle, then open sourced. It is still under development, but if you read the site, you find that SSD support is what it's about. He'll have a machine with SSD and a file system tuned for them, running his database. He can make a compelling TCO argument that converting antique COBOL/VSAM applications to his super hot-rod database machine is a slam dunk. You heard it here first.
As I have been saying, SSD multi-core multi-processor high normal form database machines are the most cost effective way to handle data. The more I learn about what Larry is up to, the more convinced I am that this is where he's taking Oracle. I couldn't be happier.
Well, the other shoe dropped. Oracle has bid for Sun. In my tracking of speculation, Oracle had more weight than IBM. And so it has turned out. This might end up being a problem for IBM.
The buyout/merger/lunch is official (so far as shareholders go; DoJ might vomit, but we'll have to wait on that) today, and since yesterday's post about file systems is still fresh in my brain, I thought I'd take a minute or two to expand on why I believe Oracle wants Sun.
It's not java.
It never was java, to my way of thinking. So, here's my way of thinking.
Larry has been buying up applications for a few years. What to do next? Or should he just keep doing that? What is the next Everest?
IBM has been diligent in transforming itself (as has GE, by the way) from a maker of things to a finance and body shop. The reason for doing so is apparent: services require little (real) capital investment. All you do is rent some office space, some computer time (or cloud it? may be that, too), find some minimally competent bodies; and sell the hell out of the "organization". IBM was, is, and always will be, a sales organization. It needed mainframes in the beginning because the US economy had not yet made the transition to de-industrialization (2007: 40% of corporate profit is finance). And to that point, the company had a history of making bespoke machines; in no small motivation to lock-in its customers. Sales staff's major duty was "client management"; squeeze the last dollar out of each of them, and make damn sure clients didn't go someplace else.
The last place that Larry has not been able to take Oracle (the database) is the IBM mainframe. There are technical reasons (mostly due to how IBM designed those things decades ago) why Oracle has never run all that well on the IBM mainframe. Consider that rather than try to climb Everest, may be you could nuke the sucker, stroll over the debris and say that you've climbed Everest. Kind of true.
How, then, does Larry nuke IBM on the mainframe? That's where Sun comes in. Rather than trying to get Oracle (the database) to run as well on the mainframe doing COBOL support as DB2 does, why not build an alternative which is cheaper, faster, easier, and runs Oracle? Cool. Oracle and Sun have been together for years. Now Larry can get the hardware folks to do exactly what he wants. He has HP doing sort of what he wants; but he doesn't own them. And the Sun processors, some tech folk assert, are better than what IBM now uses.
Which brings us to btrfs. It was developed by Oracle, then open sourced. It is still under development, but if you read the site, you find that SSD support is what it's about. He'll have a machine with SSD and a file system tuned for them, running his database. He can make a compelling TCO argument that converting antique COBOL/VSAM applications to his super hot-rod database machine is a slam dunk. You heard it here first.
As I have been saying, SSD multi-core multi-processor high normal form database machines are the most cost effective way to handle data. The more I learn about what Larry is up to, the more convinced I am that this is where he's taking Oracle. I couldn't be happier.
File Systems for SSD are here
I have no idea how many folks really notice the quotes at the top of this endeavor, nevertheless, I have found a recent article which talks about Linux file systems. The interviewee (if that's a real word) has worked on writing file systems for Linux, and has the following (page 2) to say about SSD and file systems:
With regard to local file systems, I think btrfs is flexible enough to handle any projected hardware changes for the next decade, both in performance and capacity - in other words, SSDs and truly enormous quantities of storage. I also think we may see more flash-based devices exporting access to the hardware directly as the SSD market commoditizes, in which case LogFS and NILFS become even more interesting, perhaps as part of an open source wear-leveling layer that can integrate tightly with other Linux file systems.
So, the future is here. For information about btrfs, see Wikipedia for a start (SSD is explicitly supported).
tick, tock. what's up Doc?
With regard to local file systems, I think btrfs is flexible enough to handle any projected hardware changes for the next decade, both in performance and capacity - in other words, SSDs and truly enormous quantities of storage. I also think we may see more flash-based devices exporting access to the hardware directly as the SSD market commoditizes, in which case LogFS and NILFS become even more interesting, perhaps as part of an open source wear-leveling layer that can integrate tightly with other Linux file systems.
So, the future is here. For information about btrfs, see Wikipedia for a start (SSD is explicitly supported).
tick, tock. what's up Doc?
Subscribe to:
Posts (Atom)