Lordy, lordy, I've found my Prince Charming. Well, in the sense of a soul mate who understands what's going on with Oracle, and why. He doesn't delve into the ultimate goal: the IBM mainframe customer base, but he gets it.
Have a read. While not a Goldman analyst, only a The Street columnist, he should qualify as a Mainstream Pundit. I think so anyway. He's cute. Got good eyes and nice hair.
The key point is understanding that Cloud is a highly fungible term. While some define it as a resource farm used by scads of unaffiliated applications (typically, Public Cloud), Larry understands that it just means centralized data and thin (even, dare we say it, dumb) terminals. Whether the resources are "Public", ala Amazon/Google/FooBar, or "Private", ala XYZ corporate computing infrastructure, it's all about location, location, location. From Larry's point of view that means an Oracle database sitting somewhere; may be even an Oracle datacenter. Running all that newly announced integrated applications.
27 September 2010
22 September 2010
Paranoia Strikes Armonk
Since Oracle bought Sun, I've been (uniquely, so far as I know) insisting that Larry's goal was to suck up IBM's mainframe clients, since they're the last significant number (and of really good size) of "legacy" installs to be had. Until today, the Usual Pundits haven't agreed. Ah, but news is news.
Today's Times tells us about the annual lovefest, and in the process, explicates Larry's goal. Following are a couple of quotes.
"But through its acquisition spree, Oracle moved well beyond the database and into business software, buying up the important products that companies use to keep track of their technology infrastructure, employees, sales, inventory and customers."
IBM did this in the mainframe world, initially by supplying the applications themselves. Once they killed off the Seven Dwarves (wikipedia for: IBM Seven Dwarves, for a decent bit of history), and the DoJ got under their saddle, letting software vendors work on the machines was allowed. Larry's strategy was clear before, but can't be ignored now: buy up the Oracle based application software used by the Fortune X00 (and let your fingers do the searching for how well that's gone for the clients of the bought out companies), then build a machine that's tied to the database. Just what IBM has, for now at least.
"With Sun, Oracle has found a way to sell customers hardware bundled with all that software in a fashion similar to that of its main database rival, I.B.M. Oracle executives say they can build better, faster, cheaper products this way by engineering complete systems rather than requiring customers to cobble together the parts."
Well, monocultures (the term often used to describe Windows, and explain the virus vulnerability of it) are never a good thing.
"But customers are objecting to Oracle's moves. For example, some of Sun's largest former customers consist of the large Wall Street players, and they pushed back this year when Oracle moved to limit their choices around the Sun technology. Oracle ultimately gave in to their pleas, reaffirming deals that would let Hewlett-Packard and Dell offer prized Sun software on their hardware."
That first picture in the article is the newest toy, the Exalogic machine. Letting my fingers do the searching, I came up with this Oracle page. Of note; it's built on SSD. Armonk, we have an attack!!
Today's Times tells us about the annual lovefest, and in the process, explicates Larry's goal. Following are a couple of quotes.
"But through its acquisition spree, Oracle moved well beyond the database and into business software, buying up the important products that companies use to keep track of their technology infrastructure, employees, sales, inventory and customers."
IBM did this in the mainframe world, initially by supplying the applications themselves. Once they killed off the Seven Dwarves (wikipedia for: IBM Seven Dwarves, for a decent bit of history), and the DoJ got under their saddle, letting software vendors work on the machines was allowed. Larry's strategy was clear before, but can't be ignored now: buy up the Oracle based application software used by the Fortune X00 (and let your fingers do the searching for how well that's gone for the clients of the bought out companies), then build a machine that's tied to the database. Just what IBM has, for now at least.
"With Sun, Oracle has found a way to sell customers hardware bundled with all that software in a fashion similar to that of its main database rival, I.B.M. Oracle executives say they can build better, faster, cheaper products this way by engineering complete systems rather than requiring customers to cobble together the parts."
Well, monocultures (the term often used to describe Windows, and explain the virus vulnerability of it) are never a good thing.
"But customers are objecting to Oracle's moves. For example, some of Sun's largest former customers consist of the large Wall Street players, and they pushed back this year when Oracle moved to limit their choices around the Sun technology. Oracle ultimately gave in to their pleas, reaffirming deals that would let Hewlett-Packard and Dell offer prized Sun software on their hardware."
That first picture in the article is the newest toy, the Exalogic machine. Letting my fingers do the searching, I came up with this Oracle page. Of note; it's built on SSD. Armonk, we have an attack!!
16 September 2010
Be Careful What You Wish For
As the saying goes, "Be careful what you wish for, you just might get it". I was visiting one of my favorite SSD sites, storagesearch.com, which led me to Solid Access, the text under the Technology tab. In their spiel was this:
I/O acceleration is achieved in applications by off-loading I/O-demanding files ("hot files", typically less than 5% of the content) onto an SSD for processing at RAM speed and using mechanical disks (or RAIDs) to process the remaining "cold files". This instantly improves the efficiency of the application servers by recovering CPU cycles formerly lost in I/O wait loops.
Why did this get my attention, you may ask? I will answer. Well, duh! Of course! Multiprogramming, even on multicore/processor hardware, depends on "idle" cycles, and such idle cycles predominantly derive from I/O waits. Mainframers learned this in the 1960's. If there is a proliferation of SSDs, whether my version where SSD is the sole storage medium, or the case where SSD is merely cache, one will see a reduction of I/O waits. Multiprogramming becomes much more problematic, expensive, and delicate, in this circumstance.
With I/O waits, scheduling is easy (well, as easy as that sort of thing gets); the application that *can't* do anything is skipped in favor of one which can use the cpu. What happens when all applications the OS sees are ready and rarin' to go? Algorithms will need to be developed which rank applications' priorities, somehow or another. Do the order entry folks get priority, or the accountants updating the GL? Who's the top dog?
*nix operating systems have nice, but nice, ultimately, depends on human intervention. I'd wager that nice is unknown to most coders whose work ends up on *nix systems. It's going to be interesting.
I just let my fingers do the searching, and found this article, which does mention SSD and scheduling together, although I don't see any direct discussion of removing I/O waits and multiprogramming. So, there is some consideration out in the literature; this paper is March, 2010.
We aren't in Kansas anymore. SSD proliferation may mean that multiprogramming is passe'; each core/processor will be dedicated to an application/process, since there isn't exploitable I/O wait in the machine anymore. If storage is on PCIe, or similar, I/O wait gets yet slimmer. Oh my! OS's would be greatly simplified, since multiprogramming support is the gnarliest part of any industrial strength OS.
What about database engines? They act like an OS, in that they have much the same responsibility: serving multiple clients, although the clients' needs are constrained. In the old days, there were Pick and AS/400; "integrated" OS and database. Could we see linux/db in the next few years? Might be. It's been accepted wisdom in the *nix world for many years that one should reduce, or even eliminate, OS buffering in favor of the database doing all of that itself; after all, what point is there to having multiple memory images of a file that's only of interest to the engine? Hmm.
I/O acceleration is achieved in applications by off-loading I/O-demanding files ("hot files", typically less than 5% of the content) onto an SSD for processing at RAM speed and using mechanical disks (or RAIDs) to process the remaining "cold files". This instantly improves the efficiency of the application servers by recovering CPU cycles formerly lost in I/O wait loops.
Why did this get my attention, you may ask? I will answer. Well, duh! Of course! Multiprogramming, even on multicore/processor hardware, depends on "idle" cycles, and such idle cycles predominantly derive from I/O waits. Mainframers learned this in the 1960's. If there is a proliferation of SSDs, whether my version where SSD is the sole storage medium, or the case where SSD is merely cache, one will see a reduction of I/O waits. Multiprogramming becomes much more problematic, expensive, and delicate, in this circumstance.
With I/O waits, scheduling is easy (well, as easy as that sort of thing gets); the application that *can't* do anything is skipped in favor of one which can use the cpu. What happens when all applications the OS sees are ready and rarin' to go? Algorithms will need to be developed which rank applications' priorities, somehow or another. Do the order entry folks get priority, or the accountants updating the GL? Who's the top dog?
*nix operating systems have nice, but nice, ultimately, depends on human intervention. I'd wager that nice is unknown to most coders whose work ends up on *nix systems. It's going to be interesting.
I just let my fingers do the searching, and found this article, which does mention SSD and scheduling together, although I don't see any direct discussion of removing I/O waits and multiprogramming. So, there is some consideration out in the literature; this paper is March, 2010.
We aren't in Kansas anymore. SSD proliferation may mean that multiprogramming is passe'; each core/processor will be dedicated to an application/process, since there isn't exploitable I/O wait in the machine anymore. If storage is on PCIe, or similar, I/O wait gets yet slimmer. Oh my! OS's would be greatly simplified, since multiprogramming support is the gnarliest part of any industrial strength OS.
What about database engines? They act like an OS, in that they have much the same responsibility: serving multiple clients, although the clients' needs are constrained. In the old days, there were Pick and AS/400; "integrated" OS and database. Could we see linux/db in the next few years? Might be. It's been accepted wisdom in the *nix world for many years that one should reduce, or even eliminate, OS buffering in favor of the database doing all of that itself; after all, what point is there to having multiple memory images of a file that's only of interest to the engine? Hmm.
15 September 2010
Watch Yourself, Streak
A few posts ago I predicted that the emergence of iPad (and similar) would bring the warehouse tablet paradigm into wider use. I also predicted that such use (being at much smaller dimensions) is a perfect opportunity for BCNF databased systems to prosper at the expense of flatfile bloatware.
Well, Dell is pushing Streak for medical uses. Boy howdy. Head 'em up, move 'em out. Real databases will win.
Now, if I can just find some folks in this benighted neck of the woods who've figured it out, too.
Well, Dell is pushing Streak for medical uses. Boy howdy. Head 'em up, move 'em out. Real databases will win.
Now, if I can just find some folks in this benighted neck of the woods who've figured it out, too.
10 September 2010
What Am I Bid for This Fair Maiden????
There's movement in the storage bin, these days. I missed out on the 3Par explosion, by a few hours. Alas. Today brings STEC into the buyout rumour factory.
Such a wonderful opportunity to speculate on the future, and I won't refuse.
The assumed buyers are Dell, IBM, Oracle, EMC. I'm not convinced that any buyout is in the making, so I didn't go and buy more. My reasoning is simple: I've not seen any evidence that any of the assumed players (nor any other) understand that flash SSD is useful for relational databases, done as Dr. Codd instructed. As generic byte storage, nope. The assumed players, especially Dell and EMC, haven't said or done anything to indicate they've made the connection.
The lack of connection is not surprising, since BCNF data storage means either green field development (a small corner of the enterprise space which consists largely of running 40 year old COBOL through DB2 or Oracle, stuffed full of simpleminded files), or refactoring those file image databases to BCNF (or something that looks an awful lot like that). Enterprises don't do that sort of thing. Mark Hurd (you've heard of him?) made HP "profitable" by cutting out any activity that smacked of R&D or innovation. Larry just hired him, so that tells you all you need to know about whether Oracle would embrace SSD.
That leaves IBM as possible buyer. STEC is qualified to IBM now. Why would a non-storage company (IBM or Oracle or ...) want to own STEC? The only rational reason is to own the controller IP STEC has established, and either take it off the market or re-price it significantly higher. Re-pricing is a non-starter. There are a number of, and growing, controller vendors, taking ever more clever approaches. Fusion-io is one; SandForce another. STEC's "enterprise" controller is generally believed to be superior, and has replaced other vendors. On the other hand, STEC has been pushing its lower performing drives, the Mach class, presumably due to customer pressure to move lower priced parts. The Zeus parts have higher margins; STEC has admitted that.
IBM buying STEC would be a watershed event. The company has been shedding physical production for the better part of a decade, as a result bringing production in house would be immense. They aren't likely to do that in order to sell the parts; I just don't see that. We're left with sequestering STEC controller technology in IBM. Could they break supply contracts with EMC, et al? Probably not. If they could make STEC exclusive to IBM, how would they exploit exclusive access to STEC tech? Again, SSD isn't competitive for massive byte store. The only way is to push the RELATIONAL part of RDBMS. IBM hasn't shown that they get it. Most of their database revenue (and virtually all of that growth over the last decade) has come from moving Fortune X00 companies from COBOL/VSAM to COBOL/DB2. Such companies aren't interested in doing anything more than getting the bytes from VSAM to DB2; DCLGEN is the extent of the database design.
So, in the end, while it would make me a few bucks and rock my world, I don't see IBM buying STEC. Dell or EMC wouldn't make any material difference, while Oracle has Sun's quasi-SSD flash appliance already.
Tempest in a teapot.
Such a wonderful opportunity to speculate on the future, and I won't refuse.
The assumed buyers are Dell, IBM, Oracle, EMC. I'm not convinced that any buyout is in the making, so I didn't go and buy more. My reasoning is simple: I've not seen any evidence that any of the assumed players (nor any other) understand that flash SSD is useful for relational databases, done as Dr. Codd instructed. As generic byte storage, nope. The assumed players, especially Dell and EMC, haven't said or done anything to indicate they've made the connection.
The lack of connection is not surprising, since BCNF data storage means either green field development (a small corner of the enterprise space which consists largely of running 40 year old COBOL through DB2 or Oracle, stuffed full of simpleminded files), or refactoring those file image databases to BCNF (or something that looks an awful lot like that). Enterprises don't do that sort of thing. Mark Hurd (you've heard of him?) made HP "profitable" by cutting out any activity that smacked of R&D or innovation. Larry just hired him, so that tells you all you need to know about whether Oracle would embrace SSD.
That leaves IBM as possible buyer. STEC is qualified to IBM now. Why would a non-storage company (IBM or Oracle or ...) want to own STEC? The only rational reason is to own the controller IP STEC has established, and either take it off the market or re-price it significantly higher. Re-pricing is a non-starter. There are a number of, and growing, controller vendors, taking ever more clever approaches. Fusion-io is one; SandForce another. STEC's "enterprise" controller is generally believed to be superior, and has replaced other vendors. On the other hand, STEC has been pushing its lower performing drives, the Mach class, presumably due to customer pressure to move lower priced parts. The Zeus parts have higher margins; STEC has admitted that.
IBM buying STEC would be a watershed event. The company has been shedding physical production for the better part of a decade, as a result bringing production in house would be immense. They aren't likely to do that in order to sell the parts; I just don't see that. We're left with sequestering STEC controller technology in IBM. Could they break supply contracts with EMC, et al? Probably not. If they could make STEC exclusive to IBM, how would they exploit exclusive access to STEC tech? Again, SSD isn't competitive for massive byte store. The only way is to push the RELATIONAL part of RDBMS. IBM hasn't shown that they get it. Most of their database revenue (and virtually all of that growth over the last decade) has come from moving Fortune X00 companies from COBOL/VSAM to COBOL/DB2. Such companies aren't interested in doing anything more than getting the bytes from VSAM to DB2; DCLGEN is the extent of the database design.
So, in the end, while it would make me a few bucks and rock my world, I don't see IBM buying STEC. Dell or EMC wouldn't make any material difference, while Oracle has Sun's quasi-SSD flash appliance already.
Tempest in a teapot.
01 September 2010
Touching Me, Touching You (Second Chorus)
Diligent readers know that, while this endeavor began with my having some free time to make a public stand for the full relational model/database due to the availability of much less expensive flash SSD (compared to DRAM SSD, which have been around for decades) in a "normal" OLTP application, the world changed a bit from then to now. In particular, the iPad. I've mentioned the implications in earlier postings.
Now, as regular readers know, the iPad is not especially new, from a semantic point of view. Tablets have been in use in warehouse software applications (MRP/ERP/Distribution) for a very long time. (This is just a current version.) I programmed with them in the early '90s.
But the iPad does mean that mainstream software now has a new input semantic to deal with: touch me, touch me, not my type. So, it was with some amusement that I saw this story in today's NY Times. Small-ish touch screens means small bytes of data, a bit at a time. The 100 field input screen that's been perpetuated (in no small measure as a result of the Fortune X00 penchant for "porting" 1970's COBOL screens to java or php) now for what seems like forever is headed the way of the dodo. It simply won't work. And the assumption that "well, we'll just 'break up' those flatfiles into 'sections'" will fail miserably. There'll be deadlocks, livelocks, and collisions till the cows come home.
BCNF schemas, doled out in "just the right size" to Goldilocks, is the way forward. Very cool.
Now, as regular readers know, the iPad is not especially new, from a semantic point of view. Tablets have been in use in warehouse software applications (MRP/ERP/Distribution) for a very long time. (This is just a current version.) I programmed with them in the early '90s.
But the iPad does mean that mainstream software now has a new input semantic to deal with: touch me, touch me, not my type. So, it was with some amusement that I saw this story in today's NY Times. Small-ish touch screens means small bytes of data, a bit at a time. The 100 field input screen that's been perpetuated (in no small measure as a result of the Fortune X00 penchant for "porting" 1970's COBOL screens to java or php) now for what seems like forever is headed the way of the dodo. It simply won't work. And the assumption that "well, we'll just 'break up' those flatfiles into 'sections'" will fail miserably. There'll be deadlocks, livelocks, and collisions till the cows come home.
BCNF schemas, doled out in "just the right size" to Goldilocks, is the way forward. Very cool.
Subscribe to:
Posts (Atom)