O Cloud Native altera a produtividade e a experiência do desenvolvedor?

No primeiro artigo desta série, discuti os três paradoxos da engenharia de plataforma nativa da nuvem: como medir a produtividade do desenvolvedor pode reduzi-la inadvertidamente; como os esforços de engenharia de plataforma podem sair pela culatra por serem excessivamente normativos; e como os desenvolvedores nativos da nuvem devem se concentrar em microsserviços individuais, bem como no comportamento de pods e clusters simultaneamente.

No segundo artigo, meu colega Eric Newcomer explorou em profundidade os desafios que os engenheiros de plataforma enfrentam ao construir plataformas de desenvolvedores internos (IDPs) para desenvolvedores nativos da nuvem. Ele conclui que o sucesso requer a estrutura organizacional e a governança corretas, uma boa medida de disciplina e a combinação certa de ferramentas de plataforma no IDP – em particular, ferramentas de observabilidade que adaptam os dados especificamente para as equipes pequenas e autônomas que desenvolvem, implantam e dão suporte a microsserviços. .

Existem dois fios que interligam esses argumentos. A primeira é a produtividade do desenvolvedor – quanto desenvolvedores individuais e equipes podem realizar em um determinado período de tempo. O segundo tópico é igualmente importante: experiência do desenvolvedor, ou DX. DX é uma medida da eficácia com que os desenvolvedores podem realizar seu trabalho com as ferramentas e plataformas disponíveis, combinadas com o moral e a satisfação geral no trabalho.

Quanto mais desafios forem lançados aos desenvolvedores, mais difícil se tornará produzir um trabalho de qualidade de forma consistente. Simultaneamente, a pressão para aumentar a produtividade em tais situações pode ter um impacto negativo na experiência do desenvolvedor, uma situação que certamente sairá pela culatra.

O nativo da nuvem é uma área que apresenta tais desafios. Construir microsserviços no contexto de uma implantação nativa da nuvem em escala é difícil e complexo. Como, então, as organizações devem equilibrar a produtividade do desenvolvedor e o DX para iniciativas nativas da nuvem? E, idealmente, como ambos podem ser melhorados ao mesmo tempo?

Por que o desenvolvimento nativo da nuvem é tão desafiador

O desenvolvimento nativo da nuvem começa com microsserviços. E embora existam muitas definições de microsserviços (muitas delas nem sequer são “micro”), uma definição popular é uma “unidade de execução parcimoniosa e coesa”.

“Parcimonioso” significa tão pequeno quanto possível, mas não menor – a parte “micro” da história. “Coesão” é uma característica bem conhecida de um bom software, o que significa que cada microsserviço faz bem uma coisa.

“Unidade de execução” refere-se ao fato de que microsserviços executados em contêineres incluem os componentes de tempo de execução necessários para execução – um contraste intencional entre a geração anterior de serviços da Web que eram terminais baseados em XML e software que exigia barramentos de serviços corporativos (ou outra tecnologia como mecanismos de servlet) para fornecer o contexto de execução.

Além disso, dentro do contexto mais amplo da arquitetura nativa da nuvem, os microsserviços exigem considerações adicionais. Eles aumentam e diminuem automaticamente dentro dos pods e, portanto, os desenvolvedores devem projetá-los para serem sem estado. Como resultado, o gerenciamento de estado com microsserviços requer cuidados especiais para obter os benefícios do escalonamento dinâmico.

Para manter a produtividade, os desenvolvedores nativos da nuvem devem trabalhar com a equipe de DevOps para acompanhar todas essas propriedades de microsserviços para cada microsserviço o tempo todo, tendo em mente a funcionalidade de cada microsserviço dentro do contexto mais amplo da arquitetura nativa da nuvem.

Em outras palavras, o desenvolvimento nativo da nuvem é difícil e complicado — desafios que podem facilmente afetar tanto a produtividade do desenvolvedor quanto o DX.

Mantendo DX diante do desenvolvimento desafiador

A boa notícia: os desenvolvedores adoram desafios. A maioria deles escolheu a carreira devido à satisfação inerente em resolver quebra-cabeças difíceis. Não há sensação melhor do que quando um trecho de código particularmente difícil finalmente é executado da maneira que deveria.

Há uma linha tênue, entretanto, entre desafios que são divertidos e gratificantes e problemas tão difíceis que trabalhar neles é como bater a cabeça contra a parede. Para muitos desenvolvedores, o desenvolvimento nativo da nuvem é mais do tipo desafiador.

Tanto a produtividade do desenvolvedor quanto o DX dependem da mudança dessa equação para os tipos de desafios que os desenvolvedores adoram. Os deslocados internos podem ajudar, pois fornecem aos desenvolvedores um conjunto recomendado de ferramentas, mas ter as ferramentas certas é fundamental.

De todas as ferramentas que você pode encontrar em um IDP, as que mais contribuem para a produtividade e o DX são as ferramentas de observabilidade. Problemas difíceis são aceitáveis, desde que os desenvolvedores tenham as informações necessárias para resolvê-los – e ferramentas de observabilidade como o Chronosphere fornecem essas informações.

O Chronosphere não apenas fornece observabilidade especificamente para desenvolvedores, mas também é especializado em observar ambientes nativos da nuvem.

Em particular, o Chronosphere Lens vai além da telemetria bruta, gerando dinamicamente visualizações centradas em serviços que apoiam os desenvolvedores tanto na exploração proativa quanto na solução de problemas reativos do comportamento do sistema.

A visão do Intellyx

Quando a gestão se concentra demais na produtividade do desenvolvedor, a experiência do desenvolvedor pode ser prejudicada e, assim, prejudicar o moral e, paradoxalmente, também a produtividade. É importante que a gestão tenha um toque leve para evitar esse problema, principalmente com o nativo da nuvem.

Os ambientes nativos da nuvem podem se tornar tão dinâmicos e barulhentos que a produtividade e a experiência do desenvolvedor podem diminuir. A gestão deve ter um cuidado especial para apoiar os seus desenvolvedores com as plataformas, ferramentas, processos e métricas de produtividade certas para facilitar os melhores resultados, aproveitando a engenharia da plataforma para criar e gerir IDPs que facilitam o desenvolvimento nativo da nuvem, apesar da sua complexidade inerente.

Afinal, a complexidade do desenvolvimento nativo da nuvem por si só não é o problema. A complexidade apresenta desafios, com certeza, mas os desenvolvedores estão sempre prontos para desafios. A complexidade aliada à falta de visibilidade traz frustração, diminuindo a produtividade e o DX.

Com a observabilidade correta, por exemplo, com o Chronosphere e o Google Cloud, os desenvolvedores têm boas chances de desvendar a complexidade inerente do nativo da nuvem, entregando software de qualidade dentro do prazo e do orçamento, mantendo a produtividade e o DX.

A postagem O Cloud Native altera a produtividade e a experiência do desenvolvedor? apareceu primeiro em The New Stack.