GitOps é excelente para DevEx, mas o pragmatismo é importante

A KubeCon em Paris foi uma oportunidade incrível para pessoas com ideias semelhantes se reunirem para falar sobre Kubernetes, GitOps e computação nativa em nuvem. Aproveitamos a oportunidade para entrevistar desenvolvedores especializados sobre suas iniciativas de modernização, incluindo o que funciona bem e onde há problemas.

A experiência do desenvolvedor (DevEx) é o principal impulsionador das iniciativas de modernização. Mais de dois terços das organizações estão migrando para a nuvem nativa, Kubernetes e GitOps para melhorar o DevEx. Apesar dessas boas intenções, existem dois riscos comuns de tropeços que devem ser abordados:

• Os desenvolvedores querem GitOps pragmáticos, não GitOps puro.
• Os desenvolvedores precisam de melhores ferramentas de CD, não apenas de uma ferramenta que execute scripts personalizados.

Os desenvolvedores querem GitOps pragmáticos

GitOps e Kubernetes são companheiros naturais. Comparado às máquinas virtuais, o Kubernetes tem superpoderes em orquestração de contêineres e escalonamento dinâmico. A capacidade de automatizar o Kubernetes também é uma grande vantagem, e o GitOps é a maneira natural de fazer isso.

O pragmático GitOps não chega a dizer que tudo deve acontecer no controle de versão. Por exemplo, uma ferramenta de CD dedicada cuidará do arquivo de manifesto do Kubernetes e do processo de implantação. Ele aplicará a configuração correta para cada ambiente e garantirá o progresso das versões de software em cada ambiente.

O problema com a abordagem puramente GitOps é que você acaba com arquivos YAML em todos os lugares. Não apenas dois ou três arquivos, mas milhares. São necessários apenas alguns serviços e ambientes para gerar a expansão YAML, conforme ilustrado abaixo. Se você aplicar configurações diferentes por cliente ou local, o problema será ainda pior.

Conversamos com especialistas em Kubernetes na KubeCon Paris. Encontramos o dobro de pessoas que defendem GitOps pragmáticos em vez de uma abordagem pura. (O GitOps pragmático foi preferido por 67% dos especialistas contra 33% que optaram pelo GitOps puro.) À medida que as equipes de DevOps aplicam o GitOps em escala, a necessidade de ferramentas especializadas para lidar com coisas como configuração se torna mais aparente.

Os martelos são ótimos no que fazem, mas não fazem tudo. Depois de experimentar a expansão do YAML, você verificará sua caixa de ferramentas para ver o que mais tem disponível para o trabalho.

Os desenvolvedores querem melhor entrega contínua

Sabemos que DevEx é o número 1. 1 impulsionador para iniciativas de modernização, mas os desenvolvedores querem melhores ferramentas de entrega contínua.

O problema atual decorre do fato de que muitas equipes estão usando suas ferramentas de CI para executar tarefas de CD (mas CI não é CD). Isso significa que eles estão escrevendo scripts que armazenam em strings dentro de arquivos YAML. As ferramentas de CI não oferecem recursos para progressão de ambiente, observabilidade de implantação e gerenciamento de configuração para ambientes e locatários.

Embora esses scripts manuais sejam executados dentro de uma ferramenta de CI, eles são, na verdade, mais como uma solução de implantação com script desenvolvida internamente.

Você provavelmente já encontrou um projeto de TI paralelo em algum momento de sua carreira, onde um usuário corporativo criou um aplicativo crítico dentro de uma planilha do Excel. Estes tornam-se inevitavelmente projetos de resgate urgentes quando o seu criador segue em frente ou fica sobrecarregado com o que criou. Criar uma solução de CD dentro de uma ferramenta de CI é basicamente um shadow CD do tipo “faça você mesmo”.

Quase dois terços dos desenvolvedores estão usando uma ferramenta de CI ou solução completa para seu pipeline de CD, e isso está levando a uma explosão de scripts autogerenciados como base para implantações. Esta é uma das razões pelas quais o DevEx é um problema a ser resolvido. Mais de 80% dos desenvolvedores entrevistados nos disseram que o CD é o investimento mais impactante que pode ser feito para DevEx.

À medida que as organizações investem na melhoria do DevEx e do desempenho da entrega de software, uma consideração adequada do CD será crucial.

Atualizar boas práticas para o sucesso

Há muito se afirma que o desenvolvimento de software moderno está repleto de sobrecarga cognitiva. Quando você adota o Kubernetes pela primeira vez, o ecossistema de escolhas causa sobrecarga de decisões. Porém, quando você estiver pronto e funcionando, é a expansão do YAML e o CD sombra DIY que estão limitando a entrega do software e causando problemas aos desenvolvedores.

No “Guia do líder para a adoção do Kubernetes”, Nikita Dergilev e Bob Walker explicam que as metas de negócios precisam impulsionar a adoção do Kubernetes para evitar que sejam despriorizadas por iniciativas futuras. Há uma série de decisões a serem tomadas ao longo do caminho que se beneficiarão de um processo colaborativo de padronização. As duas escolhas cruciais que você pode fazer são em relação ao DIY shadow CD e à expansão YAML.

Saímos da infraestrutura tradicional porque as soluções modernas nativas da nuvem oferecem muitos benefícios. Mas, sem querer, perdemos a sutileza na forma como gerenciamos versões de software. Atualizar as nossas boas práticas para suportar software moderno é fundamental se quisermos resolver os problemas de carga cognitiva.

A postagem GitOps é excelente para DevEx, mas o pragmatismo é importante apareceu pela primeira vez em The New Stack.