Hoje foi anunciado que a HP está comprando a EDS. O valor divulgado da compra é de US$ 13.9 bi.

Li algumas notícias dizendo que este movimento da HP tem como objetivo fortalecer a empresa para competir com a IBM. Entretanto, tenho sérias dúvidas se isso terá sucesso. A HP tem muita força na venda de equipamentos, e também presta serviços de manutenção de infra-estrutura. Já a EDS é uma gigante na prestação de serviços de software, tanto na área de manutenção de infra-estrutura como no outsourcing de aplicações, e consultoria de uma maneira geral. Como algumas áreas das empresas claramente se sobrepõem, imagino que muitos empregos serão cortados.

A HP passará a ter uma estrutura gigantesca, mas ainda ficará atrás da IBM em termos de faturamento. Além disso, embora fortaleça a empresa na disputa com a IBM, não fortalece tanto. A IBM tem uma área enorme de produtos de software que a HP continuará não tendo. Será muito difícil para a HP ganhar espaço contra a IBM sem um braço de software forte. Principalmente na área de middleware, onde a IBM está muito forte. E além da IBM, a HP teria que brigar também contra a Oracle neste nicho, depois que ela comprou a BEA.

É bom lembrarmos que a HP não tem lá um bom histórico em compras. A aquisição da Compaq foi bem traumática e não teve custo-beneficio muito bom para a HP. O mercado americano também não reagiu bem a essa compra da EDS. As ações de ambas as empresas caíram razoavelmente, mostrando que a maioria das pessoas do mercado não achou este negócio uma boa idéia para as empresas.

Na minha opinião, a HP após esta compra ainda é uma empresa incompleta para competir com a IBM, Oracle e Sun. Antes dessa compra a HP não era tida como concorrente direta dessas empresas, mas agora ela é. Penso que para a HP ter realmente relevância nessa disputa, ela precisará de um braço forte de middleware, e uma boa pilha de software em geral.

Com o histórico que a empresa tem, duvido que ela se transforme nisso por conta própria. Na minha visão o que faz sentido é a HP comprar mais alguma(s) empresa(s), para conseguir complementar suas ofertas de serviços. Considerando a consolidação atual do mercado, acho que faria sentido que a HP comprasse a Red Hat, levando o JBoss de lambuja. Além disso seria interessante que eles contassem com algum servidor de BD na pilha, já que os concorrentes possuem isso (DB2, Oracle e MySql). Uma ótima opção seria comprar a EnterpriseDB, que oferece uma versão comercial do Postgres, o excepcional BD open source.

De todas as grandes aquisições que rolaram recentemente, esta da HP é a que menos faz sentido, pelo menos atualmente. Dependendo das ações que eles tomarem em seguida, esta compra pode ser uma boa jogada ou um episódio lamentável como a compra da Compaq. Torço para que a HP aumente seus já fortes vínculos com Linux e Open Source e compre a Red Hat para se apresentar firmemente como competidora de peso. E claro, continuo torcendo pelo sucesso do meu estimado Postgres :)

SimpleDB on the other hand is not boring, it's an exciting new shiny thing that opens up a myriad of new possibilities; but first, I and the rest of the developer community, need to tool up and cast aside some of our cherished database design patterns (oh like, 3rd normal form, strong typing, joins, nothing major) and embrace a slightly different way of thinking, however, as much as I like a challenge, I also like to get things done.

That's where EnterpriseDB's new Postgres Plus Cloud Edition comes in, this is an Amazon Ec2/S3 hosted edition of their Oracle compatible PostgreSQL-based product that offers the scalability of SimpleDB but the familiarity of a traditional relational database. The "magic" is supplied by Elastra, who are also offering the same functionality against MySQL and standard PostgreSQL databases.

A Talend ETL job which I had been developing for a client, had been tested against a "normal" EnterpriseDB instance. This ETL job was part of a BI prototype trialling a Postgres Plus Cloud Edition (the new name for EnterpriseDB's cloud offering) as the back-end database. So, I exported the job as a Java executable, fired up an EC2 instance, copied up the generated JAR files, changed the database's hostname to that of the Postgres Plus "cloud" database, ran the ETL job and it worked. As I said, boring, nothing to report, it just worked.

Now you may be wondering what's so special about these Elastra powered databases, surely EC2 is no different from any other Linux virtual machine, why not simply install a standard database? The problem with EC2, and it is a problem to those of us (i.e. practically every IT pro on the planet) who have come to expect highly reliable RAID backed disk storage, is the non-permanence of its disk systems.

When an EC2 instance is powered down or fails, the disk system is wiped!

That, combined with fixed (if generous) disk sizes (160GB, 850GB or 1690GB), means that often a clustered database environment is a necessity, adding considerably to the complexity. It's this sort of complexity that SimpleDB and Elastra address.

The obvious use-case for both Elastra and SimpleDB is as data stores for OLTP applications but Elastra's ability to handle S3-backed massive databases means the possibility of using EC2 as a data warehousing platform is also considerably strengthened. Although not obvious at first glance, SimpleDB could also act as an OLAP data store; SimpleDB massively indexed tuples as "sparse dimensions" pointing to S3 objects (SQLite databases?) that hold the fact data combined with dense/"partioning" dimensions (e.g. Time). Possible ? Yes. Fun to do? Yes. A solution that I can apply tomorrow? No, that's why I'm glad EnterpriseDB and Elastra are delivery such a boring product!

UPDATE Ec2:

The other big EC2 missing - non-permanent IP addresses - has at last been addressed. EC2 now offers "Elastic IP Addresses", addresses associated with an account not an instance. If the instance fails or is shut down, the IP address can either be immediately re-assigned to a new instance (no more waiting for Dynamic DNS propagation) or "reserved" for future use at a cost of USD0.01c per hour. Also, the new "multiple locations" facility puts the API changes in place to allow for location selection, hopefully a sign that we here in Europe will have "local" EC2 instances to match our European S3 buckets!

UPDATE EnterpriseDB:

It looks like IBM have invested in EnterpriseDB, possibly as a counter-weight against Sun's acquisition of MySQL (EnterpriseDB's targeting of Oracle's customer base would also be an added benefit!).

Essa semana fiquei sabendo pelo blog do Savio Rodrigues que a IBM investiu US$ 10 milhões no EnterpriseDB, uma derivação comercial do Postgresql, mas cujos desenvolvedores atuam no desenvolvimento do produto open source também.

Com isso, até o momento o EnterpriseDB já recebeu no total US$ 37,5 mi, o que é bem próximo dos US$ 39 mi que o MySql havia recebido antes de ser comprado pela Sun. Torço para que isso ajude bastante no desenvolvimento do banco de dados e que eles consigam trazer ainda mais qualidade aos seus produtos. O Postgresql é um banco open source muito maduro e confiável já há muitos anos e o EnterpriseDB adiciona recursos interessantes para grandes empresas. Entre as principais forças do EnterpriseDB está a sua garantia de compatibilidade com código feito para o Oracle. Eles garantem por contrato que a sintaxe SQL, tipos de dados, packages, stored procedures, trigger e views desenvolvidas para o Oracle irão funcionar conforme esperado no EnterpriseDB. Isto sem dúvida é um facilitador para empresas que possuam grandes bases Oracle e queiram progressivamente migrar seus bancos de dados.

Eu usei pela primeira vez o Postgresql no começo de 2003, e sempre o considerei melhor que o Mysql. A principal razão pela qual o Postgres perdeu espaço para o MySql foi o fato de que o Postgres não tinha um instalador nativo para Windows antes da versão 8.0, que saiu em janeiro de 2005. O MySql tinha muito menos funcionalidades e confiabilidade, mas como era fácil utilizá-lo no Windows, sua adoção aumentou rapidamente.

Eu ainda considero o Postgres melhor do que o MySql e ele é o meu banco de dados preferido quando eu tenho a liberdade de escolher. Espero que eles continuem desenvolvendo bastante o produto e recebam mais investimentos. Eles merecem um ótimo lugar no mercado de bancos de dados, e torço para que eles consigam tanto ou mais sucesso que o MySql.

Aproveitando esta discussão, algo que me veio à cabeça diz respeito à consolidação das pilhas de produtos no mercado. Será que faria sentido que a Red Hat comprasse o EnterpriseDB e a Oracle comprasse uma distribuição Linux?

A Sun atualmente possui a pilha completa, indo do sistema operacional até o middleware Java, e inclui um banco de dados (MySql). A IBM não vende mais sistemas operacionais próprios (até onde sei), mas suporta bastante o Linux e tem seu banco de dados e o middleware Java EE.

A Oracle tem tudo menos o sistema operacional, especialmente depois da compra da BEA. A Red Hat tem tudo menos o banco de dados. Ambas fizeram compras significativas no passado. Será que veremos as 2 empresas completando sua pilha de produtos em breve?

Isto é algo que eu gostaria de saber, e seria bem interessante ver como o mercado se comportaria depois de tais movimentos.

EnterpriseDB uses the slogan "The Oracle-compatible database company". While I wish Andy and the folks at EnterpriseDB the best, the challenge is that Oracle's high end products aren't in danger of losing to OSS competition. Next, in the majority of Oracle deals, Oracle isn't selling a database anymore. They are selling a database, an application server, tools and applications in a joint fashion. It's difficult for vendors to compete unless they can offer, or partner to offer, the equivalent products. This is bad news for smaller ISVs, especially smaller/regional application ISVs.

EnterpriseDB does have an opportunity to compete, and win, against Oracle in deals where the customer just needs a standalone database (and not all the other Oracle products) that can be utilized with their existing Oracle sills. This isn't new news to Andy and team. I'm sure some of the new funding will be used to compete with Oracle in this market segment.

I just realized that EnterpriseDB is also targeting MySQL users (news to me!):

"MySQL users know firsthand that MySQL is most effective for read-only environments and the web/edge tier - but not for applications in demanding OLTP environments, requiring enterprise-class reliability, availability, and scalability.

In fact, some EnterpriseDB clients continue to run MySQL databases for less demanding applications and turn to us where they've "hit a wall" with MySQL. "

I find this quite interesting, and very much in line with what I've experienced. No one product is right for ever customer project. Also, a product may be right when you start the project, but it may not be appropriate a year or two down the road.

What do you think, does EnterpriseDB have a brighter future by targeting Oracle users that want "Oracle like features for MySQL prices" or by targeting MySQL users who have "hit the wall"?

In my blog entry about how PostgreSQL is supposedly only 12% slower than Oracle, I focused on the fact that these claims were fundamentally flawed. I encourage you to read that entry for more context.

There is yet another Open Source database called EnterpriseDB that has PostgreSQL at its core. I started digging in to EnterpriseDB just to see what the buzz is. It takes no Google wizardry to find EnterpriseDB making claims to solving problems and saving money. Honestly, I think they get press because of the Open Source phenomenon-or what I call DotCom 2.0 if you get my drift. How can a 2 year old company funded with $28 million venture capital get as much press as these guys? It's because the term Open Source is involved. Indeed, you don't hear much about Michael Stonebraker's company Vertica, which has raised some $16 million in venture capital and is headed by Michael Stonebraker-for crying out loud! Well, I made a blog entry about Vertica back in February, but that doesn't really count I suppose.

Making Big Waves
Google quickly spits out examples where EnterpriseDB is making waves. For instance, the following articles herald how FTD has managed to move some processing over to EnterpriseDB from Oracle:

http://www.pcworld.com/article/id,133595-pg,1/article.html

http://blogs.cnet.com/8301-13505_1-9736358-16.html

http://www.computerweekly.com/Articles/2007/06/28/225179/floral-firm-saves-83-by-moving-to-open-source.htm

That's all fine and dandy, but I wanted to dig deeper. So, I decided to sit through this webinar presented by FTD and EnterpriseDB. Basically what this webinar spells out is that FTD was reporting against their OLTP Oracle database which was saturating their hardware during their semi-annual peak processing (Valentines Day, Mother's Day). They needed to off-load the OLTP system so they started looking into solutions. Long story short, they decided to jump past all Oracle products and licensing options (e.g., Standard Editions, etc) and settled on replicating the database to EnterpriseDB and reporting against that database using Oracle Reports. Yep, just tweak a "few" things and slide in JDBC PDS and Oracle Reports is reporting against an EnterpriseDB database. Oh how cool that must seem.

After sitting through that webinar, I downloaded the slides. The one that really caught my eye was:

Odd, what does Sun get by recommending EnterpriseDB into an Oracle shop? Sun was going to get a hardware sale either way, so I don't get it. In fact, I never understood it when hardware companies recommended one database versus the other. That point seemed weird to me, but that is not what I'm blogging about.

Oracle Compatibility
There is one aspect of EnterpriseDB that I want to blog about-Oracle Compatibility. According to EnterpriseDB website, EnterpriseDB is Oracle compatible:

Making the switch from Oracle requires little or no modification to existing applications. Using our Migration Toolkit, the process is often completed in minutes. In fact, our clients report that more than 75% of their applications are 100% compatible, requiring NO changes to run on EnterpriseDB.

Well, the 75% of 100% is nebulous because even he FTD webinar suggested there is more to it than that. In the webinar FTD discussed how they had to:

• Modify RDF file for each report to point to the new database (using the profile created in jdbcpds.conf)
  • This is a bit time consuming due to the way Oracle Reports and Reports Builder work -you have to re-point all fields to the new query by hand

And

There were several things that we had to do to our queries to make them run on EnterpriseDB

• All date operations were modified to use EnterpriseDB/PostgreSQL functions instead of Oracle's
• All columns that had a string operation performed on them in the query itself had to be explicitly cast to an appropriate size
• ROWNUM references had to be modified to use LIMIT (this is no longer necessary in the new version of EnterpriseDB)
• GROUP BY and ORDER BY statements modified to use column numbers instead of column names (when grouping or ordering by complex columns)

I know shops that have tens of dozens of reports. That seams like some heavy lifting to me depending on the scale of the project. But that is not what I am blogging about.

How Did We Get Here From There?
The question I have is how in the world EnterpriseDB can claim to enhance PostgreSQL providing an even higher level of Oracle compatibility. I'm trying to figure out how one can claim they've engineered a product that acts just like another product without having both of them side by side. I know there are very clever (clairvoyant perhaps?) folks out there that can engineer software that mimics other software without doing nasty things like reverse engineering. But does anyone really think that nobody at EnterpriseDB has booted up an instance of Oracle to at least test their claims for compatibility? Moreover, does anyone think that EnterpriseDB can to support software that claims Oracle compatibility without having at least a few servers in their support labs running Oracle?

I just spent some time rummaging through Oracle's Partner list. I'm probably blind, but I didn't see EnterpriseDB there. Well, that would be odd since they are trying to directly compete with Oracle-what with selling an Oracle-compatible database and all. Maybe there really are no EnterpriseDB employees that have access to Oracle instances. Maybe.

Where's Waldo
I don't think EnterpriseDB is trying to sell and support an Oracle-compatible database without having access to Oracle database software for development, test, and support purposes. And I don't see them as a member of the Oracle Partner Network. I seriously doubt they cut a PO to purchase licenses, and even if they did, they would be in violation of the EULA because you know for certain you can't buy Oracle software to help you make software that directly competes with Oracle. So where did they get the software? I suspect they got it from the OTN software download page. Now that is just my suspicion, but if I'm right, they were required to read and acknowledge the license agreement which wouldn't likely include license to directly compete with Oracle, but I could be naïve. How coincidental, there was a related thread on the oracle-l email list today about using Oracle on VMware and how to license it.

The VMware-related thread centered around the fact that while people wouldn't use Oracle on VMware for production purposes, they do just fine using it for development and test purposes. At one point during the thread I caught on to the notion that people were just throwing Oracle on VMware instances without concern for Oracle licensing by stating the following:

...this insinuates you don't see the need to properly license Oracle for development purposes. Am I missing something?

Within minutes there was a post on the list that read:

You don't need to pay for licences for development systems

http://www.oracle.com/technology/software/index.html

"All software downloads are free, and each comes with a Development License that allows you to use full versions of the products only while developing and prototyping your applications."

I followed up immediately in this post with:

...Oh how I knew people harbor that silly misconception. You have to read the license when you download. That very URL has 2 boxes. One to affirm you are not going to export the software to Libya the other says this:

"You may not:

- use the programs for your own internal data processing or for any commercial or production purposes, or use the programs for any purpose except the development of a single prototype of your application;

[ text deleted]

- continue to develop your application after you have used it for any internal data processing, commercial or production purpose without securing an appropriate license from us, or an Oracle reseller;"

The license for using database software downloaded from OTN allows you to make a single application prototype. Once that application is deployed you have to license it. Further, once that application is deployed you cannot continue to develop it with the downloaded software without proper license. It is right there in black and white.

So how would poor EnterpriseDB get Oracle software so they can continue to develop and support a directly competing database product? Well, they certainly can't use the bits they downloaded from OTN as I've just covered. They could join the Oracle Partner Network.

Well, EnterpriseDB? What's your OPN number?

I know, I'm probably off base entirely on this one. I doubt EnterpriseDB would have gotten funding from so many venture capital firms to build a house of cards on shifting sand.