Isso Você Não Pode Virtualizar!

Recebemos isso o tempo todo em TI: um fornecedor nos diz que um sistema não pode ser virtualizado. As razões são inúmeras. Do lado de TI, ficamos sempre chocados que um fornecedor faça uma afirmação tão absurda; e muitas vezes ficamos igualmente chocados que um cliente (ou gestor) acredite nele. Os fornecedores trabalharam arduamente para aperfeiçoar esse discurso de vendas ao longo dos anos, e acho importante dissecá-lo.

A causa raiz dos problemas é que os fornecedores estão quase sempre buscando maneiras de reduzir os próprios custos enquanto aumentam os lucros obtidos dos clientes. Isso impulsiona boa parte do que, de outra forma, seria visto como um comportamento estranho.

Uma coisa que muitos e muitos fornecedores tentam fazer é limitar os cenários sob os quais seu produto terá suporte. Ao fazer isso, eles se preparam para simplesmente não fornecer suporte – o suporte é caro e pouco confiável. Essa é uma estratégia comum. Em alguns casos, isso é tão agressivo que nenhum cenário de implantação em produção aceitável sequer chega a existir.

Um meio muito comum de fazer isso é não dar suporte a nenhum sistema operacional com suporte vigente, depreciando de fato o próprio software do fornecedor (por exemplo, hoje isso significaria dar suporte apenas ao Windows XP e versões anteriores). Outro exemplo é dar suporte apenas a produtos que não estão licenciados para o caso de uso (um exemplo seria exigir o uso de um produto como o Windows 10 como servidor). E um dos casos mais comuns é proibir a virtualização.

Esses cenários colocam os clientes em posições difíceis porque, de um lado, eles têm as melhores práticas do setor, diretrizes de implantação padrão, ferramentas internas e políticas a cumprir; e, do outro lado, têm fornecedores que muitas vezes proíbem o projeto, o planejamento e a gestão adequados dos sistemas. Essas necessidades estão em conflito umas com as outras.

É claro que ninguém espera que todos os fornecedores deem suporte a todos os cenários possíveis. Limites precisam ser aplicados. Mas há um abismo gigantesco entre dar suporte a sistemas razoáveis e bem implantados e exigir ativamente implantações inaceitavelmente ruins. Esperamos que nossos fornecedores se comportem como parceiros de negócios e compartilhem um interesse comum em nosso sucesso ou, no mínimo, no sucesso de seu produto, e não busquem diretamente prejudicar ambas as causas. Esperaríamos que, no mínimo, suporte de melhor esforço fosse fornecido para qualquer cenário de implantação razoável e que suporte garantido fosse provavelmente oferecido para cenários adequadamente projetados e de melhores práticas.

Imagine um mundo em que dirigir dentro do limite de velocidade e usar o cinto de segurança violasse a garantia do seu carro e em que você só obtivesse suporte se dirigisse de forma imprudente e desprotegida!

Algumas coisas importantes precisam ser entendidas sobre a virtualização. A primeira é que a virtualização é uma melhor prática consolidada do setor e espera-se que seja utilizada em qualquer cenário de implantação em produção de serviços. A virtualização não é nada nova; mesmo no mercado de pequenas empresas, ela está na categoria de melhores práticas há bem mais de uma década, e há muitas décadas no espaço corporativo. Já passamos há muito tempo do ponto em que executar sistemas sem virtualização é considerado aceitável, e isso inclui implantações legadas que estão em funcionamento há muito tempo.

Há, é claro, sempre exceções raras a praticamente qualquer regra. Alguns sistemas precisam de acesso a hardware de caso muito especial e a virtualização pode não ser possível, embora, com o moderno passthrough de hardware, isso seja quase inédito hoje em dia. E alguns sistemas de latência extremamente baixa não podem ser virtualizados, mas eles normalmente se limitam apenas aos maiores bancos de investimento internacionais e aos fundos de hedge mais agressivos, e até mesmo a maioria desses casos de uso tradicionais foi eliminada por melhorias na virtualização que tornaram raras até mesmo essas situações. Mas o ponto fundamental é: se você não pode virtualizar, deveria ficar triste por não poder, e saberá claramente por que isso é impossível na sua situação. Em todos os outros casos, seu servidor precisa ser virtual.

Será que não é importante?

Se um fornecedor não permite que você siga as melhores práticas padrão para implantações saudáveis, o que isso diz sobre a opinião do próprio fornecedor a respeito de seu produto? Se estivéssemos falando de qualquer outra implantação, questionaríamos imediatamente por que estaríamos implantando um sistema de forma tão precária se pretendemos depender dele. Se nosso fornecedor nos obriga a agir dessa maneira, deveríamos reagir do mesmo modo – se o fornecedor não trata o produto com o mesmo grau de seriedade com que tratamos o menos importante de nossos serviços de TI, por que nós deveríamos?

Isso é um “descasamento de impedância”, como dizemos nos círculos de engenharia, entre nossas necessidades (sistemas de produção) e a forma como o fornecedor que cria esse sistema aparentemente os trata (sistemas de hobby ou entretenimento). Se precisamos depender desse produto para nossos negócios, precisamos de um fornecedor que esteja comprometido e compreenda as necessidades de negócio – que tenha uma mentalidade de produção. Se o produto não é direcionado a negócios ou não está pronto para negócios, precisamos estar cientes disso. Precisamos questionar por que achamos que deveríamos usar em produção, do qual dependemos e para o qual exigimos suporte, um serviço que não foi destinado a ser usado dessa maneira.

Será que tem suporte? Será que está sendo testado?

Algo que muitas vezes é negligenciado da perspectiva dos clientes é se os recursos de suporte necessários para um produto estão ou não disponíveis. Não é incomum que a equipe que dá suporte a um produto fique enxuta, ou até desapareça, mas que a empresa continue vendendo o produto na esperança de extrair dele o máximo que conseguir, apostando em improvisar diante de um problema ou simplesmente devolver o dinheiro do cliente caso o fornecedor seja pego em uma situação em que é simplesmente incapaz de dar suporte.

A maioria dos contratos de software estabelece que o dano máximo que pode ser cobrado do fornecedor é o custo do produto, ou o valor gasto para adquiri-lo. Em um caso como esse, o fornecedor não corre risco algum ao oferecer um produto ao qual não consegue dar suporte – mesmo cobrando um preço premium pelo suporte. Se o cliente consegue usar o produto, ótimo, eles são pagos. Se o cliente não consegue e o fornecedor não consegue dar suporte, eles apenas perdem um dinheiro que nunca teriam obtido de outra forma. O cliente assume todo o risco, não o fornecedor.

Isso sugere, é claro, que também há pouco ou nenhum teste contínuo do produto, e isso deveria ser motivo de preocupação adicional. O fato de o produto funcionar não significa que ele continuará funcionando. Colocar em operação um produto sem suporte, ou pior, impossível de receber suporte, significa que você está dependendo cada vez mais, com o passar do tempo, de um produto com um nível potencial de suporte provavelmente decrescente, piorando lentamente ao longo do tempo, justamente quando se esperaria que a necessidade de suporte e a dependência do software aumentassem.

Se um produto proprietário é implantado em produção, e a decisão é tomada de abrir mão das implantações de melhores práticas para atender às exigências de suporte, como isso pode se encaixar em uma matriz de decisão? Isso deveria implicar que o suporte adequado não existe? Mais uma vez, como antes, isso implica um descasamento com nossas necessidades.

 

Será que ele ainda está sendo desenvolvido?

Se as necessidades de implantação do software seguem práticas antigas e desatualizadas, ou exigem software ou design desatualizados (ou não razoavelmente atuais), então temos de questionar a probabilidade de o produto estar atualmente em desenvolvimento. Em alguns casos, podemos determinar isso observando o ciclo de lançamento do software por algum tempo, mas não em todos os casos. Há um receio razoável de que o produto possa estar morto, sem nenhuma equipe de desenvolvimento restante trabalhando nele. O código pode ser simplesmente antigo, uma dívida técnica que está sendo vendida na esperança de obter alguns últimos trocados de uma base de código antiga que foi abandonada. Esse processo é, na verdade, muito mais comum do que costuma se acreditar.

Casas de software menores muitas vezes conseguem desenvolver um pacote de software inicial, colocá-lo no mercado e disponibilizá-lo para venda, mas não conseguem arcar com os custos de reter ou recompor sua equipe de desenvolvimento após o(s) lançamento(s) inicial(is). Esse é, de fato, um cenário muito comum. Isso deixa os clientes com um produto que se espera tornar-se cada vez menos viável ao longo do tempo, com cenários de implantação cada vez mais arriscados e dados cada vez mais difíceis de extrair.

 

Como ele pode ter suporte se a plataforma não tem suporte?

Um paradoxo comum de algumas situações mais extremas é o software que, para se qualificar como “suportado”, exige outro software que ou está fora de suporte ou nunca teve suporte para o caso de uso pretendido. Exemplos comuns disso são exigir que um sistema servidor seja executado sobre um sistema operacional de desktop ou exigir versões de sistemas operacionais, bancos de dados ou outros componentes que já não têm suporte algum. Este último cenário é assustadoramente comum. Em uma situação como essa, é preciso perguntar se pode, então, existir alguma implantação em que o software possa ser considerado “suportado”? Se parte da pilha está sempre fora de suporte, então toda a pilha está sem suporte. Sempre haveria um motivo pelo qual o suporte poderia ser negado, não importa o quê. A própria razão pela qual, portanto, exigiríamos evitar as melhores práticas igualmente descartaria a escolha do próprio software em primeiro lugar.

Faltam habilidades e conhecimento no setor?

Talvez a questão que enfrentamos com problemas de suporte de software dessa natureza seja que a(s) equipe(s) que cria(m) o software simplesmente não sabe(m) como um bom software é feito e/ou como bons sistemas são implantados. Esse está entre os motivos mais razoáveis e válidos para o que nos levaria a essa situação. Mas, assim como as outras razões hipotéticas, isso nos deixa preocupados com a qualidade do software e com a possibilidade de o suporte estar realmente disponível. Se não podemos confiar que o fornecedor lide adequadamente com as partes mais visíveis do sistema, por que recorreríamos a ele como nossos especialistas para as partes que não conseguimos verificar?

O Grande Problema

O grande problema, e abrangente, do software que impõe exigências questionáveis de prática de implantação e manutenção em troca de desbloquear um suporte que de outra forma seria retido não é, como costumamos supor, uma questão de qualidade geral do software, mas sim de práticas viáveis de suporte e desenvolvimento. O fato de essas questões sugerirem uma preocupação significativa com o suporte de longo prazo deveria nos fazer questionar fortemente por que estamos escolhendo esses pacotes em primeiro lugar, enquanto esperamos um suporte robusto deles, quando, desde o início, temos preocupações muito visíveis e muito sérias.

Há, é claro, casos em que nenhum outro produto de software existe para suprir uma necessidade ou nenhum de viabilidade mais razoável. Essa situação deveria ser extremamente rara e, se tal situação existir, deveria ser vista como uma grande oportunidade de mercado para um fornecedor que busque entrar nesse espaço específico.

De uma perspectiva de negócios, é imperativo que as melhores práticas de infraestrutura técnica não sejam completamente ignoradas em troca do seguimento cego, ou quase cego, de exigências do fornecedor que, em qualquer outra situação, seriam consideradas imprudentes ou pouco profissionais. Por que tantas vezes deixamos de exigir excelência dos produtos centrais dos quais nossos negócios dependem dessa maneira? Isso coloca nossos negócios em risco, não apenas pela ação em si, mas muito mais ainda pelos riscos implicados pela própria existência de tal exigência.