Fazer login no IT Mídia Redefinir senha
Bem-vindo de volta,
Digite seu e-mail e clique em enviar
Ainda não tem uma conta? Cadastre-se
Salvar em Nova pasta de favoritos

+

Criar pasta
Salvar Escolher Pasta
A maneira errada de pensar sobre cloud computing
Home > Tendências

A maneira errada de pensar sobre cloud computing

Mover cargas de trabalho para dentro e para fora da nuvem não é realmente possível - ou uma boa ideia

Matt Asay, Infoworld (EUA)

30/06/2021 às 9h49

Foto: Adobe Stock

Sarah Wang e Martin Casado, investidores da Andreesen Horowitz, disseram recentemente que a mudança para a nuvem prejudica as margens de lucro e pode custar às empresas públicas até US$ 500 bilhões em capitalização coletiva de mercado. Esta é uma afirmação ousada e controversa. E também errada.

Ou, dito de forma mais educada e precisa, seu foco na economia de custos pode ser a resposta certa para a pergunta errada. “A otimização de custos sempre fica em segundo plano, reduzindo o tempo de lançamento/velocidade de recursos” com os compradores corporativos, contrapôs Corey Quinn, Analista do Duckbill Group. Não, às vezes. Não, frequentemente. Sempre. “Fundamentalmente, as empresas que se concentram mais na otimização/redução de custos do que no crescimento tendem a ser empresas em declínio”, continuou Quinn.

Em outras palavras, a pergunta certa não é "nuvem ou local?" A TI corporativa é muito complicada para respostas fáceis a perguntas binárias como essa. A pergunta certa é “Qual abordagem (entre essas ou outras) dá a uma empresa a capacidade máxima de investir para o crescimento?”

O sonho da febre da repatriação

Wang e Casado trabalham para uma das empresas de investimento mais bem-sucedidas do mundo. Seu objetivo é ajudar empresas a crescer e lucrar quando essas empresas abrem o capital ou são adquiridas. Eles pensaram muito em sua tese. Em resumo, a teoria deles é: “embora a nuvem cumpra claramente sua promessa no início da jornada de uma empresa, a pressão que ela coloca sobre as margens pode começar a superar os benefícios à medida que a empresa cresce e o crescimento diminui”. Como consequência, eles sugerem que a nuvem custe às empresas públicas até meio trilhão de dólares em capitalização coletiva de mercado.

Isto é muito dinheiro.

Eles sugerem que as startups criem opcionalidades em sua arquitetura desde o início. As empresas devem arquitetar sua infraestrutura de forma que seja mais fácil “repatriar” as cargas de trabalho da nuvem para os data centers locais quando o custo de fazer isso fizer sentido.

É um pensamento bom, mas é completamente impraticável. A TI corporativa simplesmente não funciona assim no mundo real. Ninguém move cargas de trabalho para a nuvem por capricho e ninguém as move de volta por outro capricho. Há todo tipo de inércia para complicar esses planos, incluindo a tecnologia para fazer isso. E não, o Kubernetes não é uma panaceia que move magicamente as cargas de trabalho entre as nuvens ou entre um data center privado e a nuvem, algo que já destaquei antes.

Esse é um dos motivos pelos quais a nuvem, apesar de ser um grande negócio, ainda representa apenas 5% a 6% dos gastos globais de TI. Antes que você diga “mas o Dropbox conseguiu”, o Dropbox não é um modelo que a maioria das empresas pode seguir: ele moveu um aplicativo de nicho para seu data center privado com o tipo de recursos que praticamente nenhuma outra empresa possui. Não é um poster da repatriação.

Há também um problema à parte que Quinn apontou: "Ao construir para um êxodo teórico, você paga pela opcionalidade com a velocidade do recurso e reduz suas chances de chegar a uma posição em que os custos da nuvem sejam até mesmo importantes para o sucesso geral do seu negócio".

Mas espere, tem mais!

Fazendo pessoas caras fazerem coisas básicas

Subbu Allamaraju dirige as equipes que criam os produtos de pesquisa e descoberta da Expedia. O primeiro problema que ele lista com o argumento de Wang/Casado é a crítica do Kubernetes que mencionei acima: “Não há tecnologia que possa ajudar a repatriar. A referência do Kubernetes é uma mentira que contamos a nós mesmos”. Allamaraju não está dizendo que o Kubernetes não tem valor - longe disso. Ele está argumentando contra a ideia de que o Kubernetes torna todos os aplicativos fungíveis entre ambientes operacionais.

Essa é uma condenação do argumento de Wang e Casado, mas Allamaraju vai além.

O maior problema são as pessoas. “As empresas que operam com sucesso (alta agilidade e custos gerenciáveis) no local devem gastar mais de três a cinco anos de alguns de seus melhores talentos de engenharia para amadurecer a arquitetura e a engenharia de sua infraestrutura central (comece com os primitivos). Muito poucos podem pagar por isso”, argumenta ele. Mesmo se sua empresa pudesse pagar, você realmente gostaria? Afinal, Zack Kanter, Cofundador e CEO da Stedi, diz que reconstruir a nuvem para economizar algum dinheiro significa que você está aceitando o “custo cultural (devastador a longo prazo) de recrutar engenheiros de classe mundial para fazer um trabalho pesado indiferenciado”.

Mesmo se você de alguma forma conseguir reter engenheiros encarregados de construir serviços de nuvem de nível básico (computação, armazenamento, etc.), você perdeu totalmente o ponto da nuvem, tanto Kanter, quanto Quinn enfatizam. O valor real de construir em uma nuvem pública são os serviços de nível superior, não necessariamente os blocos de construção básicos. No momento em que você replica esses serviços de nível inferior, já passou anos perdendo os bits de ordem superior.

Allamaraju termina apoiando algo que Quinn disse acima: “Para ser bem-sucedido em escala em uma arquitetura híbrida e maximizar o valor do cliente, a eficiência de custos e a agilidade, é necessário tomar um grande número de decisões técnicas, de pessoas e de processos com antecedência, anos antes do necessário. Mesmo que você possa pagar por isso, é improvável que acerte”. Parece ótimo pensar uma década à frente na infraestrutura de alguém para construir opções de longo prazo. Também é um sonho irreal. Sim, existem coisas que podemos e devemos fazer para preservar a agilidade arquitetônica. Mas a abordagem recomendada de Wang e Casado custa muito para alcançar muito pouco.

Snippets HTML5 default Intervenções CW
Vai um cookie?

A CIO usa cookies para personalizar conteúdo e anúncios, para melhorar sua experiência em nosso site. Ao continuar, você aceitará o uso. Para mais detalhes veja nossa Política de Privacidade.

Este anúncio desaparecerá em:

Fechar anúncio

15