Melhorar a deteção e eliminar o desperdício através de inventários e controlo de relações
À medida que a sua organização cresce, o mesmo acontece com a quantidade de itens que precisa de controlar. Poderá ter de controlar código, APIs, contentores, máquinas virtuais (VMs), tópicos de mensagens, associação à equipa, propriedade do projeto e muito mais. À medida que dimensiona, não é incomum encontrar esforços duplicados muitas vezes porque uma equipa não sabe sobre a outra. À medida que as pessoas se deslocam entre equipas, novas pessoas entram na empresa e outras saem, os projetos podem ficar órfãos. Se não for gerido, isto pode levar à expansão técnica e ao desperdício simplesmente porque não pode descobrir facilmente o que já existe. Este é um desafio comum. Por exemplo, considere esta citação:
Temos uma tonelada de contentores ou instâncias [VM] em execução. Podemos eliminar as nossas VMs antigas? Ninguém sabe. Temos de arranjar uma forma de limpar coisas antigas e utilizar etiquetas adequadas para sabermos quem é o proprietário ou equipa que nos pode informar sobre o que podemos fazer e qual é o ciclo de vida...... Não sabemos se podemos encerrar uma VM específica porque não temos a certeza do que vai acontecer. - Martin, Engenheiro de DevOps, Grande Empresa de Logística
Melhorar o controlo, a segurança e a reutilização através de inventários personalizados
Parte do que precisa é de um inventário que fornece ajuda para controlar todos os "conteúdos" que criou ou criou no seu ecossistema que os clientes internos podem visualizar de forma compreensível.
Um inventário pode melhorar a segurança, promover a reutilização e, geralmente, facilitar a deteção. Por exemplo, os Ambientes de Implementação do Azure descrevem e controlam infraestruturas complexas criadas através da infraestrutura como código (IaC) como um ambiente abstrato que está a um nível que tanto o desenvolvimento como as operações podem compreender. Da mesma forma, o Centro de API do Azure fornece uma forma de os programadores descobrirem e consumirem APIs. Os registos de pacotes como Os Pacotes do GitHub ou os Artefactos do Azure (ou outros inventários de pacotes aprovados e SDKs) melhoram a segurança da cadeia de fornecimento. Cada uma destas ferramentas fornece um inventário para o ajudar a gerir, controlar e limpar resíduos.
Ao avaliar a forma como irá criar ou aplicar estes inventários, uma decisão importante é determinar o quão amplamente visíveis devem ser os respetivos conteúdos. Tenha em atenção que não existe uma resposta certa ou errada aqui. Algumas empresas tomam uma abordagem de cozinha aberta onde "todos podem ver a comida a ser preparada, mas apenas algumas pessoas podem cozinhá-la". Com uma cozinha aberta, os programadores têm visibilidade total para os recursos de software, mas só podem modificar os recursos pelos quais são responsáveis. Por outro lado, as empresas regulamentadas podem ter regras mais rigorosas, em que até a visibilidade dos nomes dos projetos é considerada confidencial.
Melhorar a deteção e o controlo através de relações
Ter um ou mais sistemas de inventário que o ajudam a controlar o que tem é fundamental para as práticas de engenharia de plataformas 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, também pode melhorar a deteção ao adicionar 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 equipas procurem e descubram rapidamente todos os recursos disponíveis. Isto promove a reutilização, reduz a redundância e estabelece uma abordagem consistente à governação.
Considere a relação entre uma definição de API e o código de aplicação implementado que implementa a interface. Este código é armazenado num repositório e gerido por uma equipa e fornece documentação sobre a sua utilização. São criados ambientes de sandbox temporários, dev, test, prod e até temporários. Em cenários nativos da cloud, os ambientes podem ser implementados num cluster partilhado do Kubernetes. A equipa de desenvolvimento que cria a API e todos os consumidores internos da mesma precisam de ser capazes de obter informações sobre cada uma destas coisas, mas a forma como os recursos se relacionam não é óbvia.
Para começar, pode utilizar algo tão simples como uma página wiki para ajudar a controlar a forma como cada coisa se relaciona entre si. Mas a documentação envelhece rapidamente e pode ser difícil de localizar e analisar. Idealmente, teria um sistema com um gráfico de relações que pode ligar as interfaces de utilizador para percorrer estas relações no seu inventário. Para melhorar verdadeiramente a deteção, terá de conseguir associar itens armazenados em vários tipos de inventários ou gráficos em conjunto. Poderá não precisar de consumir inventários diretamente, mas é provável que queira associá-lo a informações num sistema de catálogo de API.
Para utilizar a analogia do arquivo digital, também pode ser útil associar os itens (modelos) no seu catálogo aos conteúdos de inventário resultantes. Por exemplo, se perceber que um dos seus modelos cria uma configuração insegura, terá de encontrar rapidamente todos os recursos que foram criados para os corrigir. Até os modelos de aplicação de início corretos são essencialmente pacotes de kits de arranque neste catálogo que se ligam a outros tipos de itens de catálogo (como modelos IaC). Controlar estas associações permitir-lhe-ia encontrar proativamente qualquer aplicação que faça referência a um modelo IaC incorreto, mesmo que ainda não tenha sido aprovisionada nenhuma infraestrutura.
Uma variação simplificada deste gráfico conceptual de plataforma de programador de alto nível pode ser encontrada em alguns toolkits e produtos atualmente, embora o que é chamado varie. Por exemplo, o toolkit do portal open source Backstage.io chama a isto um catálogo de software, enquanto outros produtos utilizam termos diferentes. No entanto, a maioria destes produtos e toolkits parte do princípio de que está a utilizar o conjunto de funcionalidades mais amplo e exige que os conteúdos dos seus inventários sejam duplicados dentro dos mesmos. Esta duplicação significa que o conteúdo da base de dados do catálogo não é específico do utilizador, pode ficar obsoleto e não é controlado pelos mecanismos de autorização de utilizador do sistema de origem. No entanto, isto pode funcionar muito bem para a sua organização se estiver a seguir uma abordagem de cozinha aberta.