Oracle Exalogic
At his Sunday night keynote, Larry Ellison announced a new software/hardware package from Oracle called Exalogic. Basically an appliance intended to address enterprise class web deployments as a forklift install (and for only about a million bucks list price), the Exalogic is the next step to the Exadata platform. Oracle wants to claim this as revolutionary, but it seems to be a large evolutionary step forwards.
One of the general shortcomings of the Exadata platform was it’s inability to perform as anything other than a database tier. Exalogic steps into the middleware tier; it also can serve as a web tier, but I would suspect it’s performance there will be somewhat marginal. According to the specs announced from the stage, Exalogic is Exadata with Oracle VM and WebLogic thrown in on top.
In a throwback to the Oracle Apps In An Hour position from the late 90′s, Oracle either is pushing a standardized configuration for Exalogic or is offering only a standardized configuration. I understand the motivation for this — support costs go down for Oracle, development costs go down for Oracle, customer hiring would be simplified (the same stack is everywhere, cutting down on the ramp up time for new employees) — but this seems a step backwards to me.
One of Oracle’s selling points has always been the extreme level of customization. You can tune the database, the middle tier, the web tier — everything — to the nth degree to wring out the last iota of performance. With a standardized configuration, you will be reliant upon Oracle’s best intentions. However, as Oracle will be selling to customers than just you, they have to pick a baseline which will serve as many people as possible. The Pareto principle largely dictates that such a baseline is likely to make most things better and some things worse.
An interesting idea with Exalogic is Oracle’s plan of applying updates to the Exalogic stack. Oracle’s plan is a “single file” to update everything. Two objections to this idea immediately struck me:
- One file applies multiple patches. Unless there’s some sort of rolling upgrade process going on in the background (which is possible but not mentioned either from the stage or in the PDF on the website as of this writing), this strikes me as a rather flawed approach. I can’t believe Oracle has not accounted for this, but I have no evidence they have.
- I’ll defer to Mr. Mencken for this one:
There is always an easy solution to every human problem—neat, plausible, and wrong.
Patching systems is a pain; coupled with the standardized configuration concept of Exalogic, and this starts to make sense. But I’m skeptical; I’ve seen these approaches other times with other software packages and it’s been a sporadically successful strategy.
For speed and performance, Exalogic relies heavily of solid state disks for its performance boost, much like Exadata, as a matter of fact. The downside to SSDs is their inability to sustain large scale writes over time. With about 1T of SSD per Exalogic full stacked rack, that’s going to get very expensive very quickly.
Finally, only 8 Exalogic full stacks can be chained together. On the one hand, that means a maximum of 2880 CPUs, 22T of RAM, 8T of SSD and 320T of SAS disks; on the other hand, some of the open source offerings (implemented with manual sharding and application partitioning) can support even higher combinations of hardware.
Related posts (autogenerated):
