Atulpriya Sharma, como CNCF Ambassador e organizador do Platform Engineering TCG, considera que a pergunta mais importante na engenharia de plataformas não é se a organização construiu uma plataforma, mas como os desenvolvedores realmente interagem com suas capacidades. Organizações que ainda não têm uma plataforma oficial geralmente dependem de scripts dispersos e conhecimento individual, enquanto outras podem ter um portal de desenvolvedores, uma interface CLI e caminhos prontos, mas ainda processam solicitações manualmente. Em ambos os casos, o problema está na maturidade da interface por meio da qual as equipes consomem as capacidades da plataforma.
O material baseia-se no Modelo de maturidade da engenharia de plataformas da CNCF, que mede cinco aspectos de forma independente: investimento, adoção, interfaces, operações e medição. Cada aspecto tem quatro níveis: ad hoc, operacional, escalável e otimizado. Segundo o modelo, a organização não avança como uma unidade única; ela pode progredir em um aspecto enquanto permanece atrasada em outro. A análise concentra-se no aspecto das interfaces, isto é, nos templates, nas interfaces CLI, nos portais e nas APIs que os desenvolvedores utilizam.
Quatro fases da interface da plataforma
No primeiro nível, a organização depende de procedimentos personalizados: solicitações manuais, processos que variam entre as equipes e conhecimento transmitido de uma pessoa para outra. A ausência de um nome oficial para a plataforma não significa que ela não exista na prática; mensagens recorrentes para um determinado engenheiro configurar um banco de dados representam a interface atual da plataforma, ainda que não seja gerenciada.
O segundo nível é chamado de ferramentas padronizadas. Aqui surgem os caminhos dourados ou caminhos pavimentados, além de documentação, templates e interfaces consistentes para fornecer e monitorar capacidades. Os resultados geralmente parecem positivos: maior adoção, integração mais rápida de novos funcionários e melhoria nos indicadores. No entanto, as solicitações que ficam fora do caminho esperado continuam exigindo a intervenção da equipe da plataforma, de modo que a interface é padronizada sem ser autossuficiente.
No terceiro nível surgem as soluções de autosserviço, nas quais o desenvolvedor consegue executar a maioria das solicitações rotineiras sem passar pela equipe da plataforma. Esse nível mede mais o comportamento das equipes do que a dependência exclusiva de indicadores: os tickets de provisionamento rotineiro diminuem, novos engenheiros começam a utilizar a plataforma diretamente e o trabalho da equipe da plataforma passa da execução de solicitações individuais para a melhoria da estrutura que as gerencia. Segundo exemplos apresentados pelo autor, organizações relataram uma redução de 40% a 60% nas solicitações de exceção após a adição de opções de configuração para o autosserviço.
No quarto nível, os serviços integrados tornam as capacidades da plataforma uma parte transparente das ferramentas de trabalho diárias. Ao criar um novo serviço, o monitoramento, o registro e a segurança podem ser integrados automaticamente, enquanto as políticas de segurança impõem suas regras por meio da plataforma, em vez de exigir que o desenvolvedor negocie manualmente com elas. A plataforma se torna quase invisível, e seu sucesso é medido pelo quanto é raro os desenvolvedores precisarem pensar na infraestrutura.
Por que as organizações param no segundo nível?
A análise identifica quatro problemas recorrentes. O primeiro é o problema das filas: os caminhos dourados cobrem os casos comuns, mas os casos excepcionais podem representar 30% do trabalho em organizações grandes. O autor apresenta o exemplo de uma organização varejista que utilizou um caminho dourado para implantar Kubernetes por meio de Helm charts e ArgoCD. A adoção chegou a 85% em seis meses, mas 40 casos de exceção se acumularam, e a equipe passou a gastar 60% do seu tempo com configurações fora do caminho.
O segundo é a lacuna de experiência; as equipes de plataforma podem criar capacidades gerais que não atendem perfeitamente às necessidades das equipes especializadas, levando essas equipes a desenvolver alternativas próprias. O terceiro é a armadilha da manutenção: cada nova capacidade representa uma superfície adicional para atualização, teste e correção quando surge uma vulnerabilidade ou quando o Kubernetes é atualizado. O autor menciona um caso em que interfaces antigas de Helm charts, dependências de um provedor de nuvem e premissas de rede se acumularam, até que sua atualização se tornou arriscada.
O quarto problema é a rigidez. O caminho dourado reflete premissas corretas no momento de sua criação, mas elas podem se transformar em restrições à medida que as tecnologias, os processos e as necessidades das equipes mudam. Nesse momento, proliferam as exceções e a infraestrutura paralela, e a equipe da plataforma se transforma em uma fábrica de soluções individuais, em vez de melhorar a interface principal.
O que muda na prática?
Para passar do primeiro ao segundo nível, o autor sugere nomear o que já existe antes de construir um novo portal: identificar as solicitações mais frequentes, as que mais consomem tempo e as mais fáceis de padronizar; depois, escolher um único caminho dourado e realmente aprimorá-lo antes de ampliar o catálogo.
Do segundo para o terceiro nível, é preciso deixar de fazer da equipe da plataforma um elo humano obrigatório. Isso exige tornar os caminhos dourados configuráveis, com opções validadas e restrições impostas por políticas, em vez de valores fixos, além de oferecer saídas para casos legítimos. A análise também recomenda medir as solicitações antes de automatizá-las; em um exemplo do setor de mídia, o registro das solicitações durante três meses revelou que 20% dos tipos de solicitação representavam 80% do volume. O autosserviço foi criado primeiro para esses padrões, e o acúmulo caiu 60% em seis meses.
Também é necessário tratar a interface como um produto, e não apenas as capacidades de back-end. Capacidade de descoberta, regras de validação, contratos e a forma de lidar com solicitações inesperadas fazem parte do produto. Ao se aproximar do quarto nível, a automação passa de uma operação escolhida pelo desenvolvedor para premissas inteligentes impostas pelas políticas dentro do Git, do ambiente de desenvolvimento e dos sistemas de CI/CD, com a distribuição da propriedade das capacidades entre as equipes de segurança, bancos de dados e monitoramento, dentro de contratos claros.
Leitura da certi.news
A mudança efetiva destacada pelo artigo é a transição do critério de sucesso da plataforma de desenvolvedores: do número de ferramentas e caminhos lançados para o grau de autonomia obtido pelos usuários e, depois, para o nível de integração dessas capacidades ao fluxo de trabalho. Isso é importante para as equipes de plataforma porque elas podem elevar a adoção aparente enquanto transferem o peso da execução para uma fila de exceções e manutenção.
No entanto, os exemplos e números apresentados aqui são descritos pelo autor como observações de interações com organizações, e não como um estudo quantitativo independente que prove que os mesmos percentuais se aplicam a todas as organizações. Além disso, chegar ao quarto nível pressupõe maturidade em contratos, políticas e distribuição de responsabilidades, aspectos que a compra de um portal ou a adição de um agente de inteligência artificial, por si só, não oferece. A conclusão apresenta uma questão aberta importante: a interface de autosserviço projetada para desenvolvedores não é necessariamente uma interface consumível por agentes de inteligência artificial, que interagem com APIs em frequências e padrões diferentes dos fluxos de trabalho humanos. Portanto, a maturidade das interfaces legíveis por máquinas pode ser a próxima etapa que as equipes de plataforma precisarão medir.