A computação nativa em nuvem passou a dominar a TI empresarial para todas as organizações que exigem infraestrutura dinâmica e flexível em escala.
Kubernetes e o restante do ecossistema nativo da nuvem O Kubernetes permite que as empresas criem e implantem aplicativos de forma mais rápida, confiável e com menor custo, mas pode ser complexo e difícil de dominar. As promessas de velocidade e escala podem parecer fora de alcance quando as equipes de desenvolvimento se preocupam com os detalhes. Para construir esse software, os desenvolvedores precisam de toda a ajuda possível.
As práticas e ferramentas DevOps são essenciais, mas são apenas o ponto de partida. Para ter sucesso com DevOps em ambientes nativos de nuvem, as organizações esperam construir plataformas internas de desenvolvedores (IDPs) seguindo as práticas recomendadas de engenharia de plataforma ainda nascentes.
O objetivo da engenharia de plataforma é melhorar a produtividade do desenvolvedor. E se as equipes de desenvolvimento forem produtivas, elas deverão ser capazes de implantar software na velocidade e na escala exigidas pelo negócio.
Mesmo com os deslocados internos em vigor, no entanto, os objetivos do desenvolvimento nativo da nuvem estabelecem um padrão elevado para as organizações que buscam seus benefícios. Para cada passo à frente, eles parecem dar um passo para trás.
Um foco excessivo na produtividade do desenvolvedor pode sair pela culatra. A engenharia de plataforma pode afastar os desenvolvedores de forma contra-intuitiva. E quanto mais complexas as implantações nativas da nuvem se tornam, mais difíceis são de gerenciar.
Este artigo — o primeiro de uma série de três — explorará esses paradoxos.
Como as organizações podem atingir as metas de negócios de seus esforços de software quando tantas armadilhas ameaçam seu sucesso?
Todos concordam que a produtividade do desenvolvedor é uma coisa boa. Quanto mais produtivos forem os desenvolvedores, mais software eles poderão fornecer para cada dólar que suas organizações lhes pagam.
O problema com a produtividade do desenvolvedor, entretanto, é como medi-la.
A McKinsey abordou essa questão em um artigo controverso recente: “Sim, você pode medir a produtividade do desenvolvedor de software,” no qual teorizou que tal medição pode melhorar os resultados do desenvolvimento de software.
Em particular, a McKinsey postulou que quando os desenvolvedores concentram suas atividades na construção, codificação e teste de software, eles estão sendo produtivos. Outras atividades “leves”, incluindo planejamento, pensamento, orientação e arquitetura, sugam a produtividade do desenvolvedor.
Dada essa perspectiva, fica claro por que os desenvolvedores estão recuando. Qualquer abordagem de medição de produtividade que siga as recomendações da McKinsey ignorará completamente o fato de que os desenvolvedores que concentram seus esforços na parte “soft” de seus trabalhos são, na verdade, mais produtivos e valiosos para sua organização em geral, em comparação com seus colegas que passam todo o seu tempo com suas mãos em seus teclados.
Iniciativas complexas de software, como o nativo da nuvem, apenas agravam essa desconexão em relação à produtividade do desenvolvedor. Na mentalidade nativa da nuvem, os desenvolvedores mais produtivos são aqueles que se concentram no que torna o software dinâmico e escalável que atenda às necessidades do negócio, independentemente de quanto tempo gastam codificando.
Os desenvolvedores não gostam de ser medidos com métricas personalizadas, como uma série de solicitações pull. Para otimizar a produtividade, é melhor deixar que os próprios desenvolvedores decidam em quais atividades devem se concentrar.
Dada a infinidade de ferramentas DevOps no mercado, montar o conjunto de ferramentas ideal pode atrasar todos e levar a resultados inconsistentes.
A solução: garantir que as equipes de engenharia de plataforma construam um IDP que inclua o melhor conjunto de ferramentas para as tarefas em questão. O objetivo dessa plataforma é fornecer um “caminho de ouro” a ser seguido pelos desenvolvedores, essencialmente um conjunto recomendado de ferramentas e processos para realizar seu trabalho.
Contudo, este caminho dourado pode tornar-se uma camisa de força. Quando esse caminho dourado for excessivamente normativo, os desenvolvedores se afastarão dele para realizar seu trabalho, frustrando seu propósito.
Assim como acontece com a medição de sua produtividade, os desenvolvedores desejam poder fazer suas próprias escolhas em relação à forma como criarão software.
Como resultado, os engenheiros de plataforma devem ter um cuidado especial ao criar IDPs para desenvolvimento nativo da nuvem. Chegar à conclusão de que ferramentas e práticas que eram adequadas para outras abordagens arquitetônicas também são apropriadas para nativas da nuvem pode ser um grande erro.
Por exemplo, as ferramentas de observabilidade são um componente importante de qualquer IDP, mas a maioria das ferramentas de observabilidade não se adapta às necessidades dos desenvolvedores nativos da nuvem. Em vez disso, uma ferramenta de observabilidade como o Chronosphere, executada no Google Cloud, fornecerá aos desenvolvedores nativos da nuvem os insights necessários para realizar seu trabalho, mesmo em ambientes complexos e dinâmicos.
Essa mentalidade nativa da nuvem traz um foco arquitetônico ao trabalho dos desenvolvedores.
Os desenvolvedores nativos da nuvem criam microsserviços individuais, mas também devem monitorar o comportamento dos pods em clusters e dos clusters em frotas de clusters. Em outras palavras, eles devem focar na floresta e ao mesmo tempo focar nas árvores.
A produtividade do desenvolvedor depende desse foco duplo. Qualquer esforço bem-sucedido de engenharia de plataforma também funciona.
Como, então, resolver este paradoxo floresta versus árvores? A resposta está nos dados. A única maneira de manter um foco adequado no panorama geral ao desenvolver microsserviços é ter uma compreensão de todos os dados relevantes sobre o desempenho da infraestrutura nativa da nuvem.
Muitos dados, no entanto, são piores do que poucos, e é por isso que a observabilidade nativa da nuvem a partir de ferramentas, juntamente com a mentalidade nativa da nuvem que o Google Cloud traz para a mesa, são essenciais para atingir os objetivos de negócios da computação nativa da nuvem.
A resolução destes paradoxos depende de alcançar o equilíbrio certo.
Muito foco na produtividade do desenvolvedor é contraproducente, mas muito pouco deixará áreas de melhoria inexploradas. A resposta: ouça seus desenvolvedores para encontrar o equilíbrio certo.
Um IDP excessivamente restrito fará com que os desenvolvedores encontrem maneiras de contorná-lo, frustrando seu propósito. Construir um IDP que siga a mentalidade nativa da nuvem ajudará a alcançar o equilíbrio adequado.
Incentivar os desenvolvedores a compreender o panorama geral da computação nativa em nuvem em escala é essencial para atingir os objetivos do esforço de software, mas sem os dados de observabilidade adequados, eles nunca encontrarão o equilíbrio entre esse panorama geral e seu trabalho diário de construir e implantar microsserviços.
Toda a noção de uma mentalidade nativa da nuvem, portanto, compreende todos esses atos de equilíbrio. Ouça seus desenvolvedores, forneça-lhes os dados corretos e deixe-os encontrar o equilíbrio.
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
