Thinking About Software Machines

During the past two weeks, I received two client Inquiries about specialized Java hardware and Larry Ellison announced v2 of Oracle's "database machine."

These two seemingly disconnected events made me ask: Is specialized hardware for software inevitable? Last year, we saw TIBCO announce a messaging appliance too. And IBM has a robust business in XML and security appliances. Will growing volumes of data, messages, and logical operations force us to adopt specialized hardware, abandoning the unbundled software model IBM introduced back when real Hippies roamed the Earth?

The client Inquiries were from firms having to invest heavily in infrastructure and still struggling to keep up with their Java processing loads. Both had seen Azul Systems, found its touted performance numbers compelling, but wondered: "Where are the other competitors?" Answer: I don't see any others doing what Azul does.

Why? My answer: Too few customers buy this way -- particularly from a startup with a proprietary software machine. IBM, HP, Intel, and the other big vendors don't see enough of a market yet to take the plunge.

With its database machine, Oracle claims impressive advances in I/O and query speeds, and disk compression. But the company says it has 20 customers for this product. For a new model and a new product, that's not bad. But I think it helps answer my question: Only the tippy top of the enterprise food chain really needs software machines for general purpose products like databases, Java application servers, and message processing. The majority of customers can use other software techniques to keep growing without being locked into proprietary software machines. Virtualization, distributed caching, in-memory databases, optimized garbage collection, and alternative database structures come to mind.

Read more

Is open systems dead? Does code portability matter?

Jeffrey Hammond and I did a Teleconference today for clients about the first release of Oracle Fusion Middleware 11g. One of the big areas of concern among attendees was an old chestnut that I actually haven't seen for awhile: Portability. The basic question: If we develop for Oracle's stack, are we locked into it?

Jeffrey and I have documented the basic risks of lock-in we see in Fusion Middleware 11g in our analysis (http://www.forrester.com/go?docid=55043). I don't want to revisit that analysis here; rather, I'm more interested in why we suddenly heard this concern..

I've been writing about software technology roughly since the birth of the "open systems" movement during the late '80s. At that time, open systems meant SQL relational DBMS + Unix at its core, with DCE and CORBA sometimes tossed into the mix as well. The concern for code portability extended to Java's "write once, run ... anywhere" promise in 1995. And then I think it started to die.

Read more

As Eclipse Kits for Cloud Arrive, Amazon Deployment Wins

Amazon's announcement on August 26th of its Eclipse toolkit added another Eclipse-cloud option for Java developers. Here is a table comparing these four: Amazon AWS Eclipse Toolkit, Google Plug-In for Eclipse, Stax Platform for Amazon EC2, and the planned next major release of SpringSource Cloud Foundry. (Cloud Foundry today provides a Web interface, but will embrace Eclipse.)
Eclipse cloud kits 

Several observations jump out at me:

Read more