Capacitar programadores através de self-service com proteções
A gestão personalizada com proteções é o princípio de capacitar as equipas de desenvolvimento para tomarem as suas próprias decisões num conjunto de parâmetros bem definidos, ou proteções, que são estabelecidos e acordados pelos principais intervenientes. Os intervenientes podem incluir equipas de segurança, operações e arquitetura em toda a organização.
A ideia subjacente à gestão personalizada com proteções é que as equipas de desenvolvimento podem manter o nível de autonomia pretendido para tomar decisões de desenvolvimento de forma independente, enquanto a automatização e a política ajudam os intervenientes a garantir que a segurança, a conformidade, as operações, as normas e os custos são corretamente geridos. Ativar esta automatização requer colaboração entre linhas de equipa para que os programadores, operadores e especialistas possam fazer mais, sem sacrificar a governação necessária. Combinado com uma melhor deteção e reutilização dentro de proteções definidas pela organização, os programadores podem concentrar-se na entrega de valor empresarial o mais rapidamente possível.
[Dizemos aos programadores,] não se preocupem com o funcionamento de tudo, basta ativá-los ou desativar, preenchê-lo, colocar uma cadeia no que precisarem de fazer e é basicamente self-service nesse aspecto, onde têm um ficheiro de readme e têm entradas, saídas e podem colocar o que quiserem. - Daniel, Engenheiro da Cloud, Fortune 500 Media Company
O objetivo de proporcionar uma experiência self-service para os seus caminhos abertos é reduzir o trabalho do programador, ao mesmo tempo que fornece visibilidade às equipas de desenvolvimento, operações e gestão. A ideia é criar uma experiência para uma determinada tarefa que tenha uma curva de aprendizagem mínima, graças, em parte, às capacidades de automatização e agregação de dados subjacentes. Além de atividades como o aprovisionamento de infraestruturas, estas experiências podem fornecer acesso a capacidades críticas para a observabilidade, política, gestão de incidentes e muito mais. A ideia estende-se à deteção e partilha de APIs internas, SDKs, juntamente com ferramentas e serviços partilhados. Estas experiências reduzem a sobrecarga para que as equipas de desenvolvimento se concentrem em fazer as coisas.
O tempo necessário para começar a utilizar um projeto ou uma tarefa é outro fator motivador para experiências self-service. Uma analogia frequentemente utilizada para uma plataforma de programador interna é que fornece capacidades semelhantes às lojas digitais empresa-empresa. As lojas digitais são inerentemente concebidas para ajudar os seus clientes a auto-servir. Podem lidar com mais débito do que as frentes de loja tradicionais porque fornecem formas de descobrir e satisfazer itens que são interessantes sem terem de falar com ninguém. Com esta analogia, os programadores são o cliente e a plataforma de programador interna fornece experiências personalizadas semelhantes. Tal como um revendedor, operadores, engenheiros de plataforma e outras funções, configure um catálogo de itens que os programadores podem pedir que foram concebidos para acomodar proteções organizacionais.
Por exemplo, pode pensar num programador que pede acesso a uma nova ferramenta como se estivesse a fazer uma encomenda de loja digital. Tal como uma encomenda, assim que o pedido for submetido, o programador quer ser capaz de acompanhar o progresso e saber quando está concluído. Nos bastidores, o pedido deve ser automaticamente encaminhado para o fornecedor de cumprimento correto para satisfazer a necessidade. Pode considerar um dos seus sistemas de integração e entrega contínua (CI/CD) como um fornecedor de cumprimento, uma ferramenta gitOps ou uma plataforma de aplicações prescritiva como um segundo e uma ferramenta de automatização de fluxo de trabalho para processos manuais como um terceiro. Em todos os casos, o programador pode auto-servir itens de um catálogo bem definido da mesma forma.
Para saber mais sobre como implementar estes conceitos, veja Aplicar sistemas de engenharia de software e Criar uma base self-service para programadores.
Utilizar tudo como padrão de código
Utilizar a infraestrutura como código (IaC) através de pipelines de entrega contínua (CD) e ferramentas do GitOps é uma parte importante da ativação self-service. Estes podem permitir-lhe utilizar gráficos Bicep, Terraform, Helm e outras ferramentas para criar e destruir recursos da cloud a pedido. Uma vez que a configuração da sua infraestrutura de cloud é gerida tal como o código num repositório de código fonte, pode aplicar inerentemente todos os benefícios de um repositório git, como segurança e auditoria.
As equipas de engenharia de plataformas podem tirar partido do IaC ao aprovisionar infraestruturas e ferramentas comuns, mas essa não é a única vantagem de uma abordagem IaC. Pode adaptar o padrão "como código" para outros cenários, incluindo segurança como código e política como código (através de ferramentas como Azure Policy e Agente de Política Aberta). Ao seguir esta técnica, um ficheiro de configuração, normalmente YAML ou JSON, é enviado para o repositório, altura em que é acionado um fluxo de trabalho que processa o ficheiro. Estes ficheiros podem ser um repositório de aplicações, como dependabot.yml ou CODEOWNERS, ou podem ser mantidos num repositório central separado. Pode até expandir isto para os seus próprios cenários para tornar verdadeiramente tudo como código (EaC) uma realidade.
Os programadores podem referenciar cada um destes modelos EaC com um catálogo central que alimenta as suas experiências self-service e incentiva as melhores práticas por predefinição.
Saiba mais sobre tudo como padrão de código.
Criar modelos de início à direita & estabelecer a governação de permanência
Vamos criar módulos para os nossos [programadores]... por isso, em vez de terem de escrever ou preocupar-se com qualquer um dos próprios back-end, tudo o que precisam de fazer é preocuparem-se com o código da aplicação. - Daniel, Engenheiro da Cloud, Fortune 500 Media Company
No desenvolvimento de software, pretendemos encapsular, modularidade e composabilidade ao conceber aplicações. Deve aplicar esta mesma linha de pensamento à engenharia de plataformas através da templating. Por exemplo, pode criar e utilizar um conjunto de modelos IaC reutilizáveis e protegidos centralmente como blocos modulares para a infraestrutura.
Estes podem ser combinados num modelo de aplicação feito à medida que se refere a estes e a outros elementos como blocos modulares de código (EaC) e se expandem a outras atividades, como criar um repositório de código fonte, propagar código de exemplo ou fornecer configuração e código de exemplo para ferramentas de observabilidade recomendadas. Estes modelos IaC, EaC e aplicações podem ser armazenados ou referenciados a partir de uma localização central e protegida, como um repositório, o catálogo em Ambientes de Implementação do Azure (ADE) ou Azure Container Registry (ACR) para nativos da cloud.
Quando os modelos de início correto são combinados com governação automatizada, análise e configuração de políticas, podem ajudar os programadores a manter-se desde o primeiro dia.
Iniciar modelos à direita
Os modelos de aplicação podem ser utilizados para arrancar os caminhos abertos definidos para várias decisões e ações fundamentais que os programadores tomam ao longo de um projeto. Estes modelos de início correto devem estabelecer práticas de desenvolvimento seguras e regidas e permitir que os programadores comecem rapidamente ao ativar a automatização que fornece acesso às ferramentas de que precisam, configura pipelines de CI/CD, aprovisiona a infraestrutura e a pilha de aplicações e configura um repositório completo com código fonte de placa de caldeira que inclui SDKs ou referências necessárias às APIs.
Ao fazer com que estes modelos de aplicação referenciam outros modelos centralizados (por exemplo, modelos IaC), cada um destes blocos modulares individuais pode tornar-se modelos corretos para simplificar a utilização em aplicações existentes. Estes modelos são centrais para permitir experiências self-service, uma vez que não só definem saídas, como também as opções disponíveis que os programadores escolhem.
Manter a governação certa
No entanto, os modelos devem fazer mais do que apenas iniciar um esforço de desenvolvimento. Devem igualmente estabelecer o controlo e a governação através da análise de políticas e segurança necessárias para se manterem ao longo do ciclo de vida do projeto. Como outro exemplo, os modelos podem configurar regras de proteção de ramos que impedem intercalações não autorizadas em produção. Uma vez que os modelos capturam melhores práticas e configurações comuns, são uma das principais técnicas para otimizar os custos entre ferramentas, fornecedores e equipas.
Obter as campanhas certas
Por fim, à medida que a confiança nos seus caminhos pavimentados aumenta, pode utilizar os blocos modulares individuais subjacentes que reuniu nos modelos de aplicação para mover aplicações existentes para um caminho pavimentado. Uma vez que os seus clientes internos já verão o valor dos seus caminhos abertos pilotados, pode executar uma campanha interna get right para criar uma caixa de diálogo bidirecional com outras equipas de aplicações. Os programadores podem aprender a migrar a sua aplicação enquanto a equipa de engenharia da plataforma aprende simultaneamente mais sobre como melhorar a plataforma para eles.
Saiba mais sobre os modelos de início corretos com a governação de manter a direita.
Traçar o seu próprio percurso
Dada a amplitude das experiências que as suas capacidades self-service podem abranger, é um foco importante para os seus esforços de investimento e Planear e priorizar para que a sua plataforma de programador interna atribua valor incrementalmente. O percurso de cada organização na criação da sua plataforma de programador interno será diferente e seguir uma mentalidade de produto irá ajudá-lo a direcionar primeiro os locais mais críticos que precisam de experiências self-service.
Saiba mais sobre o gráfico de um percurso de engenharia de plataformas.