Melhorar a descoberta e eliminar o desperdício por meio de inventários e acompanhamento de relacionamentos

À medida que sua organização cresce, a quantidade de coisas que você precisa acompanhar também. Talvez seja necessário acompanhar código, APIs, contêineres, VMs (máquinas virtuais), tópicos de mensagens, associação à equipe, propriedade do projeto e muito mais. Conforme você dimensiona, não é incomum encontrar esforços duplicados com frequência porque uma equipe não sabe sobre a outra. À medida que as pessoas se movem entre equipes, novas pessoas entram na empresa e outras saem, os projetos podem ficar órfãos. Se não for gerenciado, isso pode levar à expansão técnica e ao desperdício simplesmente porque você não pode descobrir facilmente o que já existe. Esse é um desafio comum. Por exemplo, considere esta cotação:

Temos uma tonelada de contêineres ou instâncias [VM] em execução. Podemos excluir nossas VMs antigas? Ninguém sabe. Precisamos criar uma maneira de limpo coisas antigas e usar marcas adequadas para que saibamos quem é o proprietário ou equipe que pode nos informar sobre o que podemos fazer e qual é o ciclo de vida... Não sabemos se podemos desligar uma VM específica porque não temos certeza do que acontecerá. - Martin, Engenheiro de DevOps, Empresa de Logística Grande

Melhorar o acompanhamento, a segurança e a reutilização por meio de inventários personalizados

Parte do que você precisa é de um inventário que fornece ajuda para acompanhar todas as "coisas" que você criou ou criou em seu ecossistema que os clientes internos podem visualizar de maneira compreensível.

Um inventário pode melhorar a segurança, promover a reutilização e, geralmente, facilitar a descoberta. Por exemplo, os Ambientes de Implantação do Azure descrevem e acompanham a infraestrutura complexa criada por meio da IaC (infraestrutura como código) como um ambiente abstrato que está em um nível que tanto o desenvolvimento quanto as operações podem entender. Da mesma forma, o Centro de API do Azure fornece uma maneira para os desenvolvedores descobrirem e consumirem APIs. Os registros de pacotes, como Pacotes do GitHub ou Azure Artifacts (ou outros inventários de pacotes aprovados e SDKs), melhoram a segurança da cadeia de fornecedores. Cada uma dessas ferramentas fornece um inventário para ajudá-lo a gerenciar, acompanhar e limpo o desperdício.

Ao avaliar como você criará ou aplicará esses inventários, uma decisão importante é determinar o quão amplamente visível deve ser seu conteúdo. Tenha em mente que não há resposta certa ou errada aqui. Algumas empresas adotam uma abordagem de cozinha aberta onde "todos podem ver a comida sendo preparada, mas apenas algumas pessoas podem cozinhá-la". Com uma cozinha aberta, os desenvolvedores têm visibilidade total dos ativos de software, mas só podem modificar os ativos pelos quais são responsáveis. Por outro lado, as empresas regulamentadas podem ter regras mais rígidas, em que até mesmo a visibilidade dos nomes dos projetos é considerada confidencial.

Melhorar a descoberta e o acompanhamento por meio de relações

Ter um ou mais sistemas de inventário que ajudam você a acompanhar o que você tem é fundamental para as práticas de engenharia de plataforma e evitar a expansão técnica. Inicialmente, ter um conjunto de listas de inventário simples pode ser suficiente. No entanto, embora não seja necessário iniciar, você também pode melhorar a capacidade de descoberta adicionando relações entre diferentes ativos em vários inventários. Independentemente do nível de visibilidade necessário, ter um ponto de agregação centralizado permite que as equipes pesquisem e descubram rapidamente todos os ativos disponíveis para eles. Isso promove a reutilização, reduz a redundância e estabelece uma abordagem consistente para a governança.

Considere a relação entre uma definição de API e o código do aplicativo implantado que implementa a interface. Esse código é armazenado em um repositório e gerenciado por uma equipe e fornece documentação sobre seu uso. Ambientes de área restrita de desenvolvimento, teste, prod e até mesmo temporários são criados. Em cenários nativos de nuvem, os ambientes podem ser implantados em um cluster kubernetes compartilhado. A equipe de desenvolvimento que cria a API e todos os consumidores internos dela precisam ser capazes de obter informações sobre cada uma dessas coisas, mas a forma como os recursos se relacionam não é óbvia.

Para começar, você pode usar algo tão simples quanto uma página wiki para ajudar a acompanhar como cada coisa se relaciona uma com a outra. Mas a documentação envelhece rapidamente e pode ser difícil encontrar e analisar. O ideal é que você tenha um sistema com um grafo de relação que possa alimentar as interfaces do usuário para percorrer essas relações em seu inventário. Para realmente melhorar a capacidade de descoberta, você precisará ser capaz de associar itens armazenados em vários tipos de inventários ou grafos juntos. Talvez você não precise consumir estoques diretamente, mas provavelmente desejará associá-los a informações em um sistema de catálogo de API.

Para usar a analogia do repositório digital, também pode ser útil associar os itens (modelos) em seu catálogo ao conteúdo de inventário resultante. Por exemplo, se você perceber que um de seus modelos cria uma configuração insegura, precisará encontrar rapidamente todos os recursos que foram criados para corrigi-los. Até mesmo iniciar modelos de aplicativo corretos são essencialmente pacotes de kit inicial neste catálogo que se ligam a outros tipos de itens de catálogo (como modelos de IaC). O acompanhamento dessas associações permitiria que você encontrasse proativamente qualquer aplicativo que faça referência a um modelo de IaC inválido, mesmo que nenhuma infraestrutura tenha sido provisionada ainda.

Uma variação simplificada desse grafo conceitual de plataforma de desenvolvedor de alto nível pode ser encontrada em alguns kits de ferramentas e produtos hoje em dia, embora o que ele é chamado varie. Por exemplo, o kit de ferramentas do portal de software livre Backstage.io chama isso de catálogo de software, enquanto outros produtos usam termos diferentes. No entanto, a maioria desses produtos e kits de ferramentas pressupõe que você está usando seu conjunto de recursos mais amplo e exige que o conteúdo de seus inventários seja duplicado dentro deles. Essa duplicação significa que o conteúdo do banco de dados do catálogo não é específico do usuário, pode ficar obsoleto e não é controlado pelos mecanismos de autorização de usuário do sistema de origem real. No entanto, isso pode funcionar muito bem para sua organização se você estiver seguindo uma abordagem de cozinha aberta.

Saiba mais sobre conceitos que podem ajudar.

Iniciar seu percurso de engenharia de plataforma