HP compra EDS. Mas isso faz algum sentido?

maio 14, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

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 🙂

Anúncios

Bancos de dados já são commodities?

março 17, 2008

Atenção, este blog foi migrado para: http://brunopereira.org

Nos últimos meses trabalhei em uma boa diversidade de projetos, no trabalho, em projetos pessoais e artigos. Sem motivo nenhum especial, lidei nestes projetos com uma boa variedade de servidores de bancos de dados.

A maioria das coisas que faço no trabalho envolvem o Oracle, mas nos projetos pessoais utilizei o SQL Server, Postgresql, MySql e o Derby. 5 produtos diferentes, cada um com suas particularidades. Este convívio com diferentes bancos de dados me permitiu uma boa análise do momento em que já estamos em relação ao uso dos mesmos.

Na prática, basicamente o que mudava para mim de um BD para o outro era saber qual ferramenta de administração que eu deveria utilizar e qual driver jdbc precisaria baixar. Nos casos em que a camada de persistência era com jdbc diretamente (em vez de mapeamento objeto-relacional), eu precisava também prestar um pouco de atenção com pequenas diferenças na sintaxe SQL de cada um.

Algo que me chamou a atenção quando parei para pensar sobre isso foi que para a maioria dos projetos, qualquer servidor de banco de dados que eu utilizasse me atenderia sem problemas. Em termos de funcionalidades, o que eu preciso em um banco de dados não é nada sofisticado. Eu gosto de tratar do SGBD como um repositório confiável e eficiente para persistência de dados. Prefiro deixar toda a inteligência da aplicação fora do BD. O que eu espero de um bom servidor de BD é que ele mantenha os dados íntegros, ofereça recursos de restrições de integridade, índices, sub-queries e mais algumas funcionalidades nada extraordinárias.

Como falei, não gosto de colocar inteligência no banco de dados, então descarto o uso de stored procedures, triggers e coisas do gênero sempre que possível. A maioria dos SGBDs atuais suporta todos estes recursos que mencionei. Para a maioria das aplicações que desenvolvemos, o Oracle, Sql Server, DB2, Postgres ou MySql sem dúvida servem tranqüilamente. O conjunto de aplicações que tem acessos suficientes para derrubar qualquer um destes servidores é muito pequeno. Se na maioria dos casos qualquer SGBD serve, será que já podemos considerar os bancos de dados como commodities?

É claro que existem aplicações nas quais as exigências sobre o banco de dados são muito críticas. Alguns sistemas usam intensamente o servidor de banco de dados e possuem tabelas com milhões de registros que precisam de uma indexação muito eficiente. Embora talvez seja possível usar perfeitamente o Postgres e o MySql nestes casos, eu tomaria uma postura mais conservadora e só adotaria um dos 2 após diversos testes de carga sobre a aplicação usando eles.

Da mesma forma que existem aplicações que precisam de um servidor de banco de dados extremamente robusto, existem aplicações nas quais a praticidade de uso é o requisito mais importante. Temos por exemplo casos em que utilizar o Derby ou HSQLDB no modo embedded podem ser muito convenientes. É claro que o Derby e o HSQLDB não agüentam a mesma carga que os outros servidores mencionados. Todavia, a capacidade de empacotar o banco de dados dentro da sua aplicação pode ser muito conveniente, e nestes casos o Derby e o HSQLDB não poderiam ser substituídos por nenhum outro desta lista.

Nos casos em que os requisitos de banco de dados não são convencionais, algumas opções podem se mostrar muito mais adequadas do que outras. Entretanto, na maioria das aplicações, a troca de um produto pelo outro não fará muita diferença. Os recursos que realmente precisamos a maior parte do tempo estão disponíveis na maioria dos produtos.

A forte competição imposta pelos BDs open source fez com que os SGBDs comerciais passassem a oferecer versões gratuitas de seus produtos, com algumas limitações de uso. Para enfrentar este novo desafio, o Postgresql e o Mysql foram investindo cada vez mais esforço em seus produtos e hoje já têm uma ampla gama de recursos que antigamente só víamos em produtos comerciais. Com esta evolução do mercado, temos um largo leque de opções para escolher e estimo que em 90% dos casos, qualquer uma das opções atenderá plenamente.

Na minha opinião, isto já é suficiente para classificar os bancos de dados como commodities, na maioria dos casos. Já podemos ir na farmácia e pedir pelo genérico 😉