Oracle’s hardware strategy
Larry Ellison stated clearly in an email interview with Reuters (links here and here) that Oracle intends to keep Sun’s hardware business and indeed intends to invest in the SPARC chip. Naturally, I have a few thoughts about this.
As Stephen O’Grady points out, Sun’s main strength lay in selling to the large enterprise market. Well, that’s Oracle’s overwhelming focus too. As I noted two years ago:
One Oracle response is to provide lots of add-on technologies for high-end customers, on the database and middle tiers alike. In app servers it’s done surprisingly well against BEA. It’s sold a lot of clustering. And it’s bought into and tried to popularize niche technologies like TimesTen and Tangosol’s.
This all makes perfect sense – it’s a great fit for Oracle’s best customers, and a way to get thousands of extra dollars per server from enterprises that may already have bought all-you-can-eat licenses to the Oracle DBMS. And being so sensible, it fits into the Clayton Christensen disruption story in two ways:
Oracle may be helpless against mid-tier competition, but it sure has the high-end core of its market locked up.
- As one type of technology is commoditized, value is created in other parts of the technology stack.
Oracle’s ongoing acquisition spree in system software, application software, and now hardware just supports that story. MySQL, embedded Java, and so on may be welcome to Oracle as yet more opportunities to tap additional markets — but Oracle’s emphasis is and surely will remain on the large enterprise market.
The next notable point may be found in Larry’s key quote:
… our primary reason for designing our own chips is to build computers with the very best performance, reliability and security available in the market. Some system features work much better if they are implemented in silicon rather than software. Once we own Sun, we’ll be able to plan and synchronize new features from silicon to software, just like IBM and the other big system suppliers. We want to work with Fujitsu to design advanced features into the SPARC microprocessor aimed at improving Oracle database performance. In my opinion, this will enable SPARC Solaris open-system mainframes and servers to challenge IBM’s dominance in the data center. Sun was very successful for a very long time selling computer systems based on the SPARC chip and the Solaris operating system. Now, with the added power of integrated Oracle software, we think they can be again.
Let’s examine that. There are almost no major examples of game-changing silicon-to-software enterprise server integrations. In particular, there aren’t at IBM, whose recent mainframe custom-processor offerings seem to do more as gimmicks to reduce software licensing cost than they do as genuine performance accelerators. And while Netezza and Teradata definitely have custom hardware architectures, they use off-the-shelf parts, including in the processor area.
True, there’s probably a cool story along the lines of highly parallelizing database execution on a single processor, ala Kickfire. But that would require a radical redesign of Oracle’s database software, which surely won’t happen, for two reasons:
- Difficulty.
- The need to keep running on non-Oracle hardware.
On the other hand, you don’t need a game-changing advantage to be the preferred hardware vendor; relatively small advantages are fine. While I don’t have stats, I’d guess IBM gets a lot of the hardware revenue underneath DB2. So the latter part of Larry’s quote, in which he emphasizes the benefit of Oracle’s software biz to Sun’s hardware biz — rather than vice-versa — is not at all implausible.
Finally, Larry said regarding Oracle Exadata:
Exadata is built by HP using Intel microprocessors. We have no plans for a SPARC Solaris version of Exadata. We have an excellent relationship with HP that we expect to continue. … The Sun acquisition doesn’t reduce our commitment to Exadata at all.
To interpret that, recall that the “Exadata” name applies just to the storage-tier part of the product, not the database-tier portion. I would be surprised to learn that Sun’s own storage products are based on SPARC rather than Intel processors. So the “have no plans” part of that quote may remain true for a good long time.
What’s more, it’s not obvious that Exadata will be a high-volume product. It’s very important for Oracle to succeed with Exadata, in order to maintain high-end account control. But there may not be a lot of profit opportunity in backstabbing HP on the Exadata hardware side, especially any time soon.
Comments
8 Responses to “Oracle’s hardware strategy”
Leave a Reply
Oracle has several internal inefficiencies in its database to insure cross platform compatibility. One good example is the inherently non-native base 100 format of the numbers it stores.
Maybe they’ll build a chip to deal with that.
What’s interesting is that for a long time Oracle favored the grid strategy – many small boxes rather than big systems. He points out Fujitsu as partner for SPARC. So that seems to me a shift in strategy as Fujitsu’s focus is on big boxes (SUN’s M systems). Also he doesn’t mention SUN’s own SPARC development efforts the T series. Not sure if this means anything.
As for MySQL – it could be that they use MySQL for the the SMB market. It might be feasable to run MySQL and Oracle DB as 2 very distinct products – kinda like Access and SQL server. (I am guessing here – of course)
What will Oracle do with Sun’s storage engine partner strategy?
Jeff,
I don’t think MySQL’s current helpful but otherwise hands-off approach is a good long-term match for Oracle’s approach to things.
Hence my multiple blog posts on related subjects.
CAM
>> there aren’t at IBM, whose recent mainframe custom-processor offerings seem to do more as gimmicks to reduce software licensing cost than they do as genuine performance accelerators
Last I checked, the z/Series processor had hardware BCD, and was alone as such. BCD is critical to COBOL code, which still exists and procreates by the millions each year. z/OS DB2 depends on this datatype and language; the relationship between z/OS DB2 and z/Series machines is either symbiotic or co-dependent, as your worldview determines. According to legend, Oracle is a mangy dog on z/Series.
Whether Oracle can spin SPARC machines, however massive, with Solaris as replacements for COBOL-z/OS-RACF-auditing-blah is questionable. About as likely as Rush planting a big juicy one on Michelle. My experience tells me that z/OS DB2 is mostly COBOL retro-fits, and Oracle doesn’t have any chance to move SPARC/Oracle machines there.
Larry’s delusional if he really thinks that getting Sun will enable him to displace existing applications written to DB2-z/Series.
>> I’d guess IBM gets a lot of the hardware revenue underneath DB2
If you’re referring to z/Series, I saw it the opposite: IBM moves dinosaur COBOL/VSAM code to “DB2” in order for clients to be able to PowerPoint that ABC application (first written in 1975, and maintained since) is now a “database application” because it now runs on DB2. Little to none of the RDBMS facilities are used. In other words, there’s no opportunity for SPARC/Oracle here. The folks who make applications for z/Series (not running the Linux emulation) are COBOL-ers to the death.
Robert,
Back in the 1980s, Oracle used to say that it’s IBM mainframe port was 2 years away. This lasted long enough that I started calling that figure “Larry Ellison’s constant.” Then one day I called his office, and asked his assistant Jenny Overstreet how the mainframe port was coming. She said “Let me put it this way; I’m sitting here reading an MVS manual.” That told me a lot about her as well as about product delivery dates …
… but I agree that Oracle never was, is not, and never will be a serious contender on IBM mainframes.
CAM
Yet another spin:
http://www.marketwatch.com/story/despite-promises-oracle-may-sell-off-sun-hardware
Peter
hiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii