Publicidade

A história do lock-in no Brasil

Por| 15 de Abril de 2016 às 17h50

Link copiado!

A história do lock-in no Brasil
A história do lock-in no Brasil

Em 1984 tivemos a primeira lei de informática no Brasil, estabelecendo a reserva de mercado para este tipo de atividade cujo objetivo era fortalecer a indústria nacional para desenvolvimento de projetos de hardware e software básico bloqueando a entrada de equipamentos importados. Esta política governamental, na prática, fez com que várias empresas copiassem projetos estrangeiros com qualidade questionável e, consequentemente, freou o desenvolvimento de TI no Brasil.

Naquela época, as opções que tínhamos disponíveis no mercado era adquirir mainframes - computadores de grande porte -, especialmente da IBM que possuía uma fábrica no Brasil, comercializar esse tipo de equipamento, ou comprar uma máquina nacional muitas vezes obsoleta em relação às tecnologias disponíveis fora do país. Resultado: houve um aumento brutal na base de mainframes que perdura até hoje!

Nossa história nos permite entender o porquê somos a quinta maior base de mainframes do mundo e a sexta em termos de compra anual dessa tecnologia. O Mainframe é um ótimo exemplo de lock-in, sendo uma tecnologia estável, porém cara, rodando um legado muito antigo que traz para o cliente uma equação muito complexa: migrar da grande máquina física para uma outra plataforma economizando muito dinheiro em termos de manutenção.

O lock-in é um artifício que os fabricantes de TI utilizam para manter a base instalada, ganhando dinheiro com suporte, manutenção, expansões e crescimento orgânico. Mas como evitá-la? O exemplo do mainframe mostra que isso não é tão fácil, já que pode-se cair em armadilhas do mercado, pois aparentemente parece ser a melhor opção na hora, mas anos depois você se vê encurralado com uma plataforma cara.

Continua após a publicidade

A solução, portanto, é sempre analisar as novas tecnologias disponíveis para evoluir a arquitetura que está utilizando atualmente para outra que permita separar componentes. É necessário ter uma liberdade de escolha (ou um impacto mínimo) para substituir um determinado componente por um outro que te traga mais vantagens (financeiras ou tecnológicas).

Em empresas de maior porte já existe o cargo cuja função é analisar o mercado em busca de novas tecnologias que tragam vantagens, evitando o lock-in. Há casos em que a decisão é partir para uma tecnologia proprietária, mas é importante saber as consequências disso.

A liberdade de adotar novas tecnologias de software conforme elas aparecem é algo que, na prática, precisa de diversos cuidados. Realizar uma análise da maturidade dessa tecnologia, se é uma tendência ou simplesmente algum modismo, além de levantar suas barreiras técnicas são alguns dos itens que recomendo a reflexão. Mas o mais importante: confira se a tecnologia que você está utilizando é proprietária e foi pensada em dificultar sua retirada/atualização. Não fique "preso", pois sua liberdade terá riscos e um alto custo. Há que se pensar numa arquitetura onde variados elementos possam ser substituídos sem grandes impactos no todo.

Tecnologias

Continua após a publicidade

Uma das primeiras tecnologias que apareceram com o forte discurso de ser uma plataforma livre que poderia rodar sem modificações em diversos sistemas operacionais/hardware foi o Java. Seu slogan, bastante ousado especialmente para a época (1995), era “Write Once, Run Everywhere”, ou seja, escreva o código uma vez e a aplicação gerada rodaria em qualquer plataforma.

Quando o Java surgiu, a internet estava em franca expansão e era preciso enriquecer o navegador com uma linguagem para permitir sair das páginas estáticas e promover uma interação com o usuário. O Java foi perfeito para isso, independentemente se você estivesse rodando em UNIX, Windows, Mac ou Linux, o mesmo programa rodaria. Claro que havia problemas de performance (que foram resolvidos com tecnologias como “just-in-time compilation” otimizações como o “HotSpot”) e detalhes técnicos que faziam que nem sempre isso funcionasse 100%.

Como evolução desse conceito surgiram os Servidores de Aplicação, e a especificação J2EE (Java 2 Enterprise Edition). O Servidores de Aplicação, ou simplesmente AS (do inglês Application Server), resolveram problemas que os programadores precisavam se preocupar na codificação da sua aplicação, como escalabilidade, redundância, conectores para integrar com outros aplicativos, segurança e, principalmente, padronização. A promessa dos AS vai além dessa simplificação/padronização do desenvolvimento e permite que a aplicação seja agnóstica de plataforma: o aplicativo desenvolvido em determinado AS consegue rodar em outros equipamentos com outros sistemas operacionais mas, ainda hoje, fica preso ao AS em si. A especificação J2EE não é suficiente para definir todos os recursos que os desenvolvedores precisam e existem expansões dessa especificação que cada fabricante de AS coloca para cobrir essa deficiência.

Por que não dá para ficarmos dentro da especificação e simplesmente ignorarmos as expansões? Tecnologias novas surgem diariamente e muitas vezes o que uma empresa está de olho é exatamente abraçar uma tecnologia nova que lhe dê uma vantagem competitiva em detrimento de sair da especificação. Existe um tempo necessário para que uma tecnologia nova entre na especificação afinal. Os grupos que as definem precisam fazer isso de forma controlada sem quebrar as anteriores.

Continua após a publicidade

Um outro ponto que deve ser explorado é que as especificações são regidas sobre as API (application programming interface, ou interfaces de programação), que definem como você deve codificar, porém não rege sobre os protocolos. A especificação de mensageria em Java (JMS), que cuida da comunicação entre os processos ou clientes, define claramente como deve ser feita a programação. Mas caso queira comunicar um processo de um AS de um determinado fabricante para outro AS, de outro fabricante, o protocolo de comunicação não é definido pela especificação, forçando-o a outro AS. E resumo: temos um lock-in do AS.

A camada de dados também é outro fator a ser pensado. Sabemos que grandes esforços estão sendo feitos para integrar dados de diversas fontes (bancos de dados diversos, sites diversos, até planilhas e arquivos de texto) que fazem parte da sua arquitetura de TI. Um conceito moderno é a virtualização da camada de dados.

Analogamente à virtualização de servidores, que foi um grande avanço por abstrair o servidores propriamente ditos dos Sistemas Operacionais, a virtualização da camada de dados permite maior agilidade e performance nas informações, independente do fabricante.

Se o fornecedor de resolve cobrar uma fortuna em licença e quer trocar o banco de dados, a aplicação não muda. O problema, como sempre, são as armadilhas que os fabricantes de banco de dados proprietários dispõe, sempre com o argumento de melhoria de performance e aumento de flexibilidade, mas que te dificultam sair da tecnologia adotada. Fuja do lock-in!