De DevOps para MLOps e platform engineering: o que aprender

A pergunta incômoda de todo profissional DevOps#

Existe uma conversa que se repete nos times de infraestrutura: se a IA consegue escrever YAML, gerar pipelines básicos, revisar logs e propor configurações iniciais, o que sobra do papel DevOps tradicional?

É uma preocupação legítima. Boa parte do trabalho que por anos definiu um engenheiro DevOps é manual, repetitivo e automatizável, o que o livro de SRE do Google chama de toil. É justamente o tipo de trabalho que as ferramentas de IA fazem cada vez melhor. Gerar um manifesto de Kubernetes, esboçar um pipeline de CI/CD ou resumir um stack trace já não diferencia ninguém.

Mas confundir “parte das minhas tarefas está sendo automatizada” com “meu papel está desaparecendo” é um erro de leitura. DevOps não está morrendo: está subindo na cadeia de valor, e quem entende esse movimento a tempo acaba num papel mais estratégico.

Documentação: Google SRE Book · Eliminating Toil ↗

DevOps não desaparece: muda seu centro de gravidade#

O futuro de DevOps não é escrever menos infraestrutura, e sim projetá-la melhor e deixar que a execução repetitiva seja automatizada.

Quando a IA absorve a camada operacional básica, ganha valor o que a IA não faz bem: decisões de arquitetura, trade-offs entre custo e desempenho, desenho de plataformas seguras e escaláveis, e operar sistemas complexos em produção sem que caiam às 3 da manhã.

Três disciplinas concentram esse movimento, e as três são uma evolução natural de um perfil DevOps, não uma mudança de carreira:

• Platform engineering: construir plataformas internas que o resto da organização consome em self-service.
• MLOps: levar modelos de machine learning e IA para produção de forma confiável, reproduzível e monitorada.
• DevSecOps: integrar segurança e compliance ao design, não como remendo final.

A boa notícia: se você vem de DevOps, boa parte do caminho já foi percorrida.

De DevOps para platform engineering: de operar a habilitar#

Platform engineering responde a um problema real: os times de desenvolvimento não querem virar especialistas em Kubernetes, redes e configuração de nuvem para colocar uma aplicação no ar. Cada hora que um dev passa brigando com a infraestrutura é uma hora sem construir produto.

O papel DevOps tradicional resolvia isso atendendo tickets. Platform engineering resolve construindo um produto interno: caminhos pavimentados (golden paths), templates seguros por padrão e self-service que escondem a complexidade da nuvem. A DORA relata que, em 2025, 90 % das organizações declaravam usar uma plataforma interna de desenvolvimento e 76 % tinham times de plataforma dedicados.

A mudança de mentalidade é grande. Você deixa de executar deploys e passa a projetar o sistema com o qual centenas de deploys acontecem sozinhos. Seu cliente já não é um servidor, é o dev interno, e sua métrica já não é “ticket fechado”, e sim quanto tempo um time leva para colocar código em produção com segurança.

A base, Kubernetes, infraestrutura como código, automação, pipelines e observabilidade, continua sendo o alicerce. O que se soma é pensamento de produto, design de experiência do desenvolvedor e critério de padronização. O Backstage, o framework de portais de desenvolvedor que o Spotify doou à CNCF, é um bom lugar para ver como se modela um catálogo de serviços e templates.

Para se aprofundar: Coding agents nas empresas: o desafio é a infraestrutura

Documentação: DORA · Platform engineering ↗ · CNCF TAG App Delivery · Platforms white paper ↗ · Backstage · What is Backstage? ↗

De DevOps para MLOps: a infraestrutura é o verdadeiro desafio da IA em produção#

Existe um mito caro: o de que fazer IA é, acima de tudo, um problema de ciência de dados. O paper do Google sobre dívida técnica oculta em sistemas de ML mostra isso com clareza: o código do modelo é uma fração pequena do sistema, cercada de coleta de dados, configuração, serving, monitoramento e infraestrutura. Manter um modelo em produção, com baixa latência, detectando sua degradação, retreinando quando os dados mudam, controlando o custo de GPU e com rastreabilidade, é um problema de infraestrutura e operações. Ou seja, o seu terreno.

MLOps é, na essência, DevOps aplicado ao ciclo de vida dos modelos, e quase tudo o que você sabe se transfere:

• Os pipelines de CI/CD se estendem para versionar dados e modelos, não só código; o Google descreve isso como passar de deploys manuais para treinamento contínuo.
• A observabilidade se amplia: além de CPU e latência, você monitora desvio de dados (data drift), desvio de conceito e qualidade das predições.
• A automação cobre o retreinamento e o deploy de novas versões do modelo.
• A gestão de custos se torna crítica: a IA consome computação cara, e alguém precisa projetar a infraestrutura para escalar sem queimar o orçamento.

O que é novo é o vocabulário e as ferramentas: model registries, feature stores, versionamento de datasets, frameworks de serving e monitoramento de modelos. Conceitos novos, montados sobre fundamentos que você já domina. Um model registry, por exemplo, é para um modelo o que um registry de imagens é para um container:

import mlflow
from mlflow import MlflowClient

MODEL = "fraud-detector"
run_id = "<run-id-do-treinamento>"   # fornecido pelo pipeline de treinamento

# 1. Registrar o artefato como uma nova versão do modelo
mv = mlflow.register_model(f"runs:/{run_id}/model", MODEL)

# 2. Promover só se passou na avaliação automática no CI
client = MlflowClient()
client.set_registered_model_alias(MODEL, "champion", mv.version)

# 3. O serviço de inferência carrega o alias, não uma versão fixa:
#    um rollback é mover o alias para a versão anterior.
model = mlflow.pyfunc.load_model(f"models:/{MODEL}@champion")

Os serviços gerenciados seguem a mesma lógica: o SageMaker Model Monitor e o Vertex AI Model Monitoring comparam o tráfego de produção com uma linha de base e alertam quando ele se desvia.

Documentação: NeurIPS 2015 · Hidden Technical Debt in Machine Learning Systems ↗ · Google Cloud · MLOps: continuous delivery and automation pipelines in ML ↗ · MLflow · Model Registry ↗ · AWS · SageMaker Model Monitor ↗ · Google Cloud · Vertex AI Model Monitoring ↗

DevSecOps: a segurança deixa de ser opcional#

À medida que a infraestrutura passa a sustentar IA, automação e dados sensíveis, a superfície de ataque cresce e a regulação aperta. DevSecOps vira parte do design base: gestão de segredos, policy as code, varredura contínua, controle de acessos e compliance auditável desde o primeiro commit.

O Secure Software Development Framework do NIST (SP 800-218) é uma boa referência para organizar essas práticas, e ferramentas como o Open Policy Agent permitem expressar regras de deploy como código revisável.

Para um perfil DevOps, é uma oportunidade clara de especialização: uma empresa que adota IA sem uma camada sólida de segurança está construindo um risco, não uma vantagem.

Documentação: NIST SP 800-218 · Secure Software Development Framework ↗ · Open Policy Agent · Documentation ↗

O que priorizar para evoluir sem começar do zero#

Com uma base sólida de DevOps, você não precisa se reinventar: precisa se reorientar. Uma ordem razoável:

• Aprofunde Kubernetes e infraestrutura como código até o nível de design, não só de uso; inclua o agendamento de GPUs no Kubernetes se estiver indo para MLOps.
• Domine a observabilidade de verdade: métricas, traces e logs e, principalmente, a capacidade de explicar o comportamento de um sistema em produção. O OpenTelemetry é o padrão aberto que vale conhecer.
• Aprenda o ciclo de vida de modelos: versionamento de dados e modelos, serving, retreinamento e monitoramento de drift.
• Incorpore pensamento de plataforma e de custos: self-service, escalabilidade e eficiência do gasto com nuvem.
• Trate segurança como design, não como remendo.
• Use a IA como multiplicador: deixe que ela automatize o repetitivo para você se concentrar em arquitetura e decisões.

Documentação: Kubernetes · Schedule GPUs ↗ · OpenTelemetry · What is OpenTelemetry? ↗ · Kubeflow · Pipelines overview ↗

A infraestrutura continua sendo a base#

A IA não elimina a necessidade de boa infraestrutura: ela a amplifica. Cada modelo em produção, cada agente e cada fluxo automatizado se apoia em computação, redes, segurança, pipelines e observabilidade que alguém precisa projetar e operar bem. Essa camada decide se um projeto de IA escala de forma rentável ou vira um buraco de custos.

Por isso o perfil DevOps não corre risco de extinção. Ele está no centro da próxima onda, desde que saia da execução operacional e vá para o design estratégico. Não dá para montar IA sobre infraestrutura improvisada, e construir essa base continua sendo o trabalho mais valioso do mundo DevOps.

Perguntas frequentes#

Qual a diferença entre MLOps e platform engineering? MLOps gerencia o ciclo de vida dos modelos em produção; platform engineering projeta plataformas internas de self-service para desenvolvedores. As duas nascem de DevOps com focos diferentes, e em muitas empresas a plataforma acaba oferecendo capacidades de MLOps como mais um serviço.

Que habilidades técnicas preciso para MLOps? Fundamentos de machine learning, orquestração de pipelines com ferramentas como Kubeflow ou MLflow e monitoramento de modelos em produção: desvio de dados, desvio de conceito e latência de inferência. Você não precisa virar cientista de dados.

Ainda vale a pena aprender DevOps? Sim. Automação, CI/CD e infraestrutura como código continuam sendo a base das duas especialidades. O que muda é o foco: design de sistemas e plataformas em vez de execução manual repetitiva.

Como começo em platform engineering? Parta do princípio de que você está construindo um produto para outros desenvolvedores. Explore golden paths e o Backstage, e meça o sucesso pela redução de tickets de suporte e do tempo que um time novo leva para fazer o primeiro deploy.

O que acontece se eu não evoluir meu perfil? O risco é a comoditização: as tarefas operacionais manuais são cada vez mais automatizáveis, e o valor profissional se desloca para arquitetura, design de plataformas e operação de sistemas complexos.

Documentação: Backstage · What is Backstage? ↗ · Kubeflow · Pipelines overview ↗ · MLflow · Model Registry ↗