1,490
Before I give my take on the Oracle-Tangosol acquisition , I want to first send a big congratulation to Cameron and the Tangosol team. This is a great personal achievement and I wish you all the best of luck in your new home.
Now to my analysis from a technological perspective:
Oracle’s acquisition of Tangosol is one more acquisition in a series that indicates Oracle has finally come to the conclusion that the relational database is no longer a sufficient infrastructure platform for a large class of applications, such as Extreme Transaction Processing (XTP) and real-time analytics.
This is due to three critical limitations that have become apparent:
- Performance – an RDBMS is slow for two reasons:
- It maintains transactional state and other data on disk. This approach evolved decades ago, when memory was an extremely expensive and scarce resource. That is no longer the case today.
- The database is remote to the business logic (encapsulated in application servers), messaging servers and other elements that make up the application stack. Traditional attempts at bringing these elements into the DBMS through stored-procedures and triggers have proved to be extremely inefficient and “un-natural”.
- Simplicity – As a platform for developing today’s transactional applications, databases are becoming extremely complex due to:
- Today’s application code is object-oriented. A relational database is not. This creates complexity because of the need to transform the “language” of application code to the “language” of RDBMS and vice versa.
- In addition, business logic is managed by the application server tier, and data is maintained in a DBMS tier. The clustering – including partitioning, load balancing and fail-over – for each tier needs to be maintained separately, adding a lot of complexity for developers.
- Scalability – To meet the demands of exponentially increasing transaction volumes and low transaction latencies requires architecting the entire application stack for scalability using a distributed computing paradigm. This is the only way to break through the inherent bottlenecks of “tiers” – be they application servers, messaging servers or databases. A database, fundamentally a monolithic, centralized service, is not suitable for managing the volumes of data associated with SOA and today’s transaction processing requirements, what Gartner refers to as Extreme Transaction Processing.
Hoping to overcome these critical limitations, Oracle has gone on a string of acquisitions during the past couple of years:
– It acquired TimesTen in June 2005. TimesTen is an in-memory database. TimesTen suffers from all of the flaws of a relational database, except for one: it keeps data in memory, not on disk, and therefore it was at best a very partial solution because it does not address the simplicity and scalability challenges described above.
– In February 2006, Oracle acquired Sleepycat, makers of the embedded object-oriented database Berkeley DB, an open source product. Again, because it does not address the entire set of requirements of today’s SOA and dynamic scalable applications, Berkeley DB proved to be another partial solution limited to a relatively narrow scenario.
Further acting on this “partial solution” acquisition strategy, Oracle is now acquiring Tangosol – a distributed in-memory data caching solution. As with previous acquisitions, this latest one also solves some aspects of the problem, but fails to see the big picture.
IMO what is missing in their approach is a holistic view that looks at the end-to-end challenge of scalability. In other words, how do you take a stateful application and scale it out across a cluster of machines in a simple way, and without comprising on performance. This post and this one discuss my view on only addressing the data tier, versus a complete solution.
The technology bundling approach is just adding more complexity and moving parts. It introduces more confusion even to existing oracle customers. An oracle customer now needs to choose between TimesTen, Berkeley DB, 10G, and now Coherence. Instead of realizing that we are facing a real architectural challenge that will change dramatically the current middleware stack, Oracle took the short-cut of adding yet another solution to its arsenal hoping that customers will figure out a way to use it wisely in their solution.
Luckily our growing list of customers in financial services, telco, online gaming, government and many other industries all seem to agree with our approach.
In any case, I’m sure that this acquisition will increase the awareness of the need for a solution in this space, and with it the realization that there is a need for a new middleware stack that will address the entire scalability challenge.
Needless to say, at GigaSpaces we believe we have that solution, and we call our approach Space-Based Architecture (SBA).
You can read more about SBA here and these two white papers .
UPDATE: See Geva Perry’s perspective on it here .
