Para quase todas as 82% das organizações que adotaram uma abordagem nativa da nuvem, a mudança não cumpriu totalmente a sua promessa, de acordo com uma nova pesquisa.
Das organizações que “se tornaram nativas da nuvem”, 95% relataram que os desafios as impedem de ver todos os benefícios do desenvolvimento nativo da nuvem.
Entre os principais desafios: adaptar processos legados à nuvem (citado por 46% dos adotantes nativos da nuvem), treinar suas equipes de desenvolvimento (também relatado por 46%) e automatizar processos como testes, implantação e monitoramento (44%).
Esses desafios estão a ter repercussões, indicou o inquérito. Os usuários estão enfrentando problemas relacionados à segurança, expansão de ferramentas e dificuldades culturais, incluindo má colaboração entre desenvolvedores, segurança e operações.
A pesquisa online, realizada em setembro pela Foundry, uma subsidiária integral da IDG, para a UST, uma empresa de serviços de transformação digital, entrevistou 100 profissionais e executivos de TI.
Os entrevistados trabalhavam em TI ou em funções de gerenciamento executivo em grandes empresas que estão testando, testando ou adotando abordagens e ferramentas de desenvolvimento nativas da nuvem. Quase metade era do C Suite, com engenheiros seniores e gerentes de TI constituindo o restante.
Embora o tamanho da amostra seja pequeno, a pesquisa destaca algumas tendências interessantes e alguns dos desafios envolvidos na transição para o desenvolvimento nativo da nuvem.
As descobertas do estudo devem ser consideradas neste contexto: os pesquisadores usaram uma definição visivelmente mais ampla de “nativo da nuvem” do que a aceita por órgãos como a Cloud Native Computing Foundation.
O nativo da nuvem talvez esteja sofrendo de uma definição cada vez mais confusa – o que o desenvolvedor e autor de software, Martin Fowler, chama brilhantemente de “difusão semântica”. Como Holly Cummins, principal engenheira de software sênior da Red Hat, disse ao The New Stack: “Muitas vezes pensei que apenas usamos o nativo da nuvem como sinônimo de ‘moderno e agradável’ ou ‘construído na década de 2020’”.
Dito isto, o que a pesquisa destaca é interessante — em particular, o uso generalizado de ferramentas de baixo código/sem código, com 57% de uso em alguns setores, e o forte interesse em IA generativa.
Este último talvez não seja surpreendente, dado o ponto em que estamos no ciclo de hype da IA, mas é impressionante ver ferramentas de baixo código obtendo esse nível de adoção. Talvez isso seja um indicativo de quão melhor é a geração atual de ferramentas de low-code quando comparada às suas antecessoras, como observado quando analisamos o Choreo do WS02.
A maioria dos entrevistados cita a eficiência de custos e a agilidade dos negócios como os principais impulsionadores da migração para a nuvem. A escalabilidade também obteve pontuação alta.
Isso está de acordo com minha própria experiência. Como Anne Currie e eu observamos em nosso livro “The Cloud Native Attitude”, alguma combinação de velocidade, escala e margem são os motivos mais comuns pelos quais as empresas migram para a nuvem a partir de seus próprios data centers. Curiosamente, esta pesquisa também destaca o aspecto mais cultural de melhorar a colaboração entre operações, desenvolvedores e SREs, com 37% das empresas citando isso.
Os participantes da pesquisa citaram o seguinte nível de adoção de diversas tecnologias associadas a arquiteturas de nuvem distribuídas:
Microsserviços e sem servidor, quando implementados corretamente, combinam bem com o objetivo de aumentar a agilidade dos negócios. No entanto, para fazer isso, você precisa de unidades implantáveis de forma independente, o que, por sua vez, significa definir corretamente os limites do serviço – uma área com a qual muitas pessoas têm dificuldade. Se você se deparar com uma situação em que seu pipeline de CI/CD precise implantar muitos ou todos os seus microsserviços juntos, provavelmente não ganhará nada.
Se você acertar os limites do serviço, poderá criar novas funcionalidades com mais rapidez e obter forte escalabilidade horizontal, mas com um custo considerável em complexidade operacional. Essa complexidade fez com que empresas como Netflix e Facebook construíssem suas próprias ferramentas de observabilidade, mais tarde disponibilizadas de forma mais ampla por meio de fornecedores de código aberto e pioneiros como Honeycomb.io.
Na pesquisa, podemos ver esse desafio refletido nos 31% de empresas que observaram um tempo mais longo para detectar erros e nos 29% que mencionaram visibilidade/observabilidade reduzida no ambiente de aplicação — uma questão com maior probabilidade de ser citada por empresas maiores ( definidas aqui como aquelas empresas com receitas de US$ 10 bilhões ou mais).
Em 45% das empresas, o âmbito das responsabilidades de segurança aumentou para os programadores, presumivelmente como consequência da adopção de uma abordagem de “mudança para a esquerda”, sendo os das grandes empresas mais afectados.
Um corolário vem de um relatório de 2022 da Shadowserver Foundation, que afirmava que mais de 380.000 APIs Kubernetes em todo o mundo foram expostas à Internet pública. Isto reflete a crescente complexidade que os desenvolvedores enfrentam. Ambientes distribuídos aumentam a superfície de ataque e a falta de visibilidade agrava o problema.
Entre os outros principais pontos problemáticos citados pelas equipes de desenvolvimento na pesquisa da UST:
É um erro supor que se dermos mais autonomia aos nossos desenvolvedores para escolherem as ferramentas e linguagens que desejam, eles serão mais felizes e produtivos. Na minha experiência, os desenvolvedores muitas vezes preferem que essas escolhas tenham sido feitas por eles, desde que sejam capazes de tomar decisões diferentes se suas demandas específicas assim o exigirem.
“Além do deslocamento para a esquerda, deveríamos considerar o deslocamento para baixo”, disse Cummins, da Red Hat. “Não expanda apenas a função de um engenheiro; mova algumas das coisas que são um pouco chatas, tediosas e repetitivas para nossas plataformas por meio de maior automação e curadoria aprimorada. Desta forma, beneficiamos de plataformas de maior valor, em vez de permitir que estas tecnologias se tornem um fardo extra.”
Carl Coryell-Martin, diretor sênior da Cloud Advisory, UST, ecoou esse sentimento, sugerindo que muitas organizações pesquisadas não estão implementando engenharia de plataforma – ou não a implementam corretamente.
“Acho que o Kubernetes é muito perigoso quando está no nível da equipe de desenvolvimento”, disse ele. “Você pode ver problemas sinalizados no equilíbrio entre produtividade e risco, e no aumento nas cargas de trabalho de segurança. As empresas não estão entendendo ou investindo na disciplina de engenharia de plataforma.”
Esta falta de investimento em engenharia de plataformas é muitas vezes uma consequência da forma como o financiamento funciona em organizações maiores.
Em um podcast “Hacking the Org” que fiz no início deste ano com Paula Kennedy, COO da Syntasso, abordamos alguns antipadrões, como quando o dinheiro fica com a equipe de produto e a equipe de plataforma acaba ficando sem recursos. Kennedy sugeriu que isso aconteceu porque “as equipes de plataforma são vistas apenas como mais um custo de infraestrutura”.
Coryell-Martin repetiu essa ideia, dizendo ao The New Stack que: “É difícil pagar pela engenharia de plataforma porque é um novo recurso cujo desenvolvimento é caro. Um cliente empresarial típico preferiria gastar 10% a mais na construção de seu aplicativo do que pagar pelo desenvolvimento de uma plataforma.”
Além disso, ele acrescentou: “Embora o benefício de uma engenharia de plataforma eficaz esteja espalhado por todos os resultados de negócios, ele só será eficaz se você puder mudar a forma como as equipes estão trabalhando”.
Um conselho que ele deu foi construir uma prova de conceito no nível individual da equipe. Isso permite que você mostre uma equipe que é capaz de entregar software com muito mais rapidez e qualidade. Então, disse Coryell-Martin, “você precisa ter uma conversa com o CFO e o CIO, ou CTO, onde você fala sobre os benefícios comerciais que você pode obter se fornecer qualidade superior”.
Eu acrescentaria que, como desenvolvedores e líderes de equipes de software, também precisamos ser melhores em colocar nossos argumentos em termos comerciais. Não faz sentido tentar persuadir um patrocinador de negócios a investir em uma plataforma, em mais automação ou a pagar dívidas técnicas, se não houver um benefício comercial claramente definido em fazê-lo.
Outra questão destacada por Coryell-Martin: “Muitos obstáculos para o sucesso estão emaranhados e, para perceber o resultado transformador do desenvolvimento nativo da nuvem, é necessário resolver todos eles. Não é o caso de ‘eu resolvo um e a vida fica 10% melhor, e então eu resolvo um segundo e a vida fica outros 10% melhor’. Em vez disso, cada um torna a vida cerca de 2% melhor, mas quando você resolve todo o conjunto de 10 coisas, sua vida fica 100% melhor.”
Esse conjunto de coisas inclui aspectos culturais e também tecnológicos. Cummins chegou ao ponto de argumentar que “nativo da nuvem tem a ver com cultura, não com contêineres”.
Os resultados da nova pesquisa ressaltam isso, disse Cummins. “Nativo da nuvem é difícil e você precisa pensar nas pessoas”, disse ela. “Embora alguns dos desafios fossem técnicos, muitos diziam respeito a pessoas que não tinham as competências necessárias ou ao facto de os processos empresariais existentes não terem sido corrigidos tanto quanto esperavam. Portanto, se a motivação para migrar para a nuvem nativa era a agilidade, essas tecnologias por si só não melhoraram a colaboração, o que continuou sendo um ponto de discórdia.”
Isto pode ser verdade mesmo quando o custo é o principal motivador, porque muitas vezes o que aumenta os custos é a falta de colaboração eficaz.
Cummins reiterou que é realmente importante pensar sobre qual problema você está tentando resolver: “Se você investir e esperar melhorar a agilidade, isso não ajudará”.
A colaboração bem-sucedida exige que você tenha uma forte segurança psicológica. “Um pré-requisito para uma transformação nativa da nuvem bem-sucedida é que as pessoas confiem na organização”, disse Cummins, “para que os funcionários não gastem toda a sua energia tentando proteger o que possuem”.
Da mesma forma, as pessoas ficarão relutantes em lhe contar coisas se acharem que os empregos podem estar em risco. “Não vou falar sobre uma ineficiência se achar que meus amigos serão demitidos, porque você precisará de menos funcionários para consertar isso”, disse Coryell-Martin.
Em qualquer grande transformação, você também corre o risco de que sua equipe de TI se torne mais qualificada e valiosa – e então saia em busca de oportunidades mais atraentes.
“Já me deparei com situações muitas vezes em que uma empresa estaria se transformando e então seus melhores funcionários estariam evaporando da empresa”, disse Coryell-Martin. Algum atrito é inevitável, mas você precisa ter certeza de que está aumentando os salários de acordo com o valor de mercado.
Tudo isso parece bastante negativo. Mas, disse Coryell-Martin, enfrentar os desafios de uma transformação nativa da nuvem vale a pena para muitas organizações.
“É possível com o nativo da nuvem criar um conjunto de relações de trabalho, estruturas de equipe, ferramentas e recursos de engenharia de plataforma que resultam em resultados 10 vezes melhores”, disse ele. “As equipes estão mais satisfeitas, seus clientes empresariais estão muito mais felizes porque estão fornecendo software melhor e seu pessoal de controle está mais relaxado porque é mais seguro.
“Não há compromisso entre produtividade e risco se você estiver gerenciando o risco na plataforma e removendo a maior parte dele da camada da equipe. Um mundo melhor é realmente possível.”
YOUTUBE.COM/THENEWSTACK
A tecnologia avança rápido, não perca um episódio. Inscreva-se em nosso canal no YouTube para transmitir todos os nossos podcasts, entrevistas, demonstrações e muito mais.
SE INSCREVER
