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 🙂


Postgresql x Mysql: a diferença que faz uma estratégia correta

abril 30, 2008

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

Ontem fui no Tech Talk de MySql aqui na Globo.com, que me trouxe algumas idéias interessantes e também fomentou algumas discussões. Não vou falar muito sobre o tech talk especificamente, mas sobre uma discussão paralela.

Algumas pessoas sabem da minha preferência pelo Postgres sobre o MySql. Durante a apresentação ontem o Rafael me perguntou porque tanta gente utiliza o MySql e nem tanta gente usa o Postgres. Ele me perguntou isso porque usa o Postgres em alguns projetos e não viu vantagens em utilizar o MySql em vez do Postgres.

Bom, a resposta pra isso na minha opinião vem da diferença de estratégia. Banco por banco, sou mais o Postgres, embora eu considere que em boa parte dos casos, qualquer banco atende aos requisitos. Mas porque então o MySql ganhou bem mais adoção do que o Postgres?

Na minha opinião, o fator principal que levou a isso é que o MySql já há muito tempo oferece instalador nativo para o Windows. O MySql foi lançado em 1996 e começou com suporte apenas a Linux, mas desde 1998 permite instalação nativa no Windows. O Postgres começou como um projeto acadêmico em 1986, mas em 1996 se tornou um projeto open source com participação da comunidade de software livre. Podemos ver que nesta vertente atual de desenvolvimento, ambos estão disponíveis desde 1996. Enquanto o MySql suporta nativamente o Windows desde 1998, no Postgres isso só foi ocorrer em Janeiro de 2005, com o lançamento da versão 8.0. Anteriormente o Postgres só podia ser instalado no Windows com uso do Cygwin, que está longe de ser algo prático.

Considerando os recursos que ambos os bancos ofereceram ao longo de sua história, não restam dúvidas de que o Postgres é historicamente superior tecnicamente, e na minha opinião continua sendo. Entretanto, com a enorme quantidade de desenvolvedores que só utilizavam Windows (what a shame!), o fato de poder rodar o banco de dados na mesma máquina de desenvolvimento tornou o MySql muito mais conveniente para quem precisava de um banco de dados gratuito para suas aplicações.

Quando o Postgres lançou a versão 8.0 em Janeiro de 2005, muitos desenvolvedores já utilizavam o MySql há anos, e com isso sua adoção já estava bem grande. Neste ponto podemos ver claramente a diferença que fez uma estratégia correta. O fato de ser limitado tecnicamente em comparação com o Postgres não impactou o sucesso do MySql, porque durante muitos anos ele foi simplesmente muito mais conveniente para o desenvolvedor.

Atualmente, só vejo chances do Postgres aumentar seu sucesso se for comprado por alguma grande empresa e colocado em uma pilha de produtos interessante. Eu gosto muito do banco, e nos meus projetos pessoais ele é minha opção default. Entretanto, temo que ele nunca saia da sua abrangência atual, pelos erros na estratégia. É uma pena, devido à qualidade do projeto. Mas é muito difícil qualquer mérito técnico sobreviver a uma estratégia perdedora.


IBM investe US$ 10 mi no Postgresql. Mais consolidações à vista?

março 27, 2008

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

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.


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 😉


Conexão JDBC ao SQL Server 2000

janeiro 26, 2008

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

Como falei anteriormente, estou usando o SQL Server 2000 para um projetinho freela. Para me conectar ao SQL Server, baixei o driver jdbc jtds, pois li que ele funciona melhor que o driver jdbc fornecido pela Microsoft. Isto não me surpreende muito, pois a Microsoft não deve ter muito interesse em alavancar o uso de Java com o SQL Server, preferindo sempre empurrar o uso de .NET.Pois bem, eu estava tendo problemas para me conectar ao SQL Server via jdbc. Inicialmente o problema parecia ser da forma de autenticação, pois o servidor foi instalado com as opções default e as configurações padrão especificavam autenticação pelo Windows somente, sem autenticação pelo SQL Server. Eu encontrei na internet várias referências dizendo que os drivers jdbc para o SQL Server 2000 não suportam autenticação pelo Windows, então habilitei também a autenticação pelo banco de dados.

Após habilitar a autenticação pelo banco de dados, eu continuava sem conseguir conectar. Os problemas eram sempre os mesmos, e a mensagem de erro era essa aqui: “An error occurred while establishing the connection: Type: java.sql.SQLException Error Code: 0 SQL State: 08S01
Message: Network error IOException: Connection refused: connect”
. Procurando por esse erro, encontrei algumas referências sugerindo conferir se o servidor estava configurado para permitir acesso por TCP/IP, e no meu caso estava sim.

Como eu não estava conseguindo conectar de forma alguma usando TCP/IP, tentei conectar através de named pipes, e funcionou. Minha URL de conexão com o uso de named pipes ficou da seguinte forma: jdbc:jtds:sqlserver://127.0.0.1:1433;DatabaseName=sistema_cms;namedPipe=true

Ah, um detalhe importante. Ao tentar usar essa URL com localhost em vez de 127.0.0.1 , eu recebia um erro dizendo que o nome da máquina não era encontrado na rede. Colocando o hostname correto da máquina (no meu caso, blpsilva-vostro) funcionou sem problemas também. Possivelmente esta solução que utilizei não é a melhor possível para situações mais críticas. Entretanto, para o meu caso esta solução excede bastante o “good enough”, então fiquei com ela mesmo.

OBS: Esse template do WordPress tem o péssimo hábito de eventualmente cortar algumas frases que não caibam na largura da área central . Para não prejudicar a leitura aqui, segue abaixo novamente o nome do último parâmetro da URL jdbc:

namedPipe=true


Instalação e configuração do DbVisualizer no Linux

novembro 23, 2007

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

Com a crescente adoção do uso de Linux, algumas pessoas têm me perguntado qual software de acesso a banco de dados eu uso no Linux. Eu utilizo um software que já conheço desde os meus tempos de desenvolvimento para PDAs, quando o DbVisualizer era a única forma conhecida de se acessar as bases de dados dos dispositivos móveis.O software pode ser baixado a partir daqui, após preenchimento de um pequeno cadastro. Para que usa distribuições baseadas em pacotes rpm, a opção do download do rpm é mais conveniente, e a instalação pode ser feita com o comando rpm –install nome_arquivo_dbvis.rpm. Para Linux em geral, pode ser utilizado o instalador em formato .sh

Baixando o instalador .sh, basta copiar o arquivo para um diretório qualquer de sua preferência e executá-lo como ./dbvis_linux_6_0_2.sh para iniciar o processo de instalação.

Caso o instalador não se inicie normalmente, verifique se o arquivo .sh está com permissão de execução (caso não esteja, faça chmod a+x dbvis_linux_6_0_2.sh) e se você possui o Java no PATH do seu usuário. Para verificar se você possui o Java e a versão do mesmo, use o comando: java -version. O recomendado é ter uma versão de Java da Sun e que seja a partir do 1.5. Muitas distribuições Linux instalam uma versão do Java da GNU, mas não gosto e não recomendo esta versão. Coloque o diretório do Java da Sun no começo do PATH do usuário (se alguém não souber como, eu explico posteriormente).

O processo de instalação em si é bastante simples. Você precisa apenas aceitar os termos de uso do software e escolher o diretório de instalação. No resto, aceite as opções padrão apresentadas e Next -> Next -> Next 🙂 O processo de instalação cria um atalho no Desktop.

Com a aplicação instalada, vou mostrar agora como configurar a aplicação para conseguir acessar o Oracle. O driver jdbc do Oracle não vem incluído na instalação do DbVisualizer. Para conectar ao Oracle é necessário carregar o driver. Para isto, entre na opção Tools -> Driver Manager, conforme abaixo:

Carregar driver jdbc

Nesta tela que abrir, selecione no menu esquerdo a opção Oracle Thin e então na janela que se abrirá, você terá que selecionar o jar do driver jdbc do Oracle (ojdbc14.jar ou classes12.jar), conforme abaixo:

Escolher jar do driver jdbc

Se o jar foi corretamente carregado, a opção do Oracle Thin aparecerá verde. Tendo feito isso é hora de criar a conexão. Vá para a tela principal da aplicação, e no menu esquerdo, clique com o botão direito na opção Connections e então escolha Create Database Connection. Escolha por não usar o wizard, e você chegará na tela a seguir:

Nova conexão

Preencha os campos da seguinte forma:

  • Alias: nome que você quer dar à conexão
  • Database Type: Oracle
  • Driver (JDBC): Oracle Thin
  • Database URL: url jdbc de acesso, conforme será explicado abaixo.
  • Userid: usuário de banco
  • Password: senha do usuário

A URL jdbc varia de um servidor para o outro. No caso do Oracle, o formato é conforme publicado neste outro post. Como referência para o Oracle, se você tiver acesso a um tnsnames que acesse o servidor que você precisa, no tnsnames o formato da declaração é: nome_alias = string_conexao

Para criar uma URL jdbc do Oracle a partir de uma conexão declarada no tnsnames, você deve fazer jdbc:oracle:thin:@string_conexao

Pronto, após preencher este formulário de configuração, você está pronto para conectar-se ao Oracle! Caso alguma coisa não tenha ficado clara, por favor me indiquem para eu explicar melhor


Configuração de pool de conexões Oracle 10g em Java para balanceamento de carga e alta disponibilidade

novembro 23, 2007

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

Hoje respondi a uma dúvida sobre isto na lista de Java da Concrete e como acredito que pode ser útil para outras pessoas, estou compartilhando aqui. Pode ser que isto se aplique ao Oracle 9 também, mas não tenho certeza, então prefiro me restringir ao Oracle 10g.Há cerca de 1 ano passamos a usar Oracle 10g no trabalho, e desde então nossa string conexão com o banco de dados deixou de ter um host único para ter uma URL com Oracle Real Application Cluster (RAC). No nosso caso, a URL possui 3 nós.

A url jdbc de um pool de conexões Java para acesso ao Oracle com RAC é da seguinte forma:

jdbc:oracle:thin:@(DESCRIPTION=(ENABLE=BROKEN)(ADDRESS_LIST=(ADDRESS = (PROTOCOL = TCP)(HOST = host_no1)(PORT = 1521))(ADDRESS = (PROTOCOL = TCP)(HOST = host_no2 )(PORT = 1521))(ADDRESS = (PROTOCOL = TCP)(HOST = host_no3)(PORT = 1521))(FAILOVER=on)(LOAD_BALANCE=on))(CONNECT_DATA=(SERVER=DEDICATED)(SERVICE_NAME=SRV_CAD_ISP)))

Utilizando os parâmetros FAILOVER=on e LOAD_BALANCE=on, estamos especificando para o driver jdbc que este pool irá ter alta disponibilidade e balanceamento de carga entre os nós, respectivamente. Este tipo de solução é próprio do driver jdbc do banco de dados em questão, então não dá pra usar uma URL assim com outro servidor de banco de dados.

Uma referência bem mais detalhada sobre o assunto pode ser vista aqui.

OBS: tentei bastante, mas não consegui colocar a URL jdbc sem aparecer cortada aqui no POST. Quem precisar dela precisamente, por favor pegar no “view source” da página.