Oracle: Mine is bigger and, um, more integrated
Ellison flaunts Sun unit
Comment With the European Union finally giving approval of the $7.4bn acquisition of Sun Microsystems by Oracle, the players in the IT industry can finally don their armor - made of iron, of course, and polished with software - to prepare for battle in the field of integrated systems.
Oracle and its Sun division, which could retain its name and at least some of its identity after the acquisition closes once antitrust regulators in China and Russia give the deal the nod, have a lot of work to do to knock Sun's processor, server, storage, networking, operating system, server virtualization, software development, database, and middleware roadmaps into shape and mesh them with Oracle's own operating system, virtualization, database, middleware, development tool, and application software stacks.
Oracle has - in the application space at least - been forced to let separate application stacks and their customers go on about their business and continue to run those apps and get Oracle support for those apps. It might be tempting to think that Oracle will do the same thing with Sun products, allowing Sun and Oracle variants to be supported and sold side-by-side with equal blessing. But if Oracle wants to wring profits out of Sun, as it has promised it can, this cannot happen with integrated systems. Oracle is going to have to either use or kill certain Sun products.
The first thing Oracle needs to do is decide if it wants to continue to design Sparc processors and manufacture servers. While Larry Ellison, Oracle's chief executive officer, has said repeatedly since last April, when the Sun deal was announced, that Oracle would not only remain committed to both the Sparc chip and the Solaris operating system, but also spend more on research, development, marketing, and sales than Sun did for the same products, what Ellison did not say is Oracle would expend budget on the Sparc T family of multicore/multithreaded chips designed by Sun itself.
<pFor all we know, Oracle and Fujitsu have been cooking up a new partnership whereby Fujitsu will be the designated Sparc hardware designer and Oracle will put Sun's engineers on a joint development effort. If I was Oracle, that's what I would be tempted to do. But then again, Fujitsu's Sparc64 roadmap is not particularly aggressive - we may see an eight-core "Venus" Sparc64-VIII processor in 2011 or 2012 in commercial servers - and it is just possible that Oracle has looked at the Fujitsu roadmap and the Sun Sparc roadmap from June 2009 (which El Reg outted last September when we got our hands on it) and found them both lacking. For the sake of Sun's Sparc server customers, I certainly hope that is the reaction Ellison and his team had.
In the wake of the announcement of the Oracle acquisition, Sun quietly killed off its 16-core "Rock" UltraSparc-RK processor and its related "Supernova" line of midrange and high-end servers, which were removed from the Sun roadmap last June. Sun had made no commitments to the Sparc64 lineup from Fujitsu beyond a goosed quad-core Sparc64-VII+ chip running at 2.88 GHz to be used in machines in 2009 and 2010 and a 3 GHz version used at the end of 2010 or in early 2011. That 2.88 GHz chip that was plunked into high-end boxes last October with slower variants in smaller machines, including the 2.75 GHz version announced in the single-socket M3000 last week.
Hitching its star to the Sparc64 chip line from Fujitsu is fraught with its own woes for Oracle. Fujitsu has been chronically late in deliveries and overzealous in its specs with the Sparc64 machines; the Sparc Enterprise M machines were a year late coming to market, and Fujitsu had planned to have quad-core chips to market years ahead of when they finally debuted.
More importantly, Fujitsu is in the process of outsourcing its chip manufacturing to Taiwan Semiconductor Manufacturing Corp, which adds another kink to the process and which possibly accounts for the large gap between the quad-core 3 GHz Jupiter-E chips due at the end of 2010 or so and the Venus octocore Sparc64-VIII expected in a year later. Fujitsu needs that Venus chip now, and the 3 GHz quad-core chip should have been here two years ago to meet competition in the market. Even more ominously, the Venus chips were part of a massive $1.2bn, 10 petaflops supercomputer project funded by the Japanese government that is at risk of being defunded.
Oracle might be tempted to drop modified "Niagara" Sparc T family processors into tweaked Supernova boxes and create what Sun should have made years ago: a line of SMP-capable Sparc T servers that go up to maybe 16 or 32 sockets. The problem is, Sun's own Sparc T roadmap from June 2009 was not particularly impressive. Back in August 2009, at the Hot Chips 21 conference, Sun gave out some feeds and speeds for the future the 16-core "Rainbow Falls" Sparc T processor, known variously as the Niagara-3 and the KT chip.
This chip will have eight threads per core and will be used in machines that have from one to four cores, for a maximum of 512 threads. And instead of hitting something close to 2 GHz, as Sun and its fab partner, Texas Instruments, should be able to do as they shift from a 65 nanometer to a 45 nanometer process in the middle of this year, Sun told customers last June that it could only hit 1.67 GHz with the Rainbow Falls chips. The current chips run at 1.6 GHz, so - basically - this will only be a 2X improvement in performance.
The Sun roadmap called for the "Yosemite Falls" kicker to the T3 chip, presumably to be sold as the T4, to have a new core and to revert to eight cores with eight threads per core in the design, running at 2.5 GHz and to be available in machine with one to four sockets. It is hard to imagine this chip having more performance than Rainbow Falls on database and Java workloads, which makes it peculiar, but the single-thread performance is interesting.
The "Yellowstone Falls" chip scheduled by Sun for the middle of 2012, which has only four cores and eight threads per core that runs at 3 GHz, is more interesting in that it will be used in servers with from 4 to 192 sockets. That same year, Sun was planning a related chip called "Cascade Falls," which runs at the same 3 GHz and with 16 cores and eight threads but which can be used in machines with anywhere from 1 to 8 processor sockets.
Basically, Oracle needs to pick either Yellowstone Falls or Cascade Falls and then get whichever one it picks to market in a server a lot faster than late 2012. Given these chips are implementing a new core and using 28 nanometer processes at a new fab partner, this seems unlikely.
The Sparc roadmap has traffic jams all over the place.
Which is why you can expect Oracle to continue to take the easy way out: promoting x64 servers based on chips from Intel and Advanced Micro Devices running either Solaris or Linux. Sparc customers will get what Oracle can cobble together from Sun and Fujitsu and they will no doubt pay a hefty premium compared to Solaris running on x64 iron.
Lucky Sun shops
Luckily for Sun shops, Oracle doesn't have its own Unix already, a situation that Compaq's (well, Digital's) customers faced when Hewlett-Packard ate Compaq a decade ago. The PA-RISC and Alpha chips made by HP and Compaq were already on their way out, to be replaced by Itanium, and Tru64 Unix's days were numbered because HP had its own HP-UX. (HP had planned to graft Tru64 Clusters onto HP-UX, but high costs and a bad recession forced it to simply use Veritas tools and forget that promise.)
Oracle will be able to give customers the alternative of Solaris and its clone of Red Hat's Enterprise Linux, and on x64 iron, it will be able to knock together a commercial-grade Xen hypervisor stack from Sun's xVM and the recently acquired Virtual Iron tools. (Oracle has to decide what to do with VirtualBox, and selling it off to Novell or Citrix might be an interesting idea). Sparc customers will be relegated to dynamic hardware domains on Fujitsu iron and Logical Domain (LDom) virtual machine partitioning on Sparc T boxes. The Solaris on Sparc and x64 variants will also have Solaris container virtual private servers, and Oracle has to give lip service to VMware's ESX Server and Microsoft's Hyper-V too, now that it is a Windows server supplier.
The Java middleware stack from Sun is very likely to be mothballed, with the exception of identity management features, which will be Borged into the Oracle middleware mess. Java will probably continue on its current trajectory, as Oracle has to be careful to keep all of Sun's Java partners and the millions of Java programmers in the world happy.
Sun's storage business, which is a constant source of hope and despair, has some interesting possibilities. Chris Mellor, El Reg's intrepid storage reporter, says that Ellison should get out Oracle's checkbook and buy Pillar Data to provide itself with a decent midrange storage lineup.
Ellison, of course, has funded Pillar through Tako Ventures, his personal venture capital company. You can check out Pillar's latest announcements from this week here. It is hard to say what Oracle should do with the Sun open storage products, which mix Sun servers, lots of disks, Solaris, and the Zettabyte File System. Clearly, Oracle will splash flash all across the Sun hardware line like some kind of magic performance-enhancing drug.
It is hard to say what Oracle should do with Sun's InfiniBand switches, beyond using them in products such as the Exadata parallel database cluster announced last September by Oracle and Sun or the Constellation HPC setups that Sun has been peddling for the past several years. But one thing it should probably do, if it wants to be a credible integrated systems provider, is get 10 Gigabit Ethernet switches into its product line immediately and support the Fibre Channel over Ethernet (FCoE) and Fibre Channel over InfiniBand (FCoIB) protocols to get server and storage traffic running over the same backbones as Cisco Systems is doing with its "California" Unified Computing Systems.
One ironic possibility is for Oracle to acquire Arista Networks, the upstart 10GE switch maker, which has Andy Bechtolsheim, and on-again, off-again chief technology officer at Sun, as its founder and CTO. Those "Magnum" InfiniBand switches and the related x64 servers and open storage arrays currently peddled by Sun came from another Bechtolsheim company, called Kealia, that Sun bought in 2004 shortly after Jonathan Schwartz took the helm.
It is hard to say what Oracle will do with MySQL, but its natural place is in Web infrastructure systems and Oracle would be a fool not to leverage its popularity in some kind of integrated system for hyperscale Web application deployments. One of the reasons why the EU let the Oracle-Sun deal go through is that Oracle made commitments to continue to enhance and support MySQL, and there is every reason to believe the company will make good on its promises.
Lawyers are always looking for a reason to take on a big foe with deep pockets, and they can talk governments into funding antitrust lawsuits that can drag on for years. Oracle doesn't want any of that and will most likely behave itself as long as MySQL remains popular.
Whatever Oracle plans, we will all find out a little something on January 27, when the company hosts a marathon five-hour Webcast explaining its hardware and software plans. Expect lots of subtle comparisons to - and snide comments about - the integrated systems being peddled by the Cisco/VMware/EMC triumvirate, by the Hewlett-Packard-Microsoft tag team, and by IBM. ®