Usando um portal de desenvolvedor interno para Golden Paths

Os desenvolvedores se sentem constrangidos porque desejam avançar rapidamente, lançando o máximo de recursos possível. Mas a equipe da plataforma precisa garantir que tudo o que os desenvolvedores façam siga os padrões de engenharia e não coloque a empresa em risco.

Os líderes de DevOps muitas vezes se preocupam com o fato de os desenvolvedores não entenderem completamente como cumprir esses padrões ou compreender a infraestrutura com a qual estão trabalhando. Para aliviar essas preocupações, eles poderiam exigir que os desenvolvedores solicitassem acesso a serviços ou sistemas por meio de operações de tickets ou simplesmente solicitando diretamente ao DevOps.

É aqui que entram os caminhos dourados. Eles encontram um equilíbrio entre conceder aos desenvolvedores total liberdade e exigir que o DevOps cuide de tudo para evitar possíveis erros dos desenvolvedores.

Chad Metcalf, de Daytona, descreveu um caminho dourado como um “caminho opinativo e apoiado para construir e executar sistemas”. Ele explicou que “fornece ferramentas, processos e documentação recomendados sob medida para desenvolvedores dentro de uma organização”.

Metcalf enfatizou que as estradas pavimentadas impõem menos restrições aos incorporadores. Isso é música para os ouvidos dos desenvolvedores.

Os caminhos dourados também exigem uma mudança de mentalidade, com uma ênfase crescente na experiência do desenvolvedor (DevEx) no espaço de engenharia de plataforma. Os engenheiros de plataforma visam fornecer aos desenvolvedores uma experiência melhor, e os caminhos dourados são vistos como um caminho a seguir. Embora muitas organizações se concentrem na criação do caminho dourado, permanecer nesse caminho é um esforço que deve ser igualmente considerado.

Como funciona?

Os caminhos dourados permitem que os desenvolvedores realizem tarefas de forma independente, ao mesmo tempo que garantem que os engenheiros de plataforma e DevOps incorporem os padrões da organização. Na prática, isso envolve fornecer opções de automação ou autoatendimento, permitindo que os desenvolvedores executem tarefas rapidamente com as proteções corretas instaladas. Essa abordagem geralmente reduz a carga cognitiva dos desenvolvedores, uma vez que eles não precisam escolher uma entre diversas opções para concluir uma ação; eles simplesmente seguem o caminho dourado.

No entanto, mesmo quando os desenvolvedores aderem aos caminhos dourados, é crucial garantir que os padrões sejam mantidos ao longo do tempo e não degradados após a ação inicial de autoatendimento. Um caminho dourado só permanece eficaz se os desenvolvedores continuarem a segui-lo. Os caminhos dourados são um ciclo de vida e não uma tarefa única. Uma maneira de conseguir isso é adotar uma mentalidade de produto, garantindo que tudo seja construído pensando no desenvolvedor.

Como Golden Paths pode ajudar os desenvolvedores

1. Reduzindo a carga cognitiva: O fluxo constante de novas ferramentas e tecnologias de desenvolvimento torna impossível para os desenvolvedores acompanharem. Mesmo desenvolvedores altamente qualificados com experiência em ferramentas como Terraform ou aqueles que entendem de infraestrutura podem ter dificuldades, mesmo que sejam desenvolvedores full-stack. Os caminhos dourados permitem que os desenvolvedores concluam tarefas sem conhecimento profundo de cada ferramenta ou infraestrutura, reduzindo a carga cognitiva e a frustração.
2. Aumentando a velocidade: se os desenvolvedores tiverem que esperar três dias para que um cluster Kubernetes ou um cluster de banco de dados seja provisionado, isso será uma perda de tempo. Se eles próprios conseguirem implantar esses clusters com o clique de um botão e deixá-los prontos em 5 ou 10 minutos, sua velocidade aumentará significativamente.

Um Ciclo de Vida do Caminho Dourado

Existem três etapas principais que você precisa considerar ao construir caminhos dourados:

1. Entrando no caminho: Ações de autoatendimento que atendem aos padrões
2. Verificando se continuaremos nesse caminho: Medindo os recursos existentes com base em nossos padrões
3. Trazendo os recursos “ruins” de volta ao caminho: Lidando com recursos não conformes

Ações de autoatendimento que atendem aos padrões

Um excelente exemplo de caminho de ouro é oferecer aos desenvolvedores automação padronizada para gerenciar aplicativos, recursos de nuvem e outros ativos organizacionais. Por exemplo, ao criar um novo cluster Kubernetes, o processo incluiria padrões predefinidos de segurança e rede, bem como controle de versão, por meio de uma ação de autoatendimento. Isso permite que os desenvolvedores criem rapidamente o cluster, garantindo a conformidade com os padrões estabelecidos.

No caso de criação de um novo cluster AWS RDS, muitas organizações possuem processos automatizados para isso (ou para criação de outros recursos em nuvem). Normalmente, isso envolve conectar-se ao ambiente Terraform via GitHub, atualizar um repositório git e aplicar alterações após uma solicitação pull. O objetivo é agilizar esse processo e, ao mesmo tempo, garantir a adesão aos padrões de segurança, prontidão para produção, disponibilidade e versão desde o primeiro dia.

Mantendo Padrões: Scorecards para Recursos Existentes

A próxima etapa envolve monitorar os padrões dos recursos existentes. Por exemplo, você pode rastrear se alguém com permissões de administrador alterou a versão ou as configurações de segurança? Embora algumas organizações realizem essas revisões manualmente trimestralmente ou mensalmente, uma abordagem mais eficiente é automatizar o processo.

No exemplo de cluster do AWS RDS, você deve ser capaz de identificar clusters que estão chegando ao fim da vida útil ou que não possuem alta disponibilidade a qualquer momento. Por exemplo, um banco de dados com apenas uma réplica em vez de três não está altamente disponível, criando um ponto único de falha na arquitetura. Isto pode ser avaliado através de uma abordagem de “scorecard”, que avalia o nível de conformidade com os padrões.

Lidando com recursos não conformes

Se um recurso for considerado não compatível, como um banco de dados com uma versão incorreta ou cargas de trabalho do Kubernetes com contagens de réplicas insuficientes, é crucial ter um método para os desenvolvedores corrigirem esses problemas e retornarem ao caminho dourado. Isso garante que todos os recursos permaneçam alinhados com os padrões da organização.

Implementando Golden Paths usando um portal de desenvolvedor interno

Vamos explorar como os caminhos dourados são implementados em um portal interno para desenvolvedores, com foco em três pilares principais: o catálogo de software, ações de autoatendimento e scorecards.

Passo 1. Estabelecendo o Catálogo de Software

Os desenvolvedores devem se sentir confortáveis ​​no portal, encontrando e acessando facilmente as informações de que precisam. É aqui que entra o catálogo de software. Ele serve como um inventário de todos os ativos da sua organização, incluindo um catálogo de serviços, recursos de nuvem, quadros Jira e muito mais. Abrange tudo o que é relevante para a rotina dos desenvolvedores, proporcionando uma visão abrangente e fácil acesso aos recursos necessários.

O catálogo de serviços serve como página inicial do desenvolvedor no portal. Aqui, eles podem visualizar todos os seus aplicativos em um só lugar, com detalhes relevantes como o nome do aplicativo, a equipe proprietária, a URL do repositório git e muito mais. Eles também podem acessar informações pertinentes às suas rotinas diárias, como dados da AWS (sejam clusters RDS ou Lambdas executando buckets S3) e atualizações do quadro Jira de sua equipe, todos filtrados de acordo com suas necessidades. O objetivo é visualizar tudo o que é necessário para o seu trabalho diário, com integrações ao vivo de diversas ferramentas.

Os desenvolvedores podem ver clusters diferentes quando clicam na visualização Clusters RDS.

Etapa 2. Crie ações de autoatendimento

Quando um desenvolvedor está trabalhando em um novo microsserviço, provavelmente precisará de um banco de dados. O ideal é que eles possam utilizar ações de autoatendimento no portal, onde um formulário permite criar o que precisam. Esse recurso de autoatendimento é definido e fornecido pela equipe da plataforma.

Por exemplo, clicando no botão superior direito denominado “+ Cluster RDS”, o desenvolvedor pode criar um novo cluster RDS.

O design deste formulário de autoatendimento usa abstração. O desenvolvedor fornece informações simples e relevantes para a criação do novo cluster RDS sem precisar de conhecimento específico sobre o recurso AWS ou a infraestrutura. Os engenheiros da plataforma pré-configuraram esses formulários com parâmetros dinâmicos. Ao utilizar o formulário de autoatendimento, o desenvolvedor segue um caminho de ouro traçado pelos engenheiros da plataforma e equipes de DevOps.

O desenvolvedor poderá então ver os logs que refletem a ação: Um novo cluster RDS está sendo criado e posteriormente criado com sucesso. Este processo é habilitado conectando o portal a uma ação GitHub que atualiza o arquivo Terraform e provisiona o cluster para o desenvolvedor. Este método atende aos padrões da equipe da plataforma e é eficiente, demorando apenas um minuto. O desenvolvedor não precisa de acesso direto ao console AWS, embora possa acessar o console se desejar. Em vez disso, eles podem encontrar todas as informações necessárias no catálogo. Eles podem clicar no recurso recém-criado:

Aqui, o desenvolvedor encontra todos os detalhes relevantes, como o Amazon Resource Name (ARN), o mecanismo e um link para seu recurso AWS. O novo recurso principal adicionado ao catálogo do software mostra o link, a versão e informações abrangentes sobre ele, tornando o portal uma fonte única de verdade para o ambiente.

Etapa 3. Cartões de pontuação

A próxima etapa é mostrar como os desenvolvedores podem medir continuamente seus recursos por meio de scorecards.

Isso envolve a criação de regras para avaliar a qualidade dos ativos no seu catálogo de software. O portal permite definir padrões organizacionais e como cada recurso deve ser medido. Isso é realizado por meio de um scorecard — uma métrica criada com base nos dados do portal para responder a perguntas como: “Meu banco de dados está chegando ao fim da vida útil?” ou “Meu banco de dados tem alta disponibilidade?”

Ao clicar na guia scorecards dentro do novo recurso, os desenvolvedores veem uma tela dedicada a eles. Por exemplo, pode haver dois escopos para medir: prontidão para produção e versão.

Existem três níveis: bronze, prata e ouro. Neste exemplo, “ouro” representa um banco de dados perfeito, enquanto um banco de dados que não atende aos requisitos é rotulado como “básico”.

O scorecard mede vários aspectos para garantir que o novo cluster esteja atualizado e que a ação de autoatendimento em vigor também esteja atualizada.

Para garantir a prontidão da produção, o scorecard verifica se o banco de dados é executado em diversas zonas de disponibilidade, tem proteção contra exclusão configurada e tem backups e insights de desempenho configurados pela AWS. Todos os KPIs e padrões para scorecards são totalmente personalizáveis.

Etapa 4. Ações de autoatendimento do dia 2

Medir seus recursos é um ótimo começo, mas ser capaz de atualizar e corrigir proativamente seus recursos quando eles não estão no caminho certo é igualmente importante. Se você não puder garantir que seus recursos retornem ao caminho dourado, as medições serão inúteis. Assim, as ações de autoatendimento do segundo dia permitem realinhar os recursos que não atendem mais aos seus padrões. Por exemplo, utilizando o scorecard “versão”, é possível perceber que alguns clusters RDS estão desatualizados. Portanto, para cada cluster RDS no catálogo de software, você pode fornecer uma ação do Dia 2 para atualizar o cluster desatualizado. Um desenvolvedor pode visualizar todos os recursos de sua propriedade que não atendem aos padrões a qualquer momento na página inicial do portal. Eles podem então clicar em um link diretamente da página inicial que lhes permite atualizar esses recursos usando a ação de autoatendimento.

Ciclo de Vida do Caminho Dourado

Neste exemplo, o caminho dourado não envolve apenas a criação de um novo recurso; inclui as questões básicas pré-configuradas pelos engenheiros da plataforma, garantindo que os padrões sejam integrados, os processos sejam contínuos e a comunicação entre engenheiros e desenvolvedores permaneça positiva. Além disso, o uso do portal ajuda as organizações a estabelecer e manter o caminho dourado, garantindo que os desenvolvedores permaneçam no ciclo de vida do caminho dourado em cada etapa. Esta continuidade é crucial para o sucesso.

Assista ao webinar sobre caminhos de ouro aqui.

Saiba mais sobre portais internos para desenvolvedores, engenharia de plataforma e DevEx no evento virtual Portal Talks em junho. 26 a 27 de 2024. Jennifer Riggins do New Stack será a apresentadora.

A postagem Usando um portal de desenvolvedor interno para Golden Paths apareceu pela primeira vez em The New Stack.