O que vem depois das plataformas internas de desenvolvedores?

As coisas tendem a se mover em ciclos. Estamos sempre oscilando entre um extremo e outro, reagindo – e nos diferenciando – do que veio antes. Isto é verdade num sentido histórico amplo e para o desenvolvimento.

Você poderia reescrever a história das ferramentas de desenvolvimento em ciclos de centralização e descentralização – a batalha constante para equilibrar padronização e autonomia, escalabilidade e velocidade. Justamente quando parece que chegamos a uma solução, o pêndulo oscila para o outro lado.

A ascensão das equipes de plataforma tem sido bem documentada e o gerenciamento de plataformas internas de desenvolvedores é cada vez mais uma função central. Mas à medida que a complexidade destes sistemas aumenta e o imposto de construção e manutenção prejudica os benefícios de vendê-los, alguém sente que o pêndulo está prestes a cair?

A ascensão da plataforma interna para desenvolvedores

Antes dos contêineres, existia o VMware, e estávamos obcecados em criar plataformas de autoprovisionamento para desenvolvedores, para que pudessem interagir com a infraestrutura de maneira mínima. Poderíamos simplesmente solicitar a VM necessária e começar a desenvolvê-la imediatamente.

Quando a Infraestrutura como Código surgiu, dividimos essas VMs e migramos para microsserviços. Em vez de ter esta plataforma monolítica, decidimos que uma plataforma descentralizada que separasse as preocupações nos permitiria escalar melhor. Cada equipe poderia trabalhar em sua própria cidade-estado. E quando as coisas não funcionavam, a cultura do DevOps ajudava as equipes a se comunicarem entre si.

Mas isso também começou a parecer fora de controle. Os contêineres ficavam cada vez menores e a complexidade era cada vez maior. E agora, devido à natureza humana, estamos fazendo o que sempre fazemos: algo radicalmente diferente. Cada vez que atingimos algum ponto crítico de complexidade, mudamos de marcha novamente. A descentralização não está a funcionar como esperávamos; precisamos de um padrão mais centralizado.

As plataformas internas de desenvolvimento marcam um retorno a esta visão centralizada do desenvolvimento. Estamos construindo plataformas de autoprovisionamento na esperança de que os desenvolvedores não precisem conversar com as operações.

Mas estamos enfrentando as mesmas armadilhas – apenas mover nossas ervilhas de um lado para o outro do prato. A complexidade nunca desaparece realmente.

Os riscos das plataformas internas de desenvolvedores

As plataformas internas de desenvolvedores deveriam, em princípio, reduzir a carga cognitiva dos desenvolvedores, reunindo todas as ferramentas operacionais que vêm com os contêineres em um só lugar. Mas será que este tipo de centralização é realmente eficaz? Servir seus desenvolvedores em uma plataforma central traz grandes riscos.

Superengenharia

Os analistas disseram: “Vá construir uma plataforma”. Mas o problema com recomendações como essa é que elas são feitas pensando em empresas como a Netflix. A maioria das empresas simplesmente não tem o mesmo tamanho e escala que teria os problemas que empresas como a Netflix têm, mas têm a tarefa de resolvê-los de qualquer maneira.

Sumidouro de Recursos

Uma equipe de plataforma totalmente nova pode gastar dois anos e milhões de dólares construindo um novo produto interno para desenvolvedores: a plataforma interna para desenvolvedores. Mas não há garantias de que, uma vez construído, este novo produto funcione para as pessoas.

Antes de gastar todos aqueles dólares, horas, suor e lágrimas, como você pode saber se a plataforma algum dia retornará valor?

Silos de ferramentas

As soluções empresariais são propostas complexas. Ferramentas cada vez mais especializadas para cada estágio do ciclo de vida de desenvolvimento de software facilitaram funções organizacionais específicas, mas pouco fizeram para melhorar a colaboração com outras funções usando suas próprias ferramentas especializadas. Cada equipe termina em um silo de ferramentas.

A ideia original por trás do DevOps era resolver esse isolamento ajustando a estrutura organizacional e melhorando a comunicação. A plataforma interna do desenvolvedor, concebida como uma maneira infalível para um desenvolvedor entregar seus aplicativos sem atrito, marca um afastamento dessa comunicação e colaboração. Na versão de 2024 de “jogar por cima do muro”, o muro fica entre as equipes da plataforma e os desenvolvedores, e ninguém sabe ao certo o que está acontecendo do outro lado.

Precisamos de ferramentas que promovam a comunicação em geral, e não apenas a comunicação em torno de ferramentas. Vamos reconhecer que as partes interessadas utilizam diferentes competências exigidas e vivem em mundos diferentes. Em vez de procurar o mínimo denominador comum entre estas partes interessadas, vamos maximizar as suas capacidades, dando-lhes a capacidade de se concentrarem naquilo em que são bons.

O que vem depois?

E se, em vez de pingue-pongue entre centralização e descentralização, entre silos de ferramentas e a única ferramenta para governá-los todos, facilitarmos as conversas entre ferramentas? E se fornecermos a cada um dos especialistas no assunto que compõem uma solução complexa uma estrutura comum para descrever, implantar e testar seu escopo de trabalho?

Tal solução seria uma alternativa leve à abordagem de tudo ou nada dos deslocados internos, sem um vale-tudo completamente descentralizado.

Na Garden, estamos trabalhando para ajudar as equipes a trabalhar de uma forma mais modular, dando-lhes a capacidade de obter o trabalho de outras pessoas para testar seu próprio trabalho em relação ao panorama geral. Acreditamos que as ferramentas que lidam com a complexidade, em vez de abstraí-la ou transferi-la para outras equipes, virão a seguir.

A postagem O que vem depois das plataformas internas de desenvolvedores? apareceu primeiro em The New Stack.