2.0 -//Pentabarf//Schedule//EN PUBLISH BMUCAG@@talks.devopsdays.org -BMUCAG Rodando Agentes de IA no Kubernetes com o Agent Sandbox pt-br pt-br 20261017T091000 20261017T094000 003000

Rodando Agentes de IA no Kubernetes com o Agent Sandbox

O objetivo da palestra é apresentar e falar um pouco sobre o Kubernetes Agent Sandbox e as novidades do projeto. Como os agentes autônomos frequentemente geram e executam códigos em tempo real para resolver problemas, o projeto fornece um ambiente de computação isolado (através do recurso customizado Sandbox CRD) que impede que códigos maliciosos ou erráticos acessem dados confidenciais do sistema hospedeiro, apliquem alterações destrutivas ou que possam comprometer a segurança do ambiente. PUBLIC CONFIRMED Talk https://talks.devopsdays.org/devopsdays-juiz-de-fora-2026/talk/BMUCAG/ Auditório Paulo Cerqueira PUBLISH K38QGM@@talks.devopsdays.org -K38QGM Como Conquistei Minha AWS Cloud Practitioner (e o Método para Você Passar na Sua) pt-br pt-br 20261017T094000 20261017T101000 003000

Como Conquistei Minha AWS Cloud Practitioner (e o Método para Você Passar na Sua)

PUBLIC CONFIRMED Talk https://talks.devopsdays.org/devopsdays-juiz-de-fora-2026/talk/K38QGM/ Auditório Marlene Laysa de Aguiar PUBLISH MKZTMK@@talks.devopsdays.org -MKZTMK Platform Engineering na Prática: Primeiros passos na construção de uma Internal Developer Platform com Kubevela pt-br pt-br 20261017T104000 20261017T111000 003000

Platform Engineering na Prática: Primeiros passos na construção de uma Internal Developer Platform com Kubevela

Nesta palestra, vamos explorar como Platform Engineering resolve o gargalo entre código pronto e deploy em produção, construindo uma Internal Developer Platform (IDP) com KubeVela como engine de entrega. Na prática, vou mostrar como o modelo OAM (Open Application Model) permite encapsular toda a complexidade do Kubernetes — IRSA, autoscaling com KEDA, secrets, observabilidade — em ComponentDefinitions reutilizáveis escritos em CUE, onde o desenvolvedor declara apenas "o que precisa" (um webservice, um worker SQS, um cron job) e a plataforma cuida do resto via GitOps com ArgoCD, dando autonomia real ao dev sem sacrificar governança e segurança. PUBLIC CONFIRMED Talk https://talks.devopsdays.org/devopsdays-juiz-de-fora-2026/talk/MKZTMK/ Auditório Anna Luiza Laudares Alves Pimenta Silva PUBLISH JQ3VRH@@talks.devopsdays.org -JQ3VRH FinOps com IA e Open Source na Prática pt-br pt-br 20261017T111000 20261017T114000 003000

FinOps com IA e Open Source na Prática

Como transformar FinOps em uma prática real dentro de um ambiente de cloud? Nesta apresentação, vamos além dos conceitos básicos de FinOps para explorar uma abordagem prática de otimização de custos utilizando IA, automação e ferramentas open source. Serão apresentados exemplos de como analisar o consumo de recursos, identificar desperdícios e recursos subutilizados, detectar anomalias de custos e automatizar parte desse processo. Também veremos como a IA pode atuar como uma ferramenta de apoio à análise, ajudando equipes técnicas a interpretar dados e encontrar oportunidades de economia. A abordagem será independente de um provedor específico, mostrando conceitos e estratégias que podem ser aplicados em diferentes ambientes de cloud. O objetivo é demonstrar que FinOps não precisa ser um processo exclusivamente financeiro ou depender de plataformas comerciais: ele pode fazer parte da rotina de engenharia, utilizando as mesmas práticas de automação e cultura que já fazem parte do universo DevOps. PUBLIC CONFIRMED Talk https://talks.devopsdays.org/devopsdays-juiz-de-fora-2026/talk/JQ3VRH/ Auditório Jairo Coelho PUBLISH 7G9RAH@@talks.devopsdays.org -7G9RAH Velero + RustFS: backup open source para clusters Kubernetes pt-br pt-br 20261017T114000 20261017T121000 003000

Velero + RustFS: backup open source para clusters Kubernetes

PUBLIC CONFIRMED Talk https://talks.devopsdays.org/devopsdays-juiz-de-fora-2026/talk/7G9RAH/ Auditório Emerson Silva PUBLISH BSHYXU@@talks.devopsdays.org -BSHYXU Do Deploy ao Impacto, engenharia com mentalidade de produto pt-br pt-br 20261017T140000 20261017T143000 003000

Do Deploy ao Impacto, engenharia com mentalidade de produto

PUBLIC CONFIRMED Talk https://talks.devopsdays.org/devopsdays-juiz-de-fora-2026/talk/BSHYXU/ Auditório Brendo Freitas PUBLISH NM9SNQ@@talks.devopsdays.org -NM9SNQ 876GB, flood stage, produção parada: o que esse incidente ensina sobre observabilidade de IA pt-br pt-br 20261017T143000 20261017T150000 003000

876GB, flood stage, produção parada: o que esse incidente ensina sobre observabilidade de IA

Essa palestra é um post-mortem técnico real de um cluster OpenSearch que entrou em flood stage por crescimento descontrolado de índices netflow e chegando a 876GB em dois índices e bloqueando todas as operações de escrita do ambiente. O cluster foi recuperado em menos de duas horas. A narrativa cobre o incidente completo: identificação do problema, remoção do bloqueio read-only, correção do alias is_write_index, implementação da política ISM com retenção de 60 dias e correção do pipeline Data Prepper para injetar @timestamp via processor date — sem o qual a deleção por data não funcionava. O que não funcionou primeiro também entra: a tentativa inicial de forçar deleção direta falhou porque o alias de escrita apontava para o índice errado, o que custou tempo e é um erro comum que vale documentar. A conexão com IA não é apêndice e é a tese central da palestra: workloads de LLMs e agentes em produção geram volumes de traces, métricas e logs muito superiores ao netflow desse case. Quem não implementar política de retenção antes de subir IA em produção vai enfrentar uma versão muito pior desse problema, com complexidade de recuperação proporcionalmente maior. Sou Technology Manager e DPO na 4Linux, onde atuei diretamente nesse incidente em ambiente de cliente. A 4Linux opera infraestrutura e observabilidade para dezenas de empresas no Brasil, o que nos dá visibilidade sobre padrões de falha que times internos raramente documentam. PUBLIC CONFIRMED Talk https://talks.devopsdays.org/devopsdays-juiz-de-fora-2026/talk/NM9SNQ/ Auditório Jeovany Batista da Silva PUBLISH 7X3JSG@@talks.devopsdays.org -7X3JSG Proxy reverso: A camada de borda e a hora de evoluir pt-br pt-br 20261017T163000 20261017T170000 003000

Proxy reverso: A camada de borda e a hora de evoluir

É comum aprender proxy reverso, load balancer, CDN e API Gateway como coisas diferentes. Aprende-se o nome, a ferramenta mais conhecida e alguns casos de uso. Mas, na prática, essas fronteiras não são tão claras. Um load balancer L7 pode terminar TLS e fazer roteamento. Uma CDN também funciona como proxy reverso e pode aplicar políticas de segurança. Um API Gateway também termina TLS, roteia e pode fazer cache. Em produtos gerenciados de cloud, várias dessas responsabilidades aparecem juntas na mesma caixa, gerando questões de onde termina um e começa o outro. A talk propõe um modelo mental mais simples: pensar primeiro na responsabilidade e só depois na ferramenta. Tudo começa com um proxy reverso na frente da aplicação. Ele pode terminar TLS, esconder a origem, fazer cache e assumir parte do trabalho que antes ficava dentro da aplicação. Quando uma instância já não é suficiente, aparece a necessidade de distribuir carga e entra o load balancer. Quando os usuários estão espalhados pelo mundo, a mesma ideia de proxy aparece distribuída em vários pontos da rede com uma CDN. Quando o problema passa a ser autenticação, rate limiting, agregação e outras políticas de API, entra o API Gateway. E quando o problema deixa de ser quem entra na aplicação e passa a ser como dezenas de serviços conversam entre si, a mesma ideia aparece novamente, o proxy reverso ao lado de cada serviço, formando um service mesh. Serão apresentadas as necessidades de uma aplicação que cresce e assim cada nova camada aparece porque surgiu uma necessidade, e não porque a arquitetura "precisa" de mais uma tecnologia. Serão discutidos os pontos em que essas tecnologias se sobrepõem e por que produtos diferentes podem ocupar várias partes desse espectro ao mesmo tempo. Na parte final, alguns cenários mostram essas decisões na prática: quando um NLB não resolve um problema de L7, quando uma aplicação em produção precisa deixar de depender de uma única instância, quando uma origem começa a sofrer com usuários espalhados pelo mundo e quando um API Gateway acaba virando um gargalo para o tráfego interno. Também há casos em que a melhor decisão é simplesmente não evoluir. A ideia da talk é mostrar uma visão de que na hora de desenhar a arquitetura, não perguntar "qual ferramenta devo usar?", mas "qual problema apareceu e qual responsabilidade eu preciso colocar na borda?" PUBLIC CONFIRMED Talk https://talks.devopsdays.org/devopsdays-juiz-de-fora-2026/talk/7X3JSG/ Auditório Pablo Rezende