A melhor solução para linguagem Script e banco de dados para Web – Parte I

A particularidade do ambiente Web

O ambiente Web fornece um aspecto que muitos profissionais que utilizaram as três camadas de aplicação se esqueceram: a aplicação tem um só usuário (anônimo) que é chamado muitas vezes. A identidade de acesso é única, a autenticação é necessária e a fila de atendimento é enorme. Portanto, a escolha do banco de dados se pauta mais pela disponibilidade de conectores e classes de acesso do que pelo porte do banco. Daí se poder utilizar bancos desde o Microsoft Access até Oracle.

Antes do banco de dados dar sinais de fadiga, o software servidor (IIS, Apache e outros) pode dar sinal de fadiga ou incapacidade.

Critérios de escolha

A escolha de uma solução Web se pauta nos seguintes critérios:

- Confiabilidade dos fornecedores;
- Portabilidade;
- Custo;
- Rapidez no desenvolvimento/simplicidade de acesso a características esperadas (conexões, arranjos);
- Infra-estrutura exigida;
- Complexidade de instalação/manutenção;
- Variedade de Sistemas/Aplicações conhecidas que os utilizam;
- Coerência no versionamento (versões);
- Facilidade de resolução de dúvidas pela Internet ou Credibilidade frente aos usuários;
- Rotatividade por remuneração dos técnicos.

Confiabilidade dos Fornecedores

Os fornecedores de softwares precisam atender os seguintes requisitos:

- Conhecer e disponibilizar ferramentas e literatura de suporte suficiente para produzir o conforto dos profissionais de suporte e desenvolvimento, através de sites próprios e fóruns na Internet. O teste deste requisito equivale a responder a pergunta: “Quanto tenho uma dúvida, eu acho a solução rapidamente ?”

- Lançar novas versões num prazo de 6 a 12 meses, ou mais rapidamente quando surge um problema;

- Atender pequenas e grandes aplicações sem diferença muito grande de desempenho;

- Preocupar-se com a diversidade de sistemas operacionais, linguagens do mercado e processadores;

- Proporcionar conectores para os diversos bancos de dados;

- Ter alguma espécie de preocupação com a comunidade que desenvolve software livre;

Como complemento a este requisito, entra uma quase paradoxal independência do fornecedor, ou seja, é preciso adotar uma solução cujo futuro esteja garantido pela comunidade que a utiliza. Adotar um produto de um fornecedor que hoje aparece dominando o mercado não é garantia, pois em uma fusão o controlador pode simplesmente descartá-lo ou impor um prazo para abandoná-lo. Esta independência só pode ser obtida com a credibilidade de tendência, ou seja, a comunidade que utiliza o produto o acha bom e digno de ser continuado. Os exemplos são o pacote Staroffice (da Sun) que hoje tem suas marcas como Openoffice, BrOffice e Libreoffice , entre outros. Um outro aspecto é o interesse gerado pela solução, que a faz ser comprada por um fornecedor de credibilidade e destaque no mercado, como o foi do Mysql em relação à Oracle (a Oracle comprou os direitos do banco Mysql).

Portabilidade

As versões lançadas precisam atender os diversos sistemas operacionais existentes, com o mesmo leque de características. Além desta portabilidade ortodoxa, existe a portabilidade de conceitos. Uma linguagem não pode oferecer conceitos tão diversos das linguagens já existentes, com excesso de instanciações, produtos paralelos, tags proprietárias, objetos intermediários, etc.

Custo

Na composição de custo entram os seguintes fatores:

- Custo da plataforma de hardware necessária, para desenvolvimento e produção (dois serviços de software ou dois itens de hardware);

- Custo de treinamento para suporte;

- Custo de treinamento para desenvolvimento;

- Custo de treinamento para usuários;

- Custo de instalação;

- Custo de manutenção;

- Custo de versionamento;

- Custo de licenciamento;

Quanto ao custo de versionamento, hoje ninguém negocia atualizações periódicas no contrato inicial. Este item acaba aparecendo quando um problema exige que se atualize a versão.

Rapidez no desenvolvimento/simplicidade …

No desenvolvimento, é comum a preocupação com a IDE da linguagem de acesso. Os desenvolvedores querem escrever o código com os tradicionais assistentes. Hoje, com a proliferação e diversidade de fóruns disponíveis, um aplicativo inteiro pode ser baixado e modificado. As IDEs podem ter um uso classificado na categoria de “reinvento da roda”. Quando a linguagem é simples e objetiva, apenas algumas instruções podem resolver o problema. Tags proprietárias, com uma infinidade de atributos dificultam tanto a compreensão do código como a sua natureza procedural local.

A palavra-chave é “proprietárias”. Em termos de tags, deve-se sempre esperar que elas já estejam especificadas no padrão W3C, se atendo mais à formatação do que ao acesso a dados. Isto possibilita dividir o trabalho Web em:

- Programador do banco;
- Programador da interface;
- Programador da engine (parte funcional) da aplicação.

A excessiva colocação de acesso a dados em tags de formatação provoca a dificuldade na identificação da engine da aplicação, onde estão seus conceitos e regras. Espera-se que o programador de interface seja mais um designer visual do que um misto de design e programador de  acessos a banco. A interface de um ambiente Web deve ser o mais puro HTML, no máximo conjugado à consolidada linguagem javascript. A plataforma .NET é um exemplo de confusão entre os dois terrenos de programação, misturando formatação com acesso a bancos de dados.

Infra-estrutura exigida

Bancos de dados são notórios neste requisito. O banco Oracle exige máquina dedicada. Já os bancos menores podem conviver com o serviço de disponibilização de páginas do protocolo HTTP. Quando se compra uma solução Web, o hardware necessário conta e muito. Devemos nos perguntar se o banco de dados poderá ser instalado em servidor já existente. Uma resposta negativa implica na compra de servidor, e ser refém de especificações do fornecedor do banco.

Coisa parecida vale para o servidor de páginas. Temos os servidores que rodam até em servidor tipo DOS (Apache), e que consomem um mínimo de recursos, até os que exigem pelo menos um servidor separado (como o IIS).

Complexidade da instalação/manutenção

Em um mundo em que as aplicações Web atingiram o nível da banalidade quanto ao uso, espera-se que a instalação de um software, mesmo servidor, não exija a leitura de manuais, um grande conhecimento e um grande esforço. O cliente quer, geralmente, sua aplicação instalada rapidamente, ou ainda reinstalada quando da perda de um servidor ou problema na instalação. A complexidade de instalação justifica também a alta remuneração dos técnicos, e portanto o aumento no custo da solução.

O tempo de instalação e configuração nunca deve ultrapassar 6 horas, pois o cliente Web não pode ficar sem a sua aplicação no ar.

Variedade de Sistemas/Aplicações conhecidas que …

Quanto mais Sistemas e aplicações existirem com a solução escolhida, maior é o grau de confiabilidade da solução. Em termos do Java e Oracle, por exemplo, não existem muitos produtos prontos e comuns conhecidos. Existe o grande produto SAP, mas ele se aplica tão somente a clientes de vulto, como grandes empresas e bancos. Já o híbrido Mysql/PHP possui muitas aplicações disponibilizadas gratuitamente para download nos diversos sites, sob a licença GPL. Estes produtos podem ser baixados, estudados, modificados e utilizados.

Alguns produtos, como o Joomla (Mysql/PHP/Apache) possui tanta credibilidade, que são desenvolvidas extensões para ele.

Coerência no versionamento

Existem versões de produtos de software que quebram constantemente os seus conceitos de uma versão para a outra. Os produtos Microsoft fazem isto frequentemente, pelo acordo com fornecedores de hardware. Chega-se ao absurdo de um SDK trabalhar completamente diferente de uma versão para a outra, com retirada de características anteriores, modificação do número de parâmetros fornecidos na chama e outros aspectos.

No caso de bancos de dados, muitas vezes é preciso fazer procedimentos detalhados para se exportar o banco para novas versões, inclusive com a presença de técnicos de empresas especializadas, gerando custo. Bancos do tipo ISAM, como o Mysql, possuem uma coerência muito grande entre as versões. A nova engine reconhece os formatos anteriores.

Facilidade na resolução de dúvidas pela Internet

Geralmente, quanto maior o custo da solução, menor será o volume de informação que se achará na Internet sobre suas características e problemas. Um fornecedor que trabalha com uma solução cara não vai querer divulgar as características de sua engine, e nem admitir os erros que ela apresenta. Já as soluções que envolvem software livre e uma grande comunidade de usuários, possuem farta literatura para utilização e solução de problemas advindos de sua utilização.

A literatura em torno de soluções caras como as do banco Oracle ou produtos IBM é escrita em tom formal, e sem detalhes de sua estrutura. Já as soluções livres apresentam farta quantidade de manuais e tutoriais, muitos deles escritos pelos usuários, em linguagem coloquial, fácil de se entender.

Rotatividade por remuneração dos técnicos

Profissionais que trabalham com produtos caros, dando suporte ou desenvolvendo para grandes clientes, procuram sempre uma remuneração maior, e a oferta é tanto maior quanto mais raro o técnico. Um analista que trabalha com banco de dados Oracle facilmente encontra um alto salário em uma grande corporação. Profissionais que trabalham com software livre não encontram esta facilidade, pois a comunidade que utiliza um produto desta natureza é muito numerosa. Por isto a comunidade livre prefere os serviços rápidos de customização.

Conclusão

Na busca pela melhor solução, submeta os critérios aos técnicos cuja história na empresa seja a mais longa. Eles, com a sua experiência, irão decidir o caminho compatível com o seu perfil, porém não se esquecendo de alinhar a diretriz com o mercado. Não adianta adotar o muito mais seguro e formal, se o mercado estiver tendendo para outro lado.