Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
O autosserviço com restrições é o princípio de capacitar as equipes de desenvolvimento a tomarem suas próprias decisões dentro de um conjunto de parâmetros bem definidos, ou restrições. Os guarda-corpos são estabelecidos e acordados pelas principais partes interessadas. As partes interessadas podem incluir equipes de segurança, operações e arquitetura em toda a organização.
Ao usar o autosserviço com guarda-corpos, as equipes de desenvolvimento mantêm autonomia para tomar decisões de desenvolvimento de forma independente. A automação e a política ajudam as partes interessadas a garantir que a segurança, a conformidade, as operações, os padrões e os custos sejam gerenciados corretamente. Habilitar essa automação requer colaboração entre as linhas da equipe para que desenvolvedores, operadores e especialistas possam fazer mais, sem sacrificar a governança necessária. Os desenvolvedores podem então se concentrar em fornecer valor comercial o mais rápido possível.
[Nós dizemos aos desenvolvedores,] não se preocupem nada sobre como tudo funciona, apenas ativem ou desativem, preencham, insiram uma string conforme necessário e é basicamente autosserviço nesse sentido, onde existe um manual e há entradas, saídas e podem colocar o que quiserem. - Daniel, engenheiro de nuvem, empresa de mídia Fortune 500
O objetivo de fornecer uma experiência de autosserviço para seus caminhos pavimentados é reduzir a labuta do desenvolvedor e, ao mesmo tempo, fornecer visibilidade para as equipes de desenvolvimento, operações e gerenciamento. A ideia é que você crie uma experiência para uma determinada tarefa que tenha uma curva de aprendizado mínima, graças, em parte, às suas capacidades subjacentes de automação e agregação de dados. Além de atividades como provisionamento de infraestrutura, essas experiências podem fornecer acesso a recursos críticos para observabilidade, política, gerenciamento de incidentes e muito mais. A ideia se estende à descoberta e compartilhamento de APIs internas, SDKs, juntamente com ferramentas e serviços compartilhados. Essas experiências reduzem as despesas gerais para que as equipes de desenvolvimento possam se concentrar em fazer as coisas.
As plataformas internas de desenvolvedores capacitam os desenvolvedores a agir como clientes de vitrines digitais
As plataformas internas de desenvolvedores fornecem recursos semelhantes às vitrines digitais entre empresas. As lojas digitais são inerentemente projetadas para ajudar seus clientes a se autosservirem. Eles podem lidar com mais rendimento do que as vitrines tradicionais porque fornecem maneiras de descobrir e preencher itens que são interessantes sem ter que falar com ninguém. Usando essa analogia, os desenvolvedores são o cliente e a plataforma interna do desenvolvedor fornece experiências de autoatendimento semelhantes. Operadores, engenheiros de plataforma e outras funções configuram um catálogo de itens que os desenvolvedores podem solicitar e que são projetados para acomodar guarda-corpos organizacionais.
Por exemplo, pode-se considerar um programador a solicitar acesso a uma nova ferramenta como se estivesse a fazer um pedido numa loja digital. Como um pedido, uma vez que a solicitação é enviada, o desenvolvedor quer ser capaz de acompanhar o progresso e saber quando ele está concluído. Nos bastidores, a solicitação deve ser encaminhada automaticamente para o provedor de atendimento correto para atender à necessidade. Você pode pensar em um de seus sistemas de integração e entrega contínua (CI/CD) como um provedor de atendimento, uma ferramenta GitOps ou uma plataforma de aplicativo prescritiva como um segundo e uma ferramenta de automação de fluxo de trabalho para processos manuais como um terceiro. Em todos os casos, o desenvolvedor pode auto-servir itens de um catálogo bem definido da mesma maneira.
Use o padrão tudo como código
Usar a infraestrutura como código (IaC) por meio de pipelines de entrega contínua (CD) e ferramentas GitOps é uma parte importante da facilitação do autosserviço. O IaC com CD permite que você use gráficos Bicep, Terraform, Helm e outras ferramentas para criar e destruir recursos de nuvem sob demanda. Como a configuração de sua infraestrutura de nuvem é gerenciada como o código em um repositório de código-fonte, você pode aplicar todos os benefícios de um repositório git, como segurança e auditabilidade.
O provisionamento de infraestrutura e ferramentas comuns não é a única vantagem de uma abordagem IAC. Você pode adaptar o padrão IaC para outros cenários, incluindo segurança como código e política como código (por meio de ferramentas como Azure Policy e Open Policy Agent). Seguindo essa técnica, um arquivo de configuração, normalmente YAML ou JSON, é enviado por push para o repositório, o que aciona um fluxo de trabalho que processa o arquivo. Esses arquivos podem ser um repositório de aplicativos como dependabot.yml ou CODEOWNERS, ou podem ser mantidos em um repositório central separado. Você pode até mesmo estender isso para seus próprios cenários para realmente tornar tudo em forma de código (EaC) uma realidade.
Os desenvolvedores podem fazer referência a cada um desses modelos EaC com um catálogo central que potencializa suas experiências de autoatendimento e incentiva as práticas recomendadas por padrão.
Crie modelos corretos para o início e estabeleça a governança de continuidade correta
No desenvolvimento de software, visamos o encapsulamento, modularidade e capacidade de composição ao projetar aplicações. Você deve aplicar essa mesma linha de pensamento à engenharia de plataformas por meio de modelagem. Por exemplo, você pode criar e usar um conjunto de modelos IaC reutilizáveis e protegidos centralmente como blocos de construção para infraestrutura.
Vamos construir módulos para os nossos [desenvolvedores]... Então, em vez de ter que escrever ou se preocupar com qualquer um dos back-ends, tudo o que eles precisam fazer é se preocupar com o código do aplicativo. - Daniel, engenheiro de nuvem, empresa de mídia Fortune 500
Combine IaC, EaC e modelos de aplicações numa solução personalizada de tudo como código (EaC) que se estende a outras atividades, como criar um repositório de código-fonte, semear código de exemplo ou fornecer configuração e código de exemplo para ferramentas de observabilidade recomendadas. Esses modelos de IaC, EaC e aplicativo podem ser armazenados ou referenciados a partir de um local central e seguro, como um repositório, o catálogo nos Ambientes de Implantação do Azure ou o Registro de Contêiner do Azure para nativo da nuvem.
Quando os modelos de início certo são combinados com governança, verificação e configuração de políticas automatizadas, os desenvolvedores permanecem desde o primeiro dia.
Os modelos agilizam o desenvolvimento com práticas automatizadas e seguras
Use modelos de aplicativo para inicializar seus caminhos pavimentados definidos para várias decisões e ações importantes que os desenvolvedores tomam ao longo de um projeto. Os modelos certos estabelecem práticas de desenvolvimento seguras e controladas e permitem que os desenvolvedores comecem rapidamente, ao habilitar a automação que dá acesso às ferramentas de que necessitam, configura pipelines de CI/CD, provisiona a infraestrutura e a pilha de aplicativos, e configura um repositório completo com código-fonte padrão que inclui SDKs necessários ou referências a APIs.
Ao fazer com que esses modelos de aplicativo façam referência a outros modelos centralizados (por exemplo, modelos IaC), cada um desses blocos de construção individuais se torna um modelo inicial correto. Esses modelos são fundamentais para permitir experiências de autoatendimento, pois não apenas definem saídas, mas também opções disponíveis que os desenvolvedores escolhem.
Os modelos garantem governança, segurança e otimização de custos
No entanto, os modelos devem fazer mais do que apenas inicializar um esforço de desenvolvimento. Devem também estabelecer o controlo e a governação através da análise das políticas e da segurança necessários para se manterem ao longo do ciclo de vida do projeto. Como outro exemplo, os modelos podem configurar regras de proteção de ramificação que impeçam fusões não autorizadas na produção. Como os modelos capturam práticas recomendadas e configurações comuns, eles são uma das principais técnicas para otimizar custos entre ferramentas, fornecedores e equipes.
Execute campanhas adequadas para estabelecer uma comunicação bidirecional
Finalmente, à medida que sua confiança em seus caminhos pavimentados aumenta, você pode usar os blocos de construção individuais subjacentes montados em seus modelos de aplicativo para mover aplicativos existentes para um caminho pavimentado. Como seus clientes internos já verão o valor de seus caminhos pavimentados pilotados, você pode executar uma campanha interna para criar um diálogo bidirecional com outras equipes de aplicativos. Os desenvolvedores podem aprender como migrar seus aplicativos enquanto a equipe de engenharia da plataforma aprende simultaneamente mais sobre como melhorar a plataforma para eles.
Mapeie a sua própria viagem
Dada a amplitude de experiências que seus recursos de autoatendimento podem cobrir, é um foco importante para seus esforços de investimento e Planeje e priorize para que sua plataforma de desenvolvedor interno entregue valor incrementalmente. A jornada de cada organização na criação de sua plataforma interna de desenvolvedores é diferente, e seguir uma mentalidade de produto ajuda você a segmentar os lugares mais críticos que precisam de experiências de autoatendimento primeiro.