Nunca escolhi ser engenheiro DevOps. E não, não pretendo discutir o título, porque tecnicamente nunca deveria ter sido um. Mas, por simplicidade, vamos fingir que é, e deixem que vos explique como é que cá cheguei, porque nunca foi um plano. O código, por sinal, foi consequência do amor pela tecnologia, não o contrário.

O miúdo que queria explorar

Era novo e gostava de invadir coisas, mas queria uma forma de experimentar sem me meter em sarilhos. Por isso comecei a juntar sistemas, cruzando o que sabia de hardware e de infraestruturas físicas, à procura de formas de automatizar o meu laboratório, para conseguir replicar ambientes o mais depressa possível e ter assim algo em que tentar entrar. Foi aí que acabei por escrever sobre aquele pequeno datacenter e, mais tarde, sobre como ele foi crescendo.

Depois comecei a fazer self hosting com a intenção de ir atacar o laboratório. E depois… pois… tudo se foi baralhando. Antes de dar por isso já não andava a invadir nada, andava mais a pôr coisas a funcionar umas com as outras. A minha curiosidade sem fim e a sede de aprender foram-me empurrando, à minha maneira, para o DevOps, e a frase que me acompanhou durante anos foi esta: se quero saber como é que se parte uma coisa, tenho de perceber como é que ela funciona.

Este labirinto de tantos anos acabou por dar em escrever código, coisa que nunca chegou a fazer-me clique. Aprendi Pascal, C++, Visual Basic na escola, mas nada disto me atraiu. Só até talvez há uns 10 anos, quando comecei a escrever uns scripts em bash, e isso… era divertido. Podia automatizar tarefas, podia invadir coisas mais depressa. Depois fui trabalhar para a AWS, onde pude mesmo usar bash para automatizar muitas das tarefas de arranque do datacenter, e caramba, cheguei mesmo a escrever um script parvo de bash + expect para automatizar a instalação de switches e routers out of band. E foi aí que comecei finalmente a perceber uma coisa: mais vezes do que não, não há ferramentas prontas para tudo. Mas eu estava contente com isso, porque achava que conseguia fazer tudo com bash, que continuava a não precisar de aprender uma linguagem de programação a sério. Bash chega-me!

Programar finalmente fez sentido!

Uns anos mais tarde, comecei a trabalhar mais de perto com os developers e a ter dificuldade em perceber o que é que queriam dizer, por isso fui aprender programação a sério. Aprendi Python, fui fazendo umas coisas, escrevi uns scripts, umas ferramentas, uns bots de Discord e Slack, e não demorou muito até ter de lidar com tudo à volta do Python: venvs, dependências, distribuir uma ferramenta a outra pessoa era um pesadelo. Durante um bocado, programar deixou de ser divertido outra vez, até que comecei a reparar na linguagem utilizada para construir todas as ferramentas que eu gostava. Golang. Por isso puxei pelo travão de mão, virei 180 graus, e comecei a aprender e a perceber Go, e antes de dar por isso apaixonei-me por programar, ainda que a um nível muito superficial.

Continuo a odiar todo o jargão, os design patterns, o clean code, o TDD ou todas essas filosofias esquisitas. Sou uma criatura simples, gosto de coisas simples e detesto esta conversa toda sobre OOP vs funcional, TDD ou não, este padrão é melhor do que aquele. Foda-se tudo isso! Escrevo código porque me dá gozo ter um problema e resolvê-lo. Sim, para código importante concordo a cem por cento que deve ser testável e que devemos escrever testes, mas a ordem? Que se foda! Desde que existam estou contente, até porque só cobrem os casos conhecidos, e muitas das vezes nem sequer sabemos o que queremos, quanto mais saber aquilo que temos de testar! Escrever o protótipo, deitá-lo fora e depois escrever a coisa boa? Quem defende tal coisa, digam-me lá onde é que se arranja essa paciência toda? Eu aborrecia-me e abandonava o projecto a meio caminho, ou, quando chegava a altura de implementar, já o projecto não servia o propósito! Tempo perdido!

Dito isto, a minha única preocupação sempre foi escrever código que funcione como deve ser e que internamente faça sentido, especialmente para o eu daqui a seis meses que não se vai lembrar de merda nenhuma do que foi feito. Se o eu daqui a seis meses consegue perceber aquilo, então qualquer pessoa consegue!

Então o DevOps ainda é relevante? É, e é aqui que dói

Mas os tempos mudam, e temos de estar prontos para mudar com eles. E hoje dou por mim numa encruzilhada. Temos LLMs mesmo poderosos, que conseguimos domesticar e transformar em agentes cada vez mais capazes, e as coisas que eles conseguem fazer hoje são impressionantes. À data de hoje, o código que escrevem é, em muitos casos, muito melhor do que aquilo que eu escreveria, e escrevem-no muito mais depressa. E se revejo o código? Pois, para mim, neste momento, parece-me código perfeitamente bom, já não é o mesmo esparguete que costumavam cuspir. E ainda melhor, agora já não preciso de ficar acordado até tarde porque não consigo deixar de pensar naquele bocado de código que tenho de pôr a funcionar para poder passar à etapa seguinte. Posso dizer ao agente o que quero e o que tem de fazer, ir para a cama e, na manhã seguinte, já está feito. E a minha opinião não ficou nada mais conservadora desde a última vez que escrevi sobre o assunto.

Com tudo isto, fiquei a pensar: para onde vou? O que faço? Como é que faço? O DevOps ainda será relevante? O que tenho andado a fazer e de que gosto há mais de uma década ainda tem valor? A conclusão é que sim, tem, mesmo mais do que nunca. Se calhar não na forma ou no formato a que me habituei, mas parece que o DevOps vai finalmente tornar-se aquilo para o qual foi realmente criado. O papel do engenheiro DevOps, que era basicamente apenas uma palavra chique para dizer “hacker generalista que sabe juntar as coisas e conduzir os devs”, desapareceu: agora os devs também têm esse poder na ponta dos dedos. A infraestrutura está praticamente resolvida, e com infraestrutura como código, o que precisamos mesmo é de perceber como as coisas funcionam! As entranhas e os pormenores de implementação? Já não precisamos de nos chatear com isso, porque agora qualquer agente trata disso de forma bastante eficaz. E nem sequer precisamos dos agentes mais potentes, caramba, o Qwen3.8-27B já é bastante competente e corre no meu portátil. Não é propriamente um portátil fraquinho, mas continua a ser um portátil. O génio saiu da garrafa e agora já não volta lá para dentro, na mesma medida que quando o Google apareceu, aquilo até parecia batota! A IA já está nesse ponto e vai acabar por estar, se não está já, tão enraizada naquilo que fazemos que nem vamos pensar duas vezes antes de a usar.

E esta é a primeira crença antiga que tive de largar. Quando, em 2023, escrevi sobre o DevOps como cultura e estilo de vida, escrevi sobretudo sobre as ferramentas. Se lá voltar agora, vejo que as ferramentas nunca foram a parte importante, mas sim a forma de pensar e de abordar os diferentes problemas.

E se…

Talvez tenhamos andado a ver as coisas ao contrário. Agora podemos fazer muito mais em menos tempo, por isso vamos mas é fazer ainda mais? NÃO. Isto está simplesmente errado. E se, agora que podemos fazer muito mais, em vez disso reivindicássemos esse tempo extra para nós? Para alguns de nós, sim, claro, significa fazer ainda mais merda, porque somos completamente viciados nisto, no trabalho, na tecnologia, em fazer os computadores fazerem brrr. Mas também significa que devemos repensar o que é ser produtivo e passar mesmo a reivindicar tempo para nós. Estamos provavelmente tão presos naquilo a que vamos chamar as velhas maneiras, em que viver é continuar a trabalhar.

Já vi tanta gente dizer “quem me dera que a IA fizesse as minhas tarefas domésticas e eu limitava-me a programar”, mas vamos fazer uma pausa antes de continuar. Acreditem que esta ideia tem andado às voltas na minha cabeça há bastante tempo. Pensei muito nisso, discuti muito comigo mesmo, todos os “mas” e todos os “e se” me passaram pela cabeça. Mas porque diabo é que se escreve código, afinal? Não era precisamente para isso que servia? Para atingir um resultado e chegar a um objectivo? Para finalmente deixar de fazer A, B ou C e ter tempo para D? Então agora podemos perfeitamente deixar de fazer mais uma coisa, deixar de escrever código, e fazer mais coisas que precisam realmente de nós!

Agora que podemos chegar ao resultado mais depressa, já não somos um estrangulamento. Já não temos de decorar a sintaxe da linguagem X ou da linguagem Y e as suas entranhas. Podemos parar de discutir sobre frameworks e paradigmas! Python é melhor para a tarefa X? Então Python. Golang é melhor para a tarefa Y? Muito bem. A performance começa a ser uma preocupação? Então Rust. OOP? Funcional? Qual o melhor framework web? Lixo com isso tudo, porque agora pouco importa. Os agentes não querem saber disso. Tanto lhes faz se o código está todo escrito numa linha ou em 500, ou se está formatado como uma obra de literatura!

Todas essas coisas foram tentativas de abstrair a máquina o máximo possível e de conseguir programar o mais próximo possível da linguagem humana, de modelar e expressar problemas de forma mais simples para a nossa compreensão, uma vez que programar perto do hardware sempre foi um tipo de feiticaria só ao alcance de alguns! Agora que finalmente conseguimos dizer à máquina o que queremos, mesmo que de forma vaga, e a máquina faz, os benefícios que várias linguagens e paradigmas nos proporcionaram passam simplesmente a ser artefactos do passado, e os agentes passam a escrever o código mais próximo do hardware possível, porque são mais rápidos e eficientes do que qualquer humano alguma vez possa ser!

Dito isto, porque não passamos a usar os nossos agentes para escrever o nosso código e construir o nosso negócio, enquanto nós, humanos, apreciamos o facto de podermos ser exactamente isso… humanos? Sair e dar uma volta, fazer as tarefas de casa, lavar a roupa, ler um livro, aprender a tocar um instrumento ou aquela música que andam a adiar porque não há tempo, praticar um desporto, talvez tornarem-se instrutores desse desporto, ver as árvores e a relva crescer ou simplesmente fazer o que vos sabe bem como actividade de fim de semana.

Pois, pois, eu sei. Muita gente diz mesmo que gosta de programar (DIZ!). Eu já estive aí, ando a lutar com isto há muito tempo e brinco com IA desde quando era apenas um autocomplete mais chique. Mas vamos mais fundo: é mesmo isso ou era o resultado? Está na altura de passar a olhar para o código escrito manualmente como se olha para o artesanato, uma arte que só umas poucas pessoas vão praticar à mão. Eu provavelmente não vou ser uma delas porque o código nunca foi exactamente aquilo que me atraiu. E agora posso reivindicar tempo para outras coisas: ler finalmente aquele artigo, experimentar aquela tecnologia nova que alguém construiu, testar uma forma diferente de trabalhar. Sair e explorar, às vezes nas montanhas reais com a minha prancha de snowboard, às vezes no mundo digital, e finalmente ir atrás da emoção que vem com a descoberta do desconhecido!

Então o que resta? A compreensão

Por isso, sim, o DevOps hoje continua a ser muito relevante, mas como cultura, como filosofia. E passa a ser muito mais uma questão de processos, identificar onde automatizar, onde estão os estrangulamentos, perceber profundamente os sistemas e pô-los a funcionar uns com os outros. A camada em que vamos trabalhar vai ser um bocado mais alta, e o resto? Detalhe de implementação.

Portanto, começam um produto e precisam só de uma VM? Comecem uma, empurrem o produto para lá, e um dia o produto cresce. Agora precisam de um pipeline? Ótimo, criem um, está no GitHub, no GitLab, no CircleCI, tanto faz, mandem o clanker fazer isso funcionar, e se não estão satisfeitos com o serviço que lhes estão a prestar, mudem para o seguinte. Agora a VM na Hetzner já não chega? Escalem para mais umas e mandem o clanker escrever o Terraform por vocês. Não querem Terraform? Pulumi? Isso também têm. O conhecimento de ferramentas específicas deixou de ser uma restrição, e agora temos uma quantidade infinita de ferramentas e conhecimento à nossa disposição. Podemos, mais do que nunca, usar a melhor ferramenta para o trabalho sem nos andarmos a preocupar com os pormenores.

E eu sempre fui bom a fazer uma coisa: perceber aquilo a fundo e fazer com que faça o que eu preciso, mesmo quando não foi desenhado para tal. Escrever código de todos os tipos, bash, Python, Ansible, Terraform, Golang, foi sempre consequência de uma necessidade de alcançar alguma coisa e de resolver isso. Agora a IA dá-me esse poder. O código é barato, mas o que continua caro é aquilo que nós, humanos, temos e que traz valor real: a capacidade de pensar mesmo a fundo sobre alguma coisa, a compreensão das coisas, a forma de as juntar.

E agora posso finalmente voltar a isso, porque a IA pode manter a maior parte do meu homelab por mim, pode escrever o código, pode monitorizar e avisar-me quando alguma coisa precisa da minha atenção. Isso deixa-me soltar a imaginação e experimentar coisas não só a uma velocidade absurda, mas também reclamar tempo para mim: ir ao ginásio, fazer snowboard, fazer finalmente aquelas coisas que não conseguia fazer porque estava ali a bater nas teclas para resolver um problema que tinha no cluster de Kubernetes quando só queria ver um filme. Isto é lindo, e é isto que me deixa ainda mais apaixonado pela tecnologia. Não pelo DevOps, nem pela programação, pela tecnologia. Por ser tecnólogo. Porque ontem era engenheiro DevOps, hoje é platform engineer, amanhã será outra coisa, mas tecnologia essa vai estar sempre ali para brincarmos, explorarmos e nos divertirmos imenso. E epá, assim que aceitam isto e aprendem a largar, a quantidade de divertimento é infinita!

O DevOps não vai ser saber usar o Kubernetes, saber usar o ECS, a AWS, o Azure. Não vai ser saber escrever código, nem saber escrever um pipeline de CI/CD, e caso tenham perdido, já me pronunciei sobre isto há uns anos, nada mudou nesse sentido.

E não é só o DevOps. O desenvolvimento de software vai passar muito mais a ser sobre perceber sistemas, perceber que problemas resolve cada ferramenta e quais são os seus compromissos. Kubernetes vs ECS. Python vs Go. Perceber quando é que se deve usar a ferramenta certa, porque o resto é só detalhe de implementação. Perceber quando é que se usa apenas uma VM simples na Hetzner, ou quando é que se precisa mesmo de um cluster Kubernetes completo, de pipelines, de observabilidade. Que métricas são precisas, que ferramentas usar para perceber o sistema, o que se está a passar, e tomar a decisão certa à hora certa.

São dois campos que dizem quase a mesma coisa e que, com o tempo, se vão entrelaçar cada vez mais, como deviam ter feito desde o início. Por isso, se forem macacos de um só truque que só sabem fazer deploy de coisas para o Kubernetes, ou só sabem escrever código na vossa linguagem preferida, vão passar um mau bocado, porque as coisas estão a mudar, se já não mudaram!

As crenças antigas não nos levam ao novo queijo

Enquanto pensava nisto, num dia no ginásio, apareceu-me na cabeça uma citação de um livro:

“As crenças antigas não nos levam ao novo queijo.”

Spencer Johnson, Quem mexeu no meu queijo?

Se chegaram até aqui neste artigo, epá… muito obrigado por estarem deste lado e por fazerem parte desta viagem!

Quanto a mim, vou fazer aquilo que sempre fiz melhor: seguir o instinto e deixar a minha paixão por tecnologia indicar o caminho. Neste momento, o que me parece certo é largar as crenças antigas, deixar os agentes escreverem o código enquanto me concentro em perceber os problemas e explorar as oportunidades. O foco está em construir o Searchbase, que tem uma boa parte do código escrita por mim, mas que já tem um bom conjunto de funcionalidades feitas inteiramente por agentes; em tentar ao máximo ajudar equipas a reduzir a complexidade e a adoptar IA de forma eficaz; e em concentrar-me cada vez mais naquilo de que sempre gostei: a cibersegurança. Se isto passar a ser mais do que um passatempo, o tempo dirá. Mas tenho a certeza de que tenho qualquer coisa de valor para contribuir para essa área e de que vou encontrar forma de levar a minha experiência em infraestrutura e DevOps para a infosec… acho que agora lhe chamam DevSecOps? Tanto faz, pouco se me dá. Vou fazer as minhas coisas, seja qual for o nome que lhe deem.

Escrito com a ajuda do GPT-6 Luna (OpenAI).