Thinking Out Cloud

Developer-Friendliness: Early Access Program

So while our competitors are being gobbled up by massive corporations :-) , we at GigaSpaces are starting a number of developer-friendly initiatives.

We're planning a number of things for the coming months. We will be open sourcing some elements of our product as part of a project we call OpenSpaces (not to be confused with the OpenSpaces section of our web site). Guy Nirpaz, our VP R&D, spoke about it at QCon, and Shay Banon writes about it briefly here. We will provide more information in the coming days and weeks (it's part of our upcoming 6.0 release).

Another thing we'll be doing is a special offering to start-ups, but we'll reveal this program (hopefully) next week.

In this post I want to tell you about our recently announced Early Access Program. The idea is to allow developers to register for this program and henceforth receive notifications whenever an early release (betas, milestones, release candidates, etc.) of the product comes out and of course make it available to them for download.

What we hope to get from it is a lot of feedback on the new features and changes to the product -- while there is still time to make changes before we go GA. And also maybe a little free QA...

So please SIGN UP. And once you have had a chance to download and play around with any of the early releases, please give us your feedback.

SOA Governance - Who Cares?

One of the things that have been baffling me for the past few months is the amount of money and effort the big middleware vendors  - IBM, BEA, Tibco, Oracle - have been pouring into their SOA governance products in terms of development and marketing.

It's not that I think that SOA governance is not important. Of course it is. But it is more of an organization, planning and consistency issue for those implementing SOA. The products themselves -- registries and repositories, etc. -- seem to be low-value products that are rapidly being commoditized and undifferentiated.

Seems to me that the more interesting issue, which few vendors are tackling, is how to implement your services. Existing approaches using J2EE and databases won't cut it in an SOA world where services need to be loosely-coupled, dynamically scale and so on. I previously discussed some of the challenges of implementing services in this post.

The good news is that from discussions with folks at some of the large vendors, it seems that some (senior) people are starting to get it.

By the way, Nati gave a great presentation, together with Shay Banon (one of our lead architects) on the topic of implementing services at TheServerSide Java Symposium last week, entitled From Tiers to Services without Web Services. It roughly follows the same concepts Nati discusses in The Scalability Revolution white paper we published recently.

Marketing to Developers - Build or Buy

A few weeks ago Dan Pritchett of eBay posted Build vs Buy - One Perspective. A very interesting post by Dan - including the ensuing comments - which gives a sense of some of the complexity involved when marketing to developers, as I pointed out here.

It's the architecture, stupid!

I haven't posted in a while due to extensive travel during the past three weeks: San Diego for the CMP Exchange Solution Provider show, London for QCon and last week in Las Vegas for TheServerSide Java Symposium. More on some of these in future posts, but the Oracle-Tangosol acquisition news that came out on Friday (and had been anticipated by us for some time -- it's a small world...) is the big thing everyone's talking about.

Nati posted an excellent analysis on this on the GigaSpaces blog. His post seems to have resonated well with others, such as Patrick Logan and John Powers of Digipede.

So to re-emphasize some of Nati's points in my own words:

• The Oracle acquisition of Tangosol is a strong validation of a new emerging category of middleware software by a major vendor
• It was certainly an excellent move for Tangosol (as a non-VC backed company, a lot of people there, and especially Cameron, are to get a big fat check). Furthermore, because the market is heating up and getting more competitive with well-funded companies such as GigaSpaces, this was the right time for Tangosol to do this
• It was a pretty good move for Oracle, and shows that they have a fair grasp of where the world is going to, but it leaves much to be desired. Nati discusses this in detail in the post referenced above, as well as touches on it in When You Need More Than Just a Data Grid.

The Tangosol approach all along has been that in order to solve performance and scalability problems, you need to solve the data problem -- i.e., move from a centralized, remote, disk-based database to a distributed, local, in-memory cache (aka Data Grid). That's fine.

The GigaSpaces approach has been all along that by only addressing the data bottleneck, you are merely taking an aspirin, not fundamentally curing your chronic migraines. In other words, the crux of the issue lies in the architecture -- n-tier architecture to be exact. Without a complete paradigm shift, you will not find the ultimate solution to the needs of the fast-growing category of what Gartner calls Extreme Transaction Processing (XTP), of real-time analytics, of high-performance SOA and of massive web applications of all sorts.

Besides the many GigaSpaces customers who are proof that this approach is being accepted. Look at the architectures of Google, Amazon, eBay, MySpace, LiveJournal and other Web stalwarts. They have all come to the same conclusion - with different nuances. They have all realized that the level of scalability, reliability and performance they need -- while keeping cost and complexity down -- will not come from a J2EE app server + database + messaging. It will not come from an n-tier architecture. Instead, they moved to a scale-out architecture, which aims for a shared-nothing approach.

So what is the GigaSpaces approach?

We call it Space-Based Architecture (SBA). I will not go into it in great detail here, because it has been explained extensively in our various blogs and white papers, but it follows the following principles:

First:

• Collapse the tiers into a single process
• Co-locate the services in a single process
• Manage state and other in-flight data in memory

You have essentially created a self-sufficient process ("Processing Unit" in GigaSpaces parlance). No more network hops. No more database calls.

Now:

• Scale-out these self-sufficient processes across your hardware infrastructure (cheap, standard hardware, mind you)
• Have the middleware partition and load-balance incoming requests across the many processes
• Dynamically manage the environment from a single-point-of-access (but not a single-point-of-failure) with SLAs for response times and reliability

The resulting architecture is:

• Linearly scalable -- because there is no dependency among the Processing Units, the law of diminishing returns does not apply. Each additional unit added provides the same throughput as the one before it
• Low latency -- because network hops between the tiers and the services that make up the application have been eliminated, and because data and events are accessed locally and in memory
• Simple -- because you have a single clustering model to manage high-availability, load-balancing and partitioning across your entire environment

Until the Oracles of the world acknowledge that the architecture their products assume is not viable for this class of applications, the headaches will keep coming back to plague them and their customers.