Preparando-se para o futuro: Por que os desenvolvedores e profissionais de infraestrutura precisam sair de suas zonas de conforto

Matthew Finio: como está mudando a relação entre desenvolvedores e profissionais de infraestrutura?

Miha Kralj: toda a profissão de desenvolvedor mudou com o surgimento de “tudo definido por software” — redes definidas por software, armazenamento definido por software, computação definida por software.

No passado, os profissionais de infraestrutura ficavam de um lado e os desenvolvedores de software do outro, e mal se comunicavam. Um cuidava de todos dos ativos por trás das cortinas, enquanto o outro escrevia código e tornava ideias realidade.

Agora, tudo isso está desmoronando. Nenhum dos lados está preparado para a era atual. E nenhum entende de segurança, que também precisa ser considerada. Eles precisam começar a aprender uns com os outros, e isso é difícil para ambos.

É como no livro Quem Mexeu no Meu Queijo — nenhum dos lados se sente muito à vontade se vem do mundo tradicional antigo. As gerações mais jovens, que cresceram com Gmail e YouTube, já vivem nesse novo mundo integrado. Mas aqueles que começaram suas carreiras na infraestrutura tradicional ou no desenvolvimento tradicional enfrentam dificuldades porque não aprenderam o “outro lado” desde o início.

MF: então, tanto os desenvolvedores quanto os profissionais de infraestrutura deveriam repensar suas descrições de cargo?

MK: exatamente. Desenvolvedores não devem mais pensar que são apenas desenvolvedores de aplicações. Profissionais de infraestrutura não devem mais pensar que são apenas operadores. Hoje, as equipes modernas seguem uma lógica de engenharia de produto, em que todos devem ser capazes de assumir a função de outra pessoa, se necessário. Ainda existem especializações, claro, mas um desenvolvedor, quando necessário, deve conseguir escrever um script Terraform, algo que antes era exclusivo da infraestrutura.

Ou seja, quando alguém for perguntado sobre sua função, não deve responder “sou desenvolvedor de software” ou “sou da área de infraestrutura/operações”. Todos estão construindo um produto ou ajudando a criar um serviço, e esse serviço só se torna realidade quando todas as partes estão corretamente integradas. Todos precisam entender a cadeia completa, o ciclo de vida como um todo, de cima a baixo.

MF: você mencionou o Terraform. Quais são outros conceitos de infraestrutura que os desenvolvedores precisam aprender?

MK: frequentemente, os desenvolvedores não entendem exatamente como a infraestrutura subjacente realmente funciona, o que pode durar e o que pode ser efêmero.

Se você, por exemplo, faz alguma alteração no host, contêiner ou componente serverless que está executando algo, essa alteração vai persistir quando esse componente — essa máquina virtual — for movido para outro lugar? Então, o conceito de sistemas que armazenam seus estados em outro lugar, os sistemas stateless, é um dos pontos de partida que os desenvolvedores devem começar a entender. Como criar algo infinitamente escalável? Como criar sistemas muito duráveis e elásticos? Todos esses conceitos arquitetônicos são implementados por software, mas na verdade se baseiam em padrões de infraestrutura.

Também vale a pena entender todos os padrões de segurança para criar a menor superfície possível no código, aquela com menor probabilidade de ataque. E como se comunicar corretamente com algum serviço remoto. Você vai escrever um serviço “tagarela” que envia cem perguntinhas pela rede a cada segundo? Ou vai agrupar todas as requisições e enviá-las em blocos maiores, com menos frequência?

Essas são decisões extremamente importantes que todo desenvolvedor precisa tomar, mas ele não vai entender por que está tomando essas decisões se não souber o que está acontecendo nos bastidores, como os sistemas realmente funcionam. Essa compreensão do sistema de baixo para cima é crucial. O desenvolvedor precisa escrever um código limpo e de qualidade, que não sobrecarregue o sistema, que não trave o banco de dados e que não cometa erros graves.

Se voltarmos 20 ou 30 anos, havia uma profissão dedicada a otimizar consultas de banco de dados para o menor número de ciclos de CPU e o mínimo de travamento dos dados. Muito desse conhecimento se perdeu. Mas ainda é extremamente importante entender como criar um sistema de alto desempenho e otimizado em termos de custo. Essas lições não devem ser esquecidas.

Você pode estar pensando: “Ah, estamos em 2025, vovô, senta aí! O mundo moderno é totalmente diferente. Você não entende nada!” Pois bem, nós construímos esse mundo moderno, e estamos aqui para ajudar os novos desenvolvedores e os novos profissionais de infraestrutura a usá-lo da maneira mais eficiente possível.

MF: você pode descrever algumas maneiras pelas quais os desenvolvedores podem usar ferramentas de infraestrutura como ferramenta para melhorar seu fluxo de trabalho?

MK: sim. Um bom exemplo seria como um desenvolvedor pode criar um fluxo de trabalho adequado para que seu próprio código seja automaticamente testado, compilado e empacotado sempre que ele escrever algo novo e enviar isso para um repositório. Os desenvolvedores não deveriam depender de alguém da infraestrutura para fazer isso por eles. Criar um bom script YAML no GitHub é uma tarefa de infraestrutura como código que todo desenvolvedor pode otimizar para tornar esse processo o mais eficiente possível.

Assim, por exemplo, um desenvolvedor não precisa ter o empacotamento completo, a validação completa e os testes completos se estiver trabalhando apenas no ramo de desenvolvimento. Esse desenvolvedor dirá: "Ei, estou no ramo de desenvolvimento, posso ignorar todas essas 20 tarefas que são destinadas apenas ao ramo de produção".

Mas, se você está em produção, precisa automatizar várias etapas, ativar a máquina que vai realizar toda a verificação de segurança e a validação completa do código, entre outras tarefas. Todas essas pequenas decisões que vão afetar a rapidez com que você conclui a compilação e a rapidez com que vê os resultados depois de confirmar o código, todo desenvolvedor deve ser capaz de alterar a infraestrutura como scripts de código e ajustá-las ao seu próprio fluxo de trabalho.

É como quando esses mesmos desenvolvedores gostam de ajustar seu ambiente de desenvolvimento integrado. Eles preferem suas próprias fontes, cores, atalhos de teclado e tudo mais. Eles também devem ser capazes de configurar seus próprios fluxos de trabalho, o que acontece depois que você se compromete com o código. Tudo isso é conhecimento derivado do IaC, infraestrutura como código.

MF: quais coisas específicas os profissionais de infraestrutura devem entender sobre o desenvolvimento de aplicativos hoje?

MK: infraestrutura como código — IaC — literalmente significa que as pessoas de infraestrutura estão se tornando programadores. A infraestrutura é definida com scripts, com dados, com código, o que significa que o script ou código de infraestrutura precisa passar pelo mesmo ciclo de vida de desenvolvimento de software que qualquer código que os desenvolvedores escrevam:

• Precisa ser devidamente documentado.
• Ele precisa ser armazenado adequadamente em um repositório.
• Ele precisa ser versionado corretamente.

Ele precisa ser tratado exatamente da mesma maneira. Pessoas da infraestrutura tradicional não entendiam isso nem eram capazes de fazer isso. Pessoas de infraestrutura podem configurar coisas, clicar com o mouse e talvez escrever alguns scripts Bash ou algo assim.

Mas agora é totalmente esperado que as pessoas de infraestrutura sejam programadores reais de infraestrutura. Eles precisam entender o Git. Precisam entender como fazer a verificação de segurança de sua infraestrutura como ativos de código. Seus ativos precisam ser versionados adequadamente e serão avaliados, e eles precisam entender o que é o pedido de pull. Esses são termos e atividades padrão que todo desenvolvedor de software conhece por padrão.

O pessoal de infraestrutura precisa se tornar full stack. E engenheiros full stack são difíceis de construir e difíceis de encontrar. Há uma escassez de pessoas que entendem tudo, desde a base — como os pacotes estão fluindo, como a rede funciona e como o kernel no sistema operacional funciona — até o topo. Por exemplo, como faço para realmente escrever múltiplas dependências de software? Usa pacotes de código aberto ou internos? Como escrever código assíncrono? Todas as perguntas de desenvolvimento de software puro. Dois enormes domínios colapsados em um só. O gestão de mudanças e a requalificação e o aprimoramento das habilidades para os talentos não estão disponíveis.

MF: se a requalificação e o upskilling são um desafio tão grande, como os profissionais de infraestrutura devem se manter atualizados sobre as tendências e tecnologias de desenvolvimento?

MK: bem, não há mais pessoas específicas para infraestrutura e pessoas específicas para desenvolvedores, tudo isso entrou em colapso em um único domínio. Todos estão aprendendo essas novas tendências, mudanças no ciclo de vida do desenvolvimento de software e, especialmente, as mudanças com a IA.

Conforme avançamos para um tipo de desenvolvimento nativo em IA, tanto os profissionais de infraestrutura quanto os desenvolvedores de aplicações precisam aprender esse novo paradigma. Todos sofrem com o efeito FOMO (medo de ficar para trás), achando que já estão atrasados. Eles acabaram de aprender engenharia de prompt e agora já estão ouvindo que precisam aprender a criar agentes no Semantic Kernel ou algo do tipo.

As pessoas precisam ajudar umas às outras, precisam encontrar o equilíbrio certo. Quanto tempo precisa ser dedicado para se manter atualizado e garantir que ainda se está na vanguarda? Antes eram 5%, agora são 10%. A IA generativa ajuda. Mas a proporção entre o tempo que se gasta aprendendo e o tempo que se aplica esse conhecimento para gerar valor para o negócio ou para a TI está cada vez mais inclinada para o aprendizado.

MF: e antes de encerrarmos, quais são os principais pontos que desenvolvedores e profissionais de infraestrutura devem ter em mente sobre aplicações modernas?

MK: não há mais tarefas divididas. As aplicações modernas já têm a infraestrutura praticamente embutida. Por exemplo, um desenvolvedor moderno escreve o código e solicita a criação de um contêiner. Não há um profissional de infraestrutura criando o contêiner para ele. Alguns trabalhos exigem mais foco em infraestrutura, mas também envolvem desenvolvimento. Outros exigem mais desenvolvimento de software, mas também conhecimento e acesso à infraestrutura.

Então, os profissionais de infraestrutura precisam pensar em se tornar desenvolvedores de software. E o mesmo vale para os desenvolvedores: eles precisam se tornar profissionais de infraestrutura.

Essas funções não são mais separadas, estão se fundindo. É como há uma década ou mais, quando todo time de desenvolvimento de software tinha desenvolvedores e testadores. Ninguém fala mais em testadores, porque essas duas funções se fundiram. Esse mesmo tipo de colapso e fusão de funções, desta vez entre desenvolvedores e profissionais de infraestrutura, está acontecendo agora.