Thinking Out Cloud

GigaSpaces Interviews

Recently, a few interviews with me were published.

You might want to check them out:

• GigaSpaces XAP 6.0: Simplified, Spring-based API for Space-Based Architecture
• Interview with GigaSpaces
• Balancing Performance and Simplicity for Wall Street - this excellent piece by Derrick Harris also includes an interview with Sebastian Titakis of Commerzbank, a GigaSpaces customer

Before you read these, let me just quote Yogi Berra and say: "I never really said everything I said."

Nope. Still don't see Oracle

Although I usually let personal attacks slip by, I couldn't let this post from Cameron Purdy remain unanswered, because it's kind of shameless. And BTW, sorry it took me some time, but like Cameron, I too am friggin' busy with real important stuff :-)

So I'll start with Cameron's ominous threat -- in answer to my question Where is Oracle? he said: "We are in your customer accounts. Every single one of them." I don't know if Cameron is naive enough to believe this (doubt it), is just trying to sound threatening (shaking in my boots) or is just spreading what he thinks is FUD, but obviously the threat is not very credible.

We all know that Oracle is a mean-ol' sales machine (throwing in Coherence for free to close an ELA on other products is pretty aggressive). Nothing new there. But fortunately, the world is bigger than Oracle, and not only does it have competitors, but there are many companies out there who wouldn't let an Oracle sales person set foot. And we will be in every single one of them...

Interesting thing is that the Oracle announcement of the Tangosol acquisition actually helped us close faster a few competitive deals in so-called Oracle-shops, because customers said (and I quote one directly): "I don't want to put all my eggs in one basket." I just came back from a GigaSpaces off-site management meeting, and the sales execs could only come up with one case where we actually lost a deal because of the Oracle acquisition (and that was due to the aforementioned aggressive tactics).

Anyway, enough with the petty bickering (I'll get back to petty bickering later). I was making a bigger point: Oracle is not pursuing an innovation strategy, and is therefore losing its relevance for new applications.

In Where is Oracle? I quoted Nick Carr's analysis of Oracle's strategy, which ended with: "Through acquisitions and share gains, [Oracle] will milk the old model until the old model goes dry." Following the whole BEA situation, here's a perspective from Rob Hailstone of the Butler Group (via Java Developer's Journal):

Some 15 or more years ago I was in the audience at an IT conference, listening to Larry Ellison describing CA as a ‘bottom-feeder’.

Since I was working for CA at the time this rankled a bit, but it was certainly true that CA had evolved a good business model that included acquiring end-of-life software companies where there was a substantial user base in need of ongoing support.

The last few years has seen Oracle adopt a variation on this bottom-feeder business model – it doesn’t wait for the victim to be near the end, but puts the knife in at the first sign of weakness.

Well, I guess you can call that innovation.

Besides Oracle's own strategy, I don't think that anyone can be taken serious claiming that all's well for Big-Ass commercial databases in a Web 2.0, scale-out world. I phrased my statement pretty carefully: "They overwhelmingly use MySQL and in many case use some other tier - such as their own file system or an in-memory cache, as the system of record for session or transaction state."

I'm sure that somewhere in the bowels of the organization of eBay, Amazon and Google there is an Oracle database or two installed, but that's not the point.

Now, back to the petty bickering. I don't get why Cameron keeps saying that we use Coherence for our web site. Oh, now I get it. I guess because our Wiki uses Atlassian Confluence and Coherence is used as a cache for Massive Confluence, he concluded that GigaSpaces uses Coherence. Clever boy! But seriously, not only do we not use Massive Confluence, by that token, every time Cameron trades on the NYSE he uses GigaSpaces.

Oh, I guess he's just using the famous Geva Perry tactic of "it's OK to make up anything and post it on my blog". I like it. Aggressive, Oracle-style.

Oh. Yeah. Oracle

Like I said, Ouch.

Where is Oracle?

In all the ruckus around Nati's post, there was one thing that didn't get a lot of attention. If you look at that randomly selected list of 9 web sites from Pingdom, not a single one of them uses an Oracle database. (and I believe that neither do most of the big web players -- Google, Amazon, eBay, etc.). They overwhelmingly use MySQL and in many case use some other tier - such as their own file system or an in-memory cache, as the system of record for session or transaction state.

In my post It's the Architecture, Stupid! I gave my take on why the Tangosol acquisition by Oracle is not really going to change anything because they are so committed to the database-centric status quo, and they really will use the Tangosol stuff as little patch to fix what they think are minor bottlenecks.

The other day, I was reading Nick Carr's excellent post The week that Big Software shattered - his analysis of Oracle Vs. SAP Vs. Salesforce.com, and here's what the master had to say:

Oracle, which has never been particularly sentimental or ideological about software, stands for the status quo. It believes that big companies will continue to buy and expand old-style client-server-age systems for a good long while, and it plans to be the preferred supplier to the market. Through acquisitions and share gains, it will milk the old model until the old model goes dry.

Ouch.

Not exactly Web 2.0-friendly.

Nati has a nice take on this in Putting the Database Where it Belongs.

Update: Cameron Purdy threatens, and I shiver

Grid-Enabling Resource-Intensive Applications

Timothy Hoehn and Bob Zeidman from Zeidman Consulting published on Dr. Dobbs a really interesting analysis of what's the optimal way to distribute an application across multiple machines.

They examined several methods and reached the conclusion that the optimal approach is distributed objects and the master-worker paradigm.

Sounds familiar? :-)

Large-Scale Web Sites and Java

Nati Shalom's post, Why most large-scale web sites not written in Java, created a bit of a stir, to say the least, with a raging debate in the comments to the blog and one on TheServerSide and Artima.

And it also got referenced and commented on here, here, and here  - and several others.

Some people interpreted Nati's question as Java-bashing. And that created a silly PHP/Ruby Vs. Java flame war. As I had something to do with this post, as Nati mentioned, I thought that a couple of clarifications are in order.

As anybody who knows Nati and GigaSpaces (and as Guy Nirpaz pointed out), we're Java people at heart. Our product is written in Java. So there was no intention to bad-mouth it in any way.

I agree that the way the title of the blog was worded was a bit provocative, implying that most large scale web apps are not written in Java, but that was merely done to make things more interesting and based on an arbitrary analysis done by Pingdom, based on information they simply aggregated from High-Scalability. So obviously, no, it's not a statistically significant sample, and the word "most" is problematic.

Then, of course, some people rightly asked what is the definition of "large-scale". Again, it's a legitimate question.

But I want to explain what was the motivation for this post. We had an internal discussion on the relevance of GigaSpaces to the world of Web applications. At GigaSpaces (and yes, some of our competitors too - no need to shout) we've been pounding the scale-out drums, the partitioned data drums, the shared-nothing drums (and many other kinds of percussion instruments) for quite some time. In the last year or two it seems that a lot of people -- especially from the Web world -- are joining that funky beat. Google, eBay, Amazon, MySpace, Flickr, YouTube, Wikipedia and many others have published their architectures (and yes, I know some of them use Java) - and spoke of such architectures.

In other words, in the architectures that these folks used to make their Web apps highly scalable, performant and reliable, they are using very similar principles to the ones GigaSpaces has been advocating.

That said, we noticed that many of these folks are going with LAMP stack. The question was whether this is the trend, and consequently, what does it mean for us. If the trend is that Web 2.0 is moving to LAMP, but the enterprise market is still going to be a Java world, we need to make some decisions. If the whole world is moving to LAMP, we need to make some other decisions. And if Java is still dominant (or at least major) in the Web-world, it means yet other decisions and implications.

Although we don't have clear statistics, my intuition is that the trend for Web apps that are coming from start-ups or large pure web players (as opposed to web apps from airlines, banks, etc.) is definitely towards the LAMP stack. However, Java will still remain strong for a while and  especially for Web apps that have to deal with more complex processes in the back-end.

[BTW, I have a theory that 2004 was a watershed year in which many trends changed. It is the year that Spring Framework came out, that the term Web 2.0 was officially coined, that Ruby on Rails was released to the public, and several other interesting events. It would be interesting to see an analysis that compares what Web companies that are pre-2004 and post-2004 use for their infrastructure.]

Another interesting aspect, which Nati raises in his latest post, is that there is a possible convergence between Java and LAMP/RoR in various shapes and forms -- so it is not necessarily a zero-sum game.