Your Opinion Please: Did Oracle Make Concessions to the EU?

Back when the EU started the investigation of the Oracle-Sun deal, I made a bet. The bet hinged on whether Oracle would make concessions to get the EU’s approval. Please review the arguments, pro and con, and help us settle the bet.

Issue #1: The 10-Point Commitment to Customers Developers & Users of MySQL:
PRO CONCESSIONS: After meeting with the EU, Oracle issues this list of 10 concessions. Oracle prefaces the 10 points with the line: “In order further to reassure the Commission, Oracle hereby publicly commits to the following:” It then goes on to make certain commitments including #2 the non-assertion policy where is says “Oracle will change Sun’s current policy” and commit not to assert their copyright against storage engine vendors for 5 years. And continues to say: “Oracle shall reproduce this commitment in contractual commitments to storage vendors who at present have a commercial license with Sun.” Why would ANY company give up their legal rights without pressure. Clearly they made a concession. The press release includes other commitments and then closes with “The geographic scope of these commitments shall be worldwide and these commitments shall continue until the fifth anniversary of the closing of the transaction.”

CON CONCESSIONS: This is a press release and nothing more. There is no binding legal agreement. At the bottom of this simple press release it says: “When used in this press release, the words “shall,” “plans,” “commits” and “will” and other similar expressions and any other statements that are not historical facts are intended to identify those assertions as forward-looking statements. Any such statement is subject to a number of potential risks and uncertainties…”

Issue #2: Oracle’s Press Release About EU Approval
CON CONCESSIONS: It is very clear in the title “European Commission Unconditionally Approves Oracle’s Acquisition of Sun” It is unconditional, case closed, no conditions.

PRO CONCESSIONS: Of course Oracle will say unconditional. This is tantamount to person #1 suing person #2 for $10M. Instead of taking it to court, they settle where neither person admits or denies guilt, but person #2 pays person #1 $5M. Just because it settled out of court, and they “agree” that nobody is guilty, it is pretty clear that if there was no guilt, person #2 wouldn’t have paid $5M. This face-saving way that Oracle presents the approval to the world is meaningless.

Issue #3: The EU’s Press Release About Approval of the Deal
PRO CONCESSIONS: “The Commission also took into account Oracle's public announcement of 14 December 2009 of a series of pledges to customers, users and developers of MySQL concerning issues such as the continued release of future versions of MySQL under the GPL (General Public License) open source license. Oracle has already taken action to implement some of its pledges by making binding offers to third parties who currently have a licensing contract for MySQL with Sun to amend contracts.” The EU took into account “pledges” by Oracle and the fact that Oracle is already changing binding agreements. These steps were clearly a concession and the binding legal agreements that have been fixed are legal and binding proof of these concessions.

CON CONCESSIONS: Oracle did NOT enter into any binding agreement with the EU, therefore they made no concessions to get the deal done. Any flimsy pledges in a press release are not enforceable and therefore, no concessions were made. The fact that they changed individual agreements does not mean that they made a concession to the EU at all.

We have a lunch bet riding on the argument. Did Oracle make concessions under pressure from the EU in order to close the deal to acquire Sun? Please vote in the comments section, leading with YES (Oracle made concessions) or NO (Oracle did not make concessions). Feel free to elaborate on why ;-).

Please vote on the facts, not on your opinion about whether it was sufficient or not ;-)

Thank you for helping us settle this bet.

HP Needs a Linux OLTP Database...FAST

Oracle, after dating HP, Dell, Netapp and EMC has found its mate in Sun. Oracle is now becoming a systems company, and unceremoniously dumping these former paramours. These leaves the spurned lovers to find alternate accommodations, especially in the area of the database.

As I have stated previously on this blog, the clear partner of choice on the Windows front is Microsoft. This is demonstrated by today’s partner announcement around MS SQL Server for OLTP. But who is their partner in the Linux segment?

The following are contenders:
* Postgres (HP rolls their own)
* EnterpriseDB (pre-rolled Postgres)
* Ingres or Sybase—Oracle has felled them both in the past, but they are hoping for new life with a big sugar daddy like HP.
* ScaleDB, If HP is going after the cloud and the MySQL market

I don’t see them going for a NoSQL solution because NoSQL = NoEnterprise, making it a non-starter for HP. One way or the other, HP needs a solution for OLTP on Linux and they are on the clock.

For OLAP, HP has NeoView. If they felt the need, there are a number of OLAP solutions out there such a Greenplum, Netizza, Asterdata, Paraccel, Ingres/Vectorwise and others. That said, I think HP feels that they are holding a good hand on in the OLAP space, but Linux-based OLTP just became a gaping hole in their product suite. Today's partnership with Microsoft confirms this problem, but only solves the Windows half not the Linux half.

VMWare, Zimbra and the Virtualized Software Stack

VMWare appears to be positioning itself to provide the virtualized or cloud-based alternative to Oracle, Microsoft and IBM. This is a very interesting approach, and it will be interesting to see it play out over time. With Oracle and IBM taking a more systems-centric approach, meaning they are both providing the storage, computing and software stacks in the form of a system, this leaves Oracle’s traditional hardware partners out in the cold (HP, Dell, EMC, Netapp, etc.) along with budding potential partner Cisco. VMWare may envision themselves providing the Linux-based alternative to Microsoft in this game of strategic positioning. VMWare’s strategic advantage is that their entire stack is virtualization- and cloud-friendly. That would make sense given Maritz's Microsoft experience.

This diagram compares the various stacks from VMWare's perspective (e.g. they are all on top of VMWare instead of their own respective virtualization offerings). It compares Microsoft (orange), Oracle (red), VMWare (green) and IBM (wait or it....blue).

If that is the case, there are some open holes and some questions.
1. Does VMWare need their own flavor of Linux (a la Novell’s Suse)?

2. What database does VMWare include? There are open source alternatives such as MySQL, Postgres and the recently wounded Ingres. The problem is that these all employ a shared-nothing architecture which doesn’t fit the virtualization model. They could look at some of the NoSQL alternatives, but NoSQL = NoEnterprise and the enterprise is where VMWare makes their money. (shameless plug) They could look at using ScaleDB’s shared-disk storage engine for MySQL, which is virtualization friendly.

3. Does VMWare go after higher-level applications like Zoho, SugarCRM, etc.?

4. Does VMWare partner with SAP to provide the applications layer and would that work in a virtualized stack? Certainly the proximity of their Menlo Park campi is convenient.

The opportunity for VMWare to partner with HP, Dell, Cisco, and obviously EMC but probably not Netapp, seems very compelling. Combine this with a built-in cloud play for these potential partners and it makes a lot of sense. Oracle is enamored with Sun and their systems strategy. They are walking away from HP and Dell. It would be interesting to see VMWare walk into those companies with the grand partnering strategy and a complete cloud stack ready to go. It would then increase the stakes for Oracle’s systems play, because it would cut-off their fallback position.

It is always interesting to watch the industry giants try to out flank each other.

Oracle/Sun vs. The Cloud

Larry Ellison makes it very clear that Oracle believes in a back to the future model where software and hardware meld together into “systems”, purpose-built, integrated solutions. In other words you won’t buy an Oracle database and a server and configure it to run a data warehouse, instead you’ll buy the “Oracle Data Warehouse Server.” The first such system is Exadata, which is apparently doing quite well, according to Ellison.

This is a classic bundling, although some may call it a tying strategy. Microsoft, seeing that they couldn’t win each office productivity segment individually—including word processing, spreadsheet and presentations—decided to play to their strength and bundle them into a solution that no individual company could compete with. This is bundling. The tying strategy is where Microsoft used their dominance in the operating system to tie the browser to the OS, thereby owning the browser market. In the case of Oracle, one could make a case either bundling or tying. I’m making neither a value, nor a legal judgment about Oracle’s strategy; I am just providing historical context.

Ellison points to Cisco and IBM, under T.J. Watson Jr., as examples of successful systems companies. But my question is simple: Will this back to the future strategy work against the cloud? Assembling solutions with pre-packaged systems is certainly easier than starting with more granular components like hardware and software. But does it really stack up against today’s benchmark, the cloud.

Let me use a transportation analogy:

Assembling all of the components (hardware, software, etc.): Like building a car piece by piece

Assembling systems (a la Oracle's Exadata and Cisco): Like building a car by installing large grain items, the chassis, wheels, engine, etc.

Using the cloud: Like buying a pre-built car off the lot

SaaS Applications: Like riding the subway

Most people are perfectly happy either buying a car or riding the subway. For really high-end performance, some may want to build their own car with components or by hand, but it’s a relatively small market.

I don’t expect any public cloud offerings to satisfy high-end enterprise demands…yet. But I have to admit, the cloud is evolving quite rapidly. Just look at Amazon and their introduction of Virtual Private Clouds, Elastic Block Services (a SAN in the sky), Boot from EBS, etc. I can launch an entire cluster with a mouse-click, without talking to IT. How can you beat that? Historical precedence is also on the side of commodity technologies, like the cloud, growing up to cannibalize the high-end. The PC cannibalized the workstation, which cannibalized the mini, which cannibalized the mainframe. From the clou's perspective, the trend is their friend.

The cloud won’t seriously threaten large enterprise systems for quite some time, but I believe it is just a matter of time. Oracle can certainly ride a strong wave of current demand for systems. I expect that in time they will also provide a compelling suite of solutions in the cloud. But if I were a bettin’ man I’d have to bet on the cloud; they have simplicity and history on their side. On the other hand, it is hard to bet against Ellison.

We Really Need TPC Benchmarks for the Cloud

TPC database benchmarks—which database vendors tune specifically for—are a useful objective comparison for buyers of databases. Unfortunately, there is no such comparison in the cloud, and the current cost/comparison approach used by TPC doesn’t fit the cloud.

Here are the problems:

1. TPC doesn’t include costs that are included in the cloud: Public cloud services bundle the costs of everything into their pricing. TPC eliminates things like: electricity, network connectivity, people to run the service, networking equipment (e.g. switches, cables, internet connectivity, etc.), load balancers, modems, Ethernet cards, etc. The public cloud is really a total cost of ownership, while TPC costs are not. So any cost/performance between onsite and cloud solutions compares apples to oranges.

2. TPC assumes that the expenses included above are paid in advance for three full years. Public clouds use a pay-as-you-go model. To compare apples-to-apples here, you would need to do a net present value (NPV) calculation to account for the time-value of money.

3. And this is the BIGGEST issue. TPC tests assume full utilization of the computer. Everyone knows that in the real world you (a) only use at most 80% of the CPU to accommodate usage growth and extreme peaks in performance; (b) between typical peaks and valleys in the remaining 80% your average usage in the real world is typically 10%-20% of the server’s capacity. The cloud, on the other hand, provides an elastic environment where you only pay for what you use. If you use a cloud-ready database that scales elastically, an average load factor of 10%-20% per server translates into saving 80%-90% of the costs versus a dedicated machine. In other words, an elastic cloud environment should reduce cost/transaction by 80%-90%, relative to a dedicated machine.

The cloud provides a normalized cost structure that reflects a more realistic total cost of ownership (TCO). It bundles costs like networking, personnel, electricity, internet access, and more, all in a pay-per-use model. But most importantly, we can get a transactions/instance, and then we elastically scale the instances as needed. This elastic pricing model gives us a real world cost scenario, instead of assuming that a single server is utilized at 100% capacity, which never happens in the real world.

For these reasons, I would like to see TPC create a category of benchmarks that measure cost/performance on standard cloud infrastructures.

Here is a link to Nobu, who ran TPC-C on Amazon’s RDS.

Virtual Databases: The Face of the New Cloud Database

Shared-disk databases can be virtualized—making them cloud-friendly—while shared-nothing databases are tied to a specific computer and a specific data set or data partition.

The underlying principle of the shared-nothing RDBMS is that a single master server owns its specific set of data. That data is not shared, hence the name shared-nothing. Because there is no ability to share the data, there is also no ability to virtualize the computing of that data. Instead the shared-nothing RDBMS ties the data and the computing to a specific computer. This association with a physical machine is then reinforced at the application level. Applications leveraging a shared-nothing database, that is partitioned across more than one server, use routing code. Routing code simply directs the various database requests to the servers that own the data being requested. In other words, the application must know which server owns which piece of data. This further reinforces the mismatch between shared-nothing databases and virtualization.

This is not to say that it is impossible to virtualize a shared-nothing database. As any software architect will tell you, “You can do anything in software…” The second part of that statement is “…but it may not perform or scale well, and it may make maintenance very painful.” The latter part of that statement is exactly what you will find with any effort to virtualize a shared-nothing database. Attempts to insert layers of indirection will result in added complexity that makes maintenance a nightmare. Finding bugs, tuning performance, recovering from failure, all of these issues are severely compounded when you introduce layers of indirection in a shared-nothing database.

The performance, and hence the scalability are also undermined in this model. In order to support dynamic virtualization, you must mediate the requests from the application before they hit the database. This requires a piece of middleware that sniffs each database request and routes it to the appropriate server. What happens when a database request spans multiple servers? Suffice it to say it isn’t pretty, and it doesn’t perform well. This sort of request will result in a lot of data shipping and joins. The bottom line is that partitioning your database to achieve performance, scalability and maintenance is a black art, all attempts to automate this process have failed.

Compare this to the shared-disk DBMS. Shared-disk separates the compute from the storage. The data is stored in one big trough, while you can have any number of compute instances feeding on the entirety of that data. Because each node has access to all of the data, you don't need any middleware to route the database requests to specific servers. Furthermore, each of the compute nodes is identical, making them virtualization-friendly. If one node fails, the others recover the transactions, while the application continues uninterrupted. You can also add nodes on the fly, again without interrupting the application. For these reasons, the shared-disk RDBMS is ideal for virtualization, while the shared-nothing RDBMS is anathema to virtualization.

This is an excerpt from a white paper I'm writing that addresses virtualized cloud databases.

Who owns the customer in the cloud?

In the world of technology, customer ownership has always been a huge issue. The company that owns the relationship is able to influence purchasing decisions that surround their product(s). For example, if the customer is tied into a specific application, that application can influence purchases down the stack (database, operating system, etc.). In these cases the specific (e.g. vertical applications) had an inherent advantage over the more generic or interchangeable (e.g. databases).

Then companies began to standardize on certain infrastructure elements. For example, a company might say “We are a Windows shop” or “We are an Oracle shop” and unless you had a REALLY compelling reason, you had to run on that infrastructure.

Cloud computing introduces a new dynamic. For example, you might be an HP equipment company, but if you use Amazon AWS, what is their equipment? They won’t tell you. What is the storage equipment used in S3 and EBS? Sorry, can’t say. You see those pieces are commodities.

In time, the process of commoditization will move right up the stack, and the cloud vendor strongly influences this process. Sure you can run various databases on AWS, just create your own AMI. But if you want the vertically integrated “out-of-the-box” database, that would be RDS running MySQL.

So, who owns that MySQL customer? Amazon, not MySQL/Sun/Oracle. The Amazon package bundles EBS, automation and more, and only Amazon can support it properly.

Who owns the customer when an application like SugarCRM is run on Amazon? That depends. Who sold the customer. If SugarCRM sold the customer and offered it as SaaS, then they own the customer. If the customer goes directly to Amazon, then Amazon owns the customer. If Amazon takes it one step further by integrating various other services, tools, etc. and then brands the resulting package as Amazon CRM, then Amazon will increasingly own the customers of the future.

In fact, I wouldn’t be surprised to see Amazon offer a suite of fully integrated business applications based upon open source applications and the LAMP infrastructure, sort of a back-office suite. Then you don’t have to worry about all those messy integration issues. Your CRM application will work with your document management application, etc. Sure, you could assemble your own solution in a piecemeal fashion, but why would you?

At that point, the question is not what CRM do you use, but rather which cloud suite do you use and is it compatible with my cloud suite. In other words, does the Amazon suite interoperate with the Cisco, EMC/VMWare, HP, IBM, and Rackspace suites.

The starting point for all of these solutions will be LAMP and open source applications. But each will focus initially on automation to simplify the effort, like RDS. Then they will deliver interoperability. Finally they will innovate in proprietary ways to deliver a better experience. And with each step they will further establish their ownership of the customer. This is why every major technology company, with the exception of Oracle, is assembling their own cloud solution, because they don’t want someone else owning their customers.