O aprisionamento tecnológico (vendor lock-in) costuma representar um risco, sobretudo no longo prazo, para projetos de tecnologia. Por isso, a recomendação padrão é de evitá-lo sempre que possível. Entretanto, há cenários em que tecnologias proprietárias fornecem vantagens difíceis de resistir.
Não é incomum que a adoção de tecnologias proprietárias colabore para a redução os custos (e prazos) de desenvolvimento. Entretanto, como penalidade, fica mais difícil barganhar vantagens mais tarde. Ainda pior, há o risco de tornar o software desenvolvido obsoleto junto com a tecnologia proprietária caso ela seja descontinuada por alguma razão.
[tweet]Cabe a prática da arquitetura de software consolidar a estratégia que governará as decisões relacionadas a ceder ou não ao lock-in imposto por determinados fornecedores.[/tweet]
Aprisionamento Tecnológico (Vendor Lock-in)
O aprisionamento tecnológico decorre de particularidades em produtos ou serviços que tornam seus usuários dependentes dos fornecedores, impedindo-os de trocar de fornecedor sem custos adicionais substanciais. Pode ser significativamente reforçado pelo efeito de rede, em que os usuários se vêem presos a determinados produtos ou serviços por interoperabilidade com outros usuários, ou por dependerem de massa crítica econômica em mercados correlatos como recursos humanos ou suporte técnico.
Em Informática, o aprisionamento tecnológico é tipicamente empregado por fornecedores incumbentes de programas de computador, como IBM, Microsoft, Oracle, Google ou Apple por exemplo.
Discussões sobre as vantagens e desvantagens de “ceder” ao aprisionamento tecnológico tem ficado mais frequentes com a pressão crescente pela migração de aplicações para a nuvem. Quem utiliza AWS quer ter a liberdade de poder migrar para Azure e vice-versa, por exemplo. De forma análoga, é interessante ter poucas barreiras para modificar, inclusive, o stack de tecnologias fornecidas dentro de um mesmo provedor.
A mesma temática também ocorre, por exemplo, na seleção e uso de bancos de dados, plataformas de interface gráfica, ambientes operacionais, etc.
Alguns times optam por nunca utilizar tecnologias proprietárias. Para isso, utilizam apenas produtos tecnológicos próprios, mantidos por consórcios ou implementados respeitando estritamente especificações abertas.
Essa linha de ação foi acertada, por exemplo, para todos aqueles que optaram por construir interfaces ricas usando HTML5+CSS3 no lugar de plug-ins proprietários como Flash ou Silverlight. Entretanto, não é desprezível que haviam características nessas tecnologias que poderiam reduzir o time-to-market impactando positivamente o negócio.
Netflix e Silverlight
A Netflix foi um dos maiores casos de uso do Silverlight – tecnologia legada da Microsoft para desenvolvimento de interfaces ricas na Web. Na época, isso fazia sentido por causa do amplo suporte de streaming da tecnologia. Seguramente, acelerou o negócio da empresa.
Em 2014, a Netflix desenvolveu novamente a interface, dessa vez, utilizando HTML5. O custo de ambas as decisões foi elevado, mas, estrategicamente, fez sentido para a companhia.
No passado, quando a “guerra dos bancos de dados relacionais” era mais visceral, era comum tentar evitar o lock-in a um fornecedor utilizando apenas recursos presentes na especificação comum da SQL. O custo dessa decisão era deixar de aproveitar os “diferenciais” das engines.
Modernamente, voltando a discussão sobre arquiteturas para a nuvem, é comum ver times restringindo seleção a tecnologias “Cloud Native”.
Há também aqueles que optam por suportar mais de uma alternativa de tecnologia proprietária, para um mesmo propósito, simultaneamente. Para isso, acabam desenvolvendo “mais de uma vez” determinados componentes, cada vez com uma tecnologia diferente.
Essa abordagem costuma fazer sentido em um primeiro momento tanto para reduzir o lock-in quanto para poder ofertar propostas mais flexíveis para o mercado. No passado, era comum ver empresas desenvolvendo aplicações que “funcionavam” tanto com SQL Server quanto com Oracle. Entretanto, esta abordagem acaba se tornando difícil de sustentar em função do alto custo de manutenção.
Em princípio, recursos específicos de cada tecnologia ficam acessíveis nas implementações independentes. De qualquer maneira, nenhuma funcionalidade específica poderá ser desenvolvida se for exclusiva de uma das tecnologias.
Há ainda quem opte por utilizar uma tecnologia proprietária, porém isolando-a em componentes, sob abstrações. Nesses casos, a tecnologia proprietária é empregada mas é acessada apenas indiretamente. Assim, pelo menos em teoria, uma migração ficaria menos “difícil”.
O problema dessa abordagem é que ela acaba “mascarando” a interface da tecnologia proprietária gerando, com muita frequência, defasagem de atualização, não permitindo que todas as vantagens da tecnologia adotada sejam exploradas.
Finalmente, alguns times optam por adotar “explicitamente” uma tecnologia proprietária, sem recorrer a abstrações. Para isso, abrem mão da possibilidade de substituir tal tecnologia – pelo menos, sem pagar por um alto custo.
Ao selecionar uma tecnologia proprietária, muitas vezes os times ficam limitados quanto a opções de ferramentas e tipos de integração, dificultando, muitas vezes, a configuração de ambientes. Por outro lado, tecnologias proprietárias oferecem soluções prontas, que permitem a concentração dos esforços às aplicações, e não à infraestrutura.
Em resumo, eventualmente o aprisionamento tecnológico estará presente, seja com o provedor de nuvem, ou até mesmo com a própria linguagem de programação. Não utilizar todos os recursos oferecidos pelas tecnologias proprietárias, limita o aproveitamento de todo o poder que elas nos proporcionam, impactando diretamente no velocity.
Em contrapartida, dependendo do cenário, evitar o lock-in pode ser o requisito, como ambientes de multi-cloud, utilizando aplicações portáveis. Há de se reconhecer, inclusive, que os padrões abertos, no caso da nuvem, em muitos cenários, estão mais poderosos que as tecnologias proprietárias. Para ter maior assertividade na seleção tecnológica, durante o planejamento deve-se avaliar o impacto das vantagens e desvantagens de cada abordagem, envolvendo o negócio nessas discussões, entendendo as demandas da solução e ponderando entre riscos e benefícios.
Colocando as coisas sob esta perspectiva e considerando todas as preocupações envolvidas em retrospecto ao que eu vivenciei, é impossível pra mim não concluir que o tempo e energia gastos nisto são um desperdício.
Será mesmo que existe um “aprisionamento”? Será que não seria uma mera questão de perspectiva?
Me pergunto se a paranóia com Lock-Ins como uma medida de proteger seu negócio seja uma estratégia responsável.
Claro, não podemos ignorar que tecnologias surgem e morrem todos os dias. Mas, olhemos para o caso do Flash, que por mais de uma década viabilizou e sustentou produtos que confiaram na sua suportabilidade até que um dia ela deixou de ser dada como garantida e então uma multidão de empresas tiveram que encarar o fim dele como um fato consumado e adaptar seus produtos. Me pergunto: quantos produtos deixaram de existir por conta do fim de flash, e quantos outros (elaborados em flash) deixaram de existir por motivos completamente diferentes? Ninguém quer correr o risco de, da noite pro dia, se ver obrigado a redesenvolver seu produto devido a uma mudança na tecnologia.
…
Ou será que não?
Vamos encarar um caso específico: Todo o mercado financeiro e todos os profissionais de finanças trabalhando nos mais diversos setores (claro, sempre considerando as exceções) funcionam baseados em um produto específico e um único Vendor: Excel. Me pergunto quantas empresas e profissionais estão preparados para o fim do Excel. No entanto, não tem quase ninguém realmente preocupado com isto (afinal, o Excel não pretende morrer tão cedo… muito embora o Flash também não fizesse planos para sair de cena), apesar de produtos competitivos já estarem presentes no mercado. Mesmo assim, o Excel não esteve por aí desde sempre.
Realmente, me parece que perdemos muito tempo e energia discutindo fatores que estão completamente fora do nosso controle, e que não tenho certeza se faz sentido discutir. Pelo menos não no aspecto de “aprisionamento”. Afinal, o sucesso do seu produto muito provavelmente não está na dependência das tecnologias que rodam por trás dele (no sentido de que elas não possam ser revistas na iminência de que elas deixem de atendê-lo). É muito mais provável até que tecnologias deixem de ser usadas por que outras melhores passaram a existir, viabilizando novas oportunidades para o negócio, e ainda assim, é um processo que pode ser planejado e transitório. As coisas dificilmente acontecem da noite para o dia.
Ótimo post. Vou me debruçar um pouco mais pra pensar nas implicações de não evitar aprisionamento.