1 devopsdays-juiz-de-fora-2026 2026-10-17 2026-10-17 1 00:05 https://talks.devopsdays.org https://talks.devopsdays.org/media/devopsdays-juiz-de-fora-2026/img/logo_5HfQVR9.webp America/Sao_Paulo Auditório Talk 2026-10-17T09:10:00-03:00 09:10 00:30 O Agent Sandbox é uma solução de infraestrutura em Kubernetes voltada para a execução segura, isolada e eficiente de agentes de inteligência artificial. devopsdays-juiz-de-fora-2026-7075-rodando-agentes-de-ia-no-kubernetes-com-o-agent-sandbox Paulo Cerqueira pt-br 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. false https://talks.devopsdays.org/devopsdays-juiz-de-fora-2026/talk/BMUCAG/ Auditório Talk 2026-10-17T09:40:00-03:00 09:40 00:30 Nesta palestra compartilho, de forma prática e honesta, toda a minha jornada até a aprovação na AWS Certified Cloud Practitioner. O foco não será apenas a prova, mas principalmente o método de estudo que utilizei, as decisões que tomei ao longo do caminho e o que faria diferente se tivesse que começar hoje. Por que começar pela AWS Cloud Practitioner: como a certificação ajuda a construir uma base sólida em computação em nuvem, apresentando conceitos fundamentais de arquitetura, segurança, disponibilidade e responsabilidade compartilhada, essenciais para quem deseja iniciar sua jornada em Cloud e DevOps. Vou apresentar os cursos, simulados e plataformas que utilizei, explicar por que escolhi cada uma delas e como os simulados se tornaram minha principal ferramenta de aprendizado, como utilizei laboratórios práticos para consolidar conceitos importantes da AWS e por que acredito que apenas assistir aulas não é suficiente para construir uma boa base em Cloud. Por fim, compartilharei como funciona a experiência do exame: desde o agendamento e o processo de check-in com o proctor até a realização da prova e o recebimento do resultado, ajudando a reduzir a ansiedade de quem pretende fazer sua primeira certificação. O objetivo é que os participantes saiam da palestra com um roteiro claro de preparação que podem ser usados inclusive para preparação de outras certificações AWS, conhecendo os recursos que realmente agregaram valor na minha jornada e evitando erros comuns de quem está começando. devopsdays-juiz-de-fora-2026-7054-como-conquistei-minha-aws-cloud-practitioner-e-o-metodo-para-voce-passar-na-sua /media/devopsdays-juiz-de-fora-2026/submissions/K38QGM/image_7e8HZFs.webp Marlene Laysa de Aguiar pt-br false https://talks.devopsdays.org/devopsdays-juiz-de-fora-2026/talk/K38QGM/ Auditório Talk 2026-10-17T10:40:00-03:00 10:40 00:30 Platform Engineering propõe dar autonomia ao desenvolvedor sem sacrificar governança. Nesta palestra, mostro como construímos uma Internal Developer Platform usando KubeVela e o modelo OAM sobre Kubernetes, encapsulando workloads complexos (SQS workers, cron jobs, webservices com IRSA e autoscaling) em templates CUE reutilizáveis que o dev consome via YAML declarativo e GitOps. Trago o caminho prático, as decisões de design e as armadilhas reais de operar essa plataforma em produção. devopsdays-juiz-de-fora-2026-7061-platform-engineering-na-pratica-primeiros-passos-na-construcao-de-uma-internal-developer-platform-com-kubevela Anna Luiza Laudares Alves Pimenta Silva pt-br 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. false https://talks.devopsdays.org/devopsdays-juiz-de-fora-2026/talk/MKZTMK/ Auditório Talk 2026-10-17T11:10:00-03:00 11:10 00:30 Reduzir custos em cloud não significa apenas desligar recursos ou escolher instâncias mais baratas. FinOps aproxima engenharia, operações e negócio para transformar custos em uma dimensão técnica das decisões sobre infraestrutura. Nesta talk, vamos explorar como aplicar FinOps na prática utilizando IA, automação e ferramentas open source para identificar desperdícios, analisar custos, encontrar oportunidades de otimização e apoiar decisões técnicas. A proposta é mostrar como transformar dados de consumo em ações concretas, integrando controle de custos ao dia a dia das equipes de DevOps. devopsdays-juiz-de-fora-2026-7121-finops-com-ia-e-open-source-na-pratica Jairo Coelho pt-br 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. false https://talks.devopsdays.org/devopsdays-juiz-de-fora-2026/talk/JQ3VRH/ Auditório Talk 2026-10-17T11:40:00-03:00 11:40 00:30 Disaster Recovery em Kubernetes ainda é um dos temas mais negligenciados por times de plataforma e SRE. Muitos ambientes produtivos não têm uma estratégia clara de backup — e quando algo dá errado, o custo é alto. Nesta palestra vamos explorar como o Velero, ferramenta open source da VMware para backup e restore de clusters Kubernetes, se integra com o RustFS — um object storage compatível com S3, escrito em Rust, com alta performance e 100% open source. devopsdays-juiz-de-fora-2026-6977-velero-rustfs-backup-open-source-para-clusters-kubernetes Emerson Silva pt-br false https://talks.devopsdays.org/devopsdays-juiz-de-fora-2026/talk/7G9RAH/ Auditório Talk 2026-10-17T14:00:00-03:00 14:00 00:30 E se tudo que construímos em engenharia pudesse ser tratado como um produto? Um pipeline de CI/CD, uma plataforma interna, uma solução de observabilidade ou até mesmo uma API possuem usuários, problemas a resolver, custos, métricas e valor a entregar. Vamos explorar como a mentalidade de produto pode transformar a forma como engenheiros de software enxergam e constroem essas soluções. Vamos discutir como definir métricas de valor, entender SLAs e SLOs, avaliar impacto, conhecer os usuários das nossas soluções internas e transformar práticas de DevOps em produtos que geram resultados reais. A proposta é ir além da ideia de simplesmente “entregar software” do deploy à observabilidade, da pipeline à plataforma, cada solução pode fazer parte de um ciclo contínuo de descoberta, entrega, medição e aprendizado. devopsdays-juiz-de-fora-2026-7120-do-deploy-ao-impacto-engenharia-com-mentalidade-de-produto Brendo Freitas pt-br false https://talks.devopsdays.org/devopsdays-juiz-de-fora-2026/talk/BSHYXU/ Auditório Talk 2026-10-17T14:30:00-03:00 14:30 00:30 Era um cluster OpenSearch saudável. Até que não era mais. Dois índices netflow chegaram a 876GB sem nenhuma política de retenção. O flood stage disparou, o cluster entrou em read-only e a produção parou. Conto o incidente completo: como identificamos o problema, removemos o bloqueio, corrigimos o alias is_write_index, implementamos ISM com retenção de 60 dias e corrigimos o Data Prepper para injetar @timestamp e sem isso a deleção por data não funcionava. Voltamos em menos de duas horas. Mas o ponto que importa: se esse volume fosse de traces de LLMs e agentes de IA, o colapso teria chegado muito antes. Se você opera observabilidade ou está prestes a monitorar IA em produção, essa palestra é devopsdays-juiz-de-fora-2026-7076-876gb-flood-stage-producao-parada-o-que-esse-incidente-ensina-sobre-observabilidade-de-ia Jeovany Batista da Silva pt-br 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. false https://talks.devopsdays.org/devopsdays-juiz-de-fora-2026/talk/NM9SNQ/ Auditório Talk 2026-10-17T16:30:00-03:00 16:30 00:30 Uma aplicação está no ar. Mas por onde o tráfego entra? Quem termina o TLS? A aplicação fica exposta diretamente? Quando surge uma segunda instância, quem distribui as requisições? E, quando os usuários estão espalhados pelo mundo ou aparecem dezenas de serviços, quando faz sentido colocar uma CDN, um API Gateway ou até um service mesh na arquitetura? A proposta desta talk é olhar para essas tecnologias a partir de uma ideia simples: o proxy reverso é a base; o restante é especialização. Load balancer, CDN e API Gateway continuam sendo proxies reversos na mecânica. O que muda é a responsabilidade que cada um acrescenta: distribuição de carga, distribuição geográfica, políticas de API e, no caso do service mesh, a mesma ideia aplicada ao tráfego entre serviços. A talk acompanha uma aplicação crescendo e mostra esses componentes entrando conforme surgem problemas concretos: uma instância que não aguenta mais, usuários distantes, necessidade de autenticação e rate limiting, ou dezenas de serviços conversando entre si. Em vez de decorar ferramentas, a ideia é sair entendendo qual problema cada camada resolve e quais são os sinais de que chegou a hora de evoluir, ou de que ainda não chegou. Os conceitos são apresentados com diagramas animados, mostrando o tráfego acontecendo e as responsabilidades sendo adicionadas à arquitetura. devopsdays-juiz-de-fora-2026-7112-proxy-reverso-a-camada-de-borda-e-a-hora-de-evoluir /media/devopsdays-juiz-de-fora-2026/submissions/7X3JSG/image_IzpPFKs.webp Pablo Rezende pt-br É 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?" false https://talks.devopsdays.org/devopsdays-juiz-de-fora-2026/talk/7X3JSG/