The DevSecOps Talks Podcast

This episode with Joachim Hill-Grannec asks: How do platforms bloat, and how do you keep them simple and fast with trunk-based dev and small batches? Which metrics prove it works—cycle time, uptime, or developer experience? Can security act as a partner that speeds delivery instead of a gate? We are always happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners. DevSecOps Talks podcast LinkedIn page DevSecOps Talks podcast website DevSecOps Talks podcast YouTube channel Summary In this episode of DevSecOps Talks, Mattias speaks with Joachim Hill-Grannec, co-founder of Peltek, a boutique consulting firm specializing in high-availability, cloud-native infrastructure. Following up on a previous episode where Steve discussed cleaning up bloated platforms, Mattias and Joachim dig into why platforms get bloated in the first place and how platform teams should think when building from scratch. Their conversation spans cloud provider preferences, the primacy of cycle time, the danger of adding process in response to failure, and a strong argument for treating security and quality as enablers rather than gatekeepers. Key Topics Platform Teams Should Serve Delivery Teams Joachim frames the core question of platform engineering around who the platform is actually for. His answer is clear: the delivery teams are the client. Platform engineers should focus on making it easier for developers to ship products, not on making their own work more convenient. He connects this directly to platform bloat. In his experience, many platforms grow uncontrollably because platform engineers keep adding tools that help the platform team itself: "Look, I spent this week to make my job this much faster." But Joachim pushes back on this instinct — the platform team is an amplifier for the organization, and every addition should be evaluated by whether it helps a product get to production faster and gives developers better visibility into what they are working on. Choosing a Cloud Provider: Preferences vs. Reality The conversation briefly explores cloud provider choices. Joachim says GCP is his personal favorite from a developer perspective because of cleaner APIs and faster response times, though he acknowledges Google's tendency to discontinue services unexpectedly. He describes AWS as the market workhorse — mature, solid, and widely adopted, comparing it to "the Java of the land." Azure gets the coldest reception; both acknowledge it has improved over time, but Joachim says he still struggles whenever he is forced to use it. They observe that cloud choices are frequently made outside engineering. Finance teams, investors, and existing enterprise agreements often drive the decision more than technical fit. Joachim notes a common pairing: organizations using Google Workspace for productivity but AWS for cloud infrastructure, partly because the Entra ID (formerly Azure AD) integration with AWS Identity Center works more smoothly via SCIM than the equivalent Google Workspace setup, which requires a Lambda function to sync groups. Measuring Platform Success: Cycle Time Above All When Mattias asks how a team can tell whether a platform is actually successful, Joachim separates subjective and objective measures. On the subjective side, he points to developer happiness and developer experience (DX). Feedback from delivery teams matters, even if surveys are imperfect. On the objective side, his favorite metric is cycle time — specifically, the time from when code is ready to when it reaches production. He also mentions uptime and availability, but keeps returning to cycle time as the clearest indicator that a platform is helping teams deliver faster. This aligns with DORA research, which has consistently shown that deployment frequency and lead time for changes are strong predictors of overall software delivery performance. Start With a Highway to Production A major theme of the episode is that platforms should begin with the shortest possible route to production. Mattias calls this a "highway to production," and Joachim strongly agrees. For greenfield projects, Joachim favors extremely fast delivery at first — commit goes to production, commit goes to production — even with minimal process. As usage and risk increase, teams can gradually add automation, testing, and safeguards. The critical thing is to keep the flow and then ask "how do we make those steps faster?" as you add them, rather than letting each new step slow down the pipeline unchallenged. He also makes a strong case for tags and promotions over branch-based deployment, noting his instinctive reaction when someone asks "which branch are we deploying from?" is: "No branches — tags and promotions." The Trap of Slowing Down After Failure Joachim warns about a common and dangerous pattern: when a bug reaches production, the natural organizational reaction is not to fix the pipeline, but to add gates. A QA team does a full pass, a security audit

Is your Kubernetes stack bloated, slow, and hard to explain? Steve Wade shares simple checks—the hiring treadmill, onboarding time, and the acronym test—to spot platform theater fast. What would a 30-day deletion sprint cut, save, and secure? We are always happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners. DevSecOps Talks podcast LinkedIn page DevSecOps Talks podcast website DevSecOps Talks podcast YouTube channel Summary In this episode of DevSecOps Talks, Mattias and Paulina speak with Steve Wade, founder of Platform Fix, about why so many Kubernetes and platform initiatives become overcomplicated, expensive, and painful for developers. Steve has helped simplify over 50 cloud-native platforms and estimates he has removed around $100 million in complexity waste. The conversation covers how to spot a bloated platform, why "free" tools are never really free, how to systematically delete what you don't need, and why the best platform engineering is often about subtraction rather than addition. Key Topics Steve's Background: From Complexity Creator to Strategic Deleter Steve introduces himself as the founder of Platform Fix — the person companies call when their Kubernetes migration is 18 months in, millions over budget, and their best engineers are leaving. He has done this over 50 times, and he is candid about why it matters so much to him: he used to be this problem. Years ago, Steve led a migration that was supposed to take six months. Eighteen months later, the team had 70 microservices, three service meshes (they kept starting new ones without finishing the old), and monitoring tools that needed their own monitoring. Two senior engineers quit. The VP of Engineering gave Steve 90 days or the team would be replaced. Those 90 days changed everything. The team deleted roughly 50 of the 70 services, ripped out all the service meshes, and cut deployment time from three weeks of chaos to three days, consistently. Six months later, one of the engineers who had left came back. That experience became the foundation for Platform Fix. As Steve puts it: "While everyone's collecting cloud native tools like Pokemon cards, I'm trying to help teams figure out which ones to throw away and which ones to keep." Why Platform Complexity Happens Steve explains that organizations fall into a complexity trap by continuously adding tools without questioning whether they are actually needed. He describes walking into companies where the platform team spends 65–70% of their time explaining their own platform to the people using it. His verdict: "That's not a team, that's a help desk with infrastructure access." People inside the complexity normalize it. They cannot see the problem because they have been living in it for months or years. Steve identifies several drivers: conference-fueled recency bias (someone sees a shiny tool at KubeCon and adopts it without evaluating the need), resume-driven architecture (engineers choosing tools to pad their CVs), and a culture where everyone is trained to add but nobody asks "what if we remove something instead?" He illustrates the resume-driven pattern with a story from a 200-person fintech. A senior hire — "Mark" — proposed a full stack: Kubernetes, Istio, Argo, Crossplane, Backstage, Vault, Prometheus, Loki, Tempo, and more. The CTO approved it because "Spotify uses it, so it must be best practice." Eighteen months and $2.3 million later, six engineers were needed just to keep it running, developers waited weeks to deploy, and Mark left — with "led Kubernetes migration" on his CV. When Steve asked what Istio was actually solving, nobody could answer. It was costing around $250,000 to run, for a problem that could have been fixed with network policies. He also highlights a telling sign: he asked three people in the same company how many Kubernetes clusters they needed and got three completely different answers. "That's not a technical disagreement. That's a sign that nobody's aligned on what the platform is actually for." The AI Layer: Tool Fatigue Gets Worse Paulina observes that the same tool-sprawl pattern is now being repeated with AI tooling — an additional layer of fatigue on top of what already exists in the cloud-native space. Steve agrees and adds three dimensions to the AI complexity problem: choosing which LLM to use, learning how to write effective prompts, and figuring out who is accountable when AI-written code does not work as expected. Mattias notes that AI also enables anyone to build custom tools for their specific needs, which further expands the toolbox and potential for sprawl. How Leaders Can Spot a Bloated Platform One of the most practical segments is Steve's framework for helping leaders who are not hands-on with engineering identify platform bloat. He gives them three things to watch for: The hiring treadmill: headcount keeps growing but shipping speed stays flat, because all new capacity is absorbed by maintenance. Th

We bring Paul Stack back to cover the parts we skipped last time. What changed when the models got better and we moved from one-shot Gen AI to agentic, human-in-the-loop work? How do plan mode and tight prompts stop AI from going rogue? Want to hear how six branches, git worktrees, and a TypeScript CLI came together? We are always happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners. DevSecOps Talks podcast LinkedIn page DevSecOps Talks podcast website DevSecOps Talks podcast YouTube channel Summary In this episode, Mattias, Andre, and Paulina welcome back returning guest Paul from System Initiative to continue a conversation that started in the previous episode about their project Swamp. The discussion digs into how AI-assisted software development has changed over the past year, and why the real shift is not "AI writes code" but humans orchestrating multiple specialized agents with strong guardrails. Paul walks through the practical workflows, multi-layered testing, architecture-first thinking, cost discipline, and security practices his team has adopted — while the hosts push on how this applies across enterprise environments, mentoring newcomers, and the uncomfortable question of who is responsible when AI-built software fails. Key Topics The industry crossroads: layoffs, fear, and a new reality Before diving into technical specifics, Paul acknowledges that the industry is at "a real crazy crossroads." He references Block (formerly Square) cutting roughly 40% of their workforce, citing uncertainty about what AI means for their teams. He wants to be transparent that System Initiative also shrank — but clarifies the company did not cut people because of AI. The decision to reduce headcount came before they even knew what they were going to build next, let alone how they would build it. AI entered the picture only after they started prototyping the next version of their product. Block's February 2026 layoffs, announced by CEO Jack Dorsey, eliminated over 4,000 positions. The move was framed as an AI-driven restructuring, making it one of the most visible examples of AI anxiety playing out in real corporate decisions. From GenAI hype to agentic collaboration Paul explains that AI coding quality shifted significantly around October–November of the previous year. Before that, results were inconsistent — sometimes impressive, often garbage. Then the models improved dramatically in both reasoning and code generation. But the bigger breakthrough, in his view, was not the models themselves. It was the industry's shift from "Gen AI" — one-shot prompting where you hand over a spec and accept whatever comes back — to agentic AI, where the model acts more like a pair programmer. In that setup, the human stays in the loop, challenges the plan, adds constraints, and steers the result toward something that fits the codebase. He gives a concrete early example: System Initiative had a CLI written in Deno (a TypeScript runtime). Because the models were well-trained on TypeScript libraries and the Deno ecosystem, they started producing decent code. Not beautiful, not perfectly architected — but functional. When Paul began feeding the agent patterns, conventions, and existing code to follow, the output became coherent with their codebase. This led to a workflow where Paul would open six Claude Code sessions at once in separate Git worktrees — isolated copies of the repository on different branches — each building a small feature in parallel, feeding them bug reports and data, and continuously interacting with the results rather than one-shotting them. Git worktrees let you check out multiple branches of the same repository simultaneously in separate directories. Each worktree is independent, so you can work on several features at once and merge them back via pull requests. He later expanded this by running longer tasks on a Mac Mini accessible via Tailscale (a mesh VPN), while handling shorter tasks on his laptop — effectively distributing AI workloads across machines. Why architecture matters more than ever One of Paul's strongest themes is that AI shifts engineering attention away from syntax and back toward architecture. He argues that AI can generate plenty of code, but without design principles and boundaries it will produce spaghetti on top of existing spaghetti. He introduces the idea of "the first thousand lines" — an anecdote he read recently claiming that the first thousand lines of code an agent helps write determine its path forward. If those lines are well-structured and follow clear design principles, the agent will build coherently on top of them. If they are messy and unprincipled, everything after will compound the mess. Paul breaks software development into three layers: Architecture — design patterns like DDD (Domain-Driven Design), CQRS (Command Query Responsibility Segregation) Patterns — principles like DRY (Don't Repeat Yourself), YAGNI (You Aren't Gonna Nee

Andrey and Mattias share a fast re:Invent roundup focused on AWS security. What do VPC Encryption Controls, post-quantum TLS, and org-level S3 block public access change for you? Which features should you switch on now, like ECR image signing, JWT checks at ALB, and air-gapped AWS Backup? Want simple wins you can use today? We are always happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners. DevSecOps Talks podcast LinkedIn page DevSecOps Talks podcast website DevSecOps Talks podcast YouTube channel Summary In this episode, Andrey and Mattias deliver a security-heavy recap of AWS re:Invent 2025 announcements, while noting that Paulina is absent and wishing her a speedy recovery. Out of the 500+ releases surrounding re:Invent, they narrow the list down to roughly 20 features that security-conscious teams can act on today — covering encryption, access control, detection, backups, container security, and organization-wide guardrails. Along the way, Andrey reveals a new AI-powered product called Boris that watches the AWS release firehose so you don't have to. Key Topics AWS re:Invent Through a Security Lens The hosts frame the episode as the DevSecOps Talks version of a re:Invent recap, complementing a FivexL webinar held the previous month. Despite the podcast's name covering development, security, and operations, the selected announcements lean heavily toward security. Andrey is upfront about it: if security is your thing, stay tuned; otherwise, manage your expectations. At the FivexL webinar, attendees were asked to prioritize areas of interest across compute, security, and networking. AI dominated the conversation, and people were also curious about Amazon S3 Vectors — a new S3 storage class purpose-built for vector embeddings used in RAG (Retrieval-Augmented Generation) architectures that power LLM applications. It is cost-efficient but lacks hybrid search at this stage. VPC Encryption and Post-Quantum Readiness One of the first and most praised announcements is VPC Encryption Control for Amazon VPC, a pre-re:Invent release that lets teams audit and enforce encryption in transit within and across VPCs. The hosts highlight how painful it used to be to verify internal traffic encryption — typically requiring traffic mirroring, spinning up instances, and inspecting packets with tools like Wireshark. This feature offers two modes: monitor mode to audit encryption status via VPC flow logs, and enforce mode to block unencrypted resources from attaching to the VPC. Mattias adds that compliance expectations are expanding. It used to be enough to encrypt traffic over public endpoints, but the bar is moving toward encryption everywhere, including inside the VPC. The hosts also call out a common pattern: offloading SSL at the load balancer and leaving traffic to targets unencrypted. VPC encryption control helps catch exactly this kind of blind spot. The discussion then shifts to post-quantum cryptography (PQC) support rolling out across AWS services including S3, ALB, NLB, AWS Private CA, KMS, ACM, and Secrets Manager. AWS now supports ML-KEM (Module Lattice-Based Key Encapsulation Mechanism), a NIST-standardized post-quantum algorithm, along with ML-DSA (Module Lattice-Based Digital Signature Algorithm) for Private CA certificates. The rationale: state-level actors are already recording encrypted traffic today in a "harvest now, decrypt later" strategy, betting that future quantum computers will crack current encryption. Andrey notes that operational quantum computing feels closer than ever, making it worthwhile to enable post-quantum protections now — especially for sensitive data traversing public networks. S3 Security Controls and Access Management Several S3-related updates stand out. Attribute-Based Access Control (ABAC) for S3 allows access decisions based on resource tags rather than only enumerating specific actions in policies. This is a powerful way to scope permissions — for example, granting access to all buckets tagged with a specific project — though it must be enabled on a per-bucket basis, which the hosts note is a drawback even if necessary to avoid breaking existing security models. The bigger crowd-pleaser is S3 Block Public Access at the organization level. Previously available at the bucket and account level, this control can now be applied across an entire AWS Organization. The hosts call it well overdue and present it as the ultimate "turn it on and forget it" control: in 2026, there is no good reason to have a public S3 bucket. Container Image Signing Amazon ECR Managed Image Signing is a welcome addition. ECR now provides a managed service for signing container images, leveraging AWS Signer for key management and certificate lifecycle. Once configured with a signing rule, ECR automatically signs images as they are pushed. This eliminates the operational overhead of setting up and maintaining container image signing infrastructure — previously a si

What can you automate with SWAMP today, from AWS to a Proxmox home lab? How do skills, scripts, and reusable workflows plug into your stack? Could this be your agent’s missing guardrails? We are always happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners. DevSecOps Talks podcast LinkedIn page DevSecOps Talks podcast website DevSecOps Talks podcast YouTube channel Summary System Initiative has undergone a dramatic transformation: from a visual SaaS infrastructure platform with 17 employees to Swamp, a fully open-source CLI built for AI agents, maintained by a five-person team whose initials literally spell the product name. Paul Stack returns for his third appearance on the show to explain why the old model failed — and why handing an AI agent raw CLI access to your cloud is, as Andrey puts it, just "console-clicking in the terminal." The conversation gets sharp when the hosts push on what problem Swamp actually solves, whether ops teams are becoming the next bottleneck in AI-era delivery, and why Paul believes the right move is not replacing Terraform but giving AI a structured system it can reason about. Paul also drops a parting bombshell: he hasn't written a single line of code in four weeks. Key Topics System Initiative's pivot from visual editor to AI-first CLI Paul Stack explains that System Initiative spent over five years iterating on a visual infrastructure tool where users could drag, drop, and connect systems. Despite the ambition, the team eventually concluded that visual composition was too slow, too cumbersome, and too alien for practitioners accustomed to code, artifacts, and reviewable changes. The shift started in summer 2025 when Paul spiked a public OpenAPI-spec API. A customer then built an early MCP (Model Context Protocol) server on top of it — a prototype that worked but had no thought given to token usage or tool abstraction. System Initiative responded by building its own official MCP server and pairing it with a CLI. The results were dramatically better: customers could iterate easily from the command line or through AI coding tools like Claude Code. By Christmas 2025 the writing was on the wall. The CLI-plus-agent approach was producing better outcomes, while the company was still carrying hundreds of thousands of lines of code for a distributed SaaS platform built for a previous product direction. In mid-January 2026, the company made the call to rethink everything from first principles. The team behind the name The restructuring was painful. System Initiative went from 17 people to five. Paul explains the reasoning candidly: when you don't know what the tool is going to be, keeping a large team around is unfair to them, bad for their careers, and expensive. The five who stayed were the CEO, VP of Business, COO, Paul (who ran product), and Nick Steinmetz, the head of infrastructure — who also happened to be System Initiative's most active internal user, having used the platform to build System Initiative itself. Those five people's initials spell SWAMP. The name was unintentional but stuck — and Paul notes with a grin that if they ever remove the "P," it becomes "SWAM," so he's safe even if he leaves. Beyond the joke, the name fits: Swamp stores operational data in a local .swamp/ directory — not a neatly formatted data lake, but a structured store that AI agents can pull from to reason about infrastructure state and history. Why raw AI agent access to infrastructure is dangerous A major theme in the conversation is that letting an AI agent operate infrastructure directly — through the AWS CLI or raw API calls — is fundamentally unreliable. Andrey lays out the problem clearly: this kind of interaction is equivalent to clicking around the cloud console, just automated through a terminal. It is not repeatable, not reviewable, and inherits the non-deterministic behavior of LLMs. If the agent's context window fills up, it starts to forget earlier decisions and improvises — a terrifying prospect for production infrastructure. What made System Initiative's earlier MCP-based direction compelling, in Andrey's view, was the combination of guardrails, repeatability, and human review. The agent generates a structured specification, a human reviews it, and only then is it applied. Paul agrees and calls this the "agentic loop with the human loop" — the strongest pattern they found. Token costs and the case for local-first architecture Paul shares a hard-won lesson from building MCP integrations: a poorly designed MCP server burns enormous amounts of tokens and creates unnecessary costs for users. He spent three weeks in December reworking the server to use progressive context reveal rather than flooding the model with data. Even so, the fundamental problem with a SaaS-first architecture remained — constantly transmitting context between a central API and the user's agent was expensive regardless of optimization. That experience pushed the team towa

We kick off with a CVSS 10 in n8n, then look at self-hosted AI assistants with weak defaults and prompt injection risks. Are your API keys, inbox, and drives safe if a bot is open to the web? What should you rotate, patch, and hide behind a VPN? We are always happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners. DevSecOps Talks podcast LinkedIn page DevSecOps Talks podcast website DevSecOps Talks podcast YouTube channel

We get into K8s vs native orchestrators. Do you still need Kubernetes when managed services cover most needs? How do cost, lock-in, and team skills change the choice? Expect a heated debate. We are always happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners. DevSecOps Talks podcast LinkedIn page DevSecOps Talks podcast website DevSecOps Talks podcast YouTube channel

Are devs ignoring AI, misusing it, or getting real value? What happens when agents touch your env vars, repos, and pipelines? How do you share prompts, set team defaults, and keep trust? Could an AI engineer role lead culture as well as tools? We are always happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners. DevSecOps Talks podcast LinkedIn page DevSecOps Talks podcast website DevSecOps Talks podcast YouTube channel

Which parts of AI Act, NIS2, DORA, and DSA overlap so you can cover more with less? What basics raise your baseline fast: central logs, backups, risk assessments, and human-in-the-loop governance? Could a simple mailing list make incident comms painless? We are always happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners. DevSecOps Talks podcast LinkedIn page DevSecOps Talks podcast website DevSecOps Talks podcast YouTube channel

Want a quick map of EU compliance for engineers? How do you classify AI by risk and tell users when AI is used? When do you send a 24-hour heads-up and a one-month report after an incident? Does NIS2 make your board liable and your logs mandatory? We are always happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners. DevSecOps Talks podcast LinkedIn page DevSecOps Talks podcast website DevSecOps Talks podcast YouTube channel

Is MCP just another server you need to threat model, patch, and monitor? How do you keep users from over-privileged access, block LLM injection, and stop blind spots? We unpack the VentureBeat article https://venturebeat.com/security/mcp-stacks-have-a-92-exploit-probability-how-10-plugins-became-enterprise with real-world tips. We are always happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners. DevSecOps Talks podcast LinkedIn page DevSecOps Talks podcast website DevSecOps Talks podcast YouTube channel

We break down 10 years of HashiConf and this year's Terraform-heavy news. What do Terraform Actions with Ansible, Stacks GA, and HCP-only features mean for day two work? Is open source getting left behind, and is OpenTofu worth a look? We are always happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners. DevSecOps Talks podcast LinkedIn page DevSecOps Talks podcast website DevSecOps Talks podcast YouTube channel

Can AI really help us build more secure software? What’s working in practice right now, and where do the tools still fall short? Mattias and Paulina share their views. We are always happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners. DevSecOps Talks podcast LinkedIn page DevSecOps Talks podcast website DevSecOps Talks podcast YouTube channel

It’s been a while since OpenTofu was released to the public, so we wanted to check in on where it stands today. How is the community adopting it? What’s the public sentiment? And how does it differ from Terraform in terms of features? This time we’re joined by Cole Bittel, an experienced SRE, platform engineer, and contributor to OpenTofu. He shares his hands-on experience migrating to OpenTofu, and we look into the problems teams face with infrastructure as code and how both Terraform and OpenTofu approach solving them. We are always happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners. DevSecOps Talks podcast LinkedIn page DevSecOps Talks podcast website DevSecOps Talks podcast YouTube channel

This time we talk about how LLMs use tools and what the Model Context Protocol (MCP) brings to the table. What are the risks? How can an attacker exploit MCPs? And why are LLMs a bit like grandpas — helpful but forgetful? We are always happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners. DevSecOps Talks podcast LinkedIn page DevSecOps Talks podcast website DevSecOps Talks podcast YouTube channel

Still pasting tokens into Slack? What types of secrets are at risk, and which tools fit which consumer—humans, CI/CD, or workloads? Where do most teams stumble, and how do you fix it fast? Hear our no-nonsense checklist. Connect with us on LinkedIn or X (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners. The video version of this episode is available on our YouTube channel LinkedIn page of the DevSecOps Talks team is here

Passkeys are gaining attention as a new way to log in without passwords. How do they work, and how do they compare to traditional multi-factor authentication (MFA)? In this episode, we explore the history of passwords, the strengths and weaknesses of common MFA methods, and the potential of passkeys to enhance security. What threats do passkeys mitigate, and what still remain? Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

Andrey, Paulina, and Mattias kick off a miniseries on European infrastructure. We talk about infrastructure providers' options across Europe, ask what really drives the move away from hyperscalers, and wonder whether the trade-offs make sense for most teams. Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

In this guest episode, we chat with Davlet Dzhakishev, co-founder of Cloudgeni, who’s working on an AI-powered approach to fixing compliance issues in IaC. What’s the state of tools in this space? Where does his idea fit in? And how should we think about the relationship between compliance and security? Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

Part two of our chaos engineering series is here! Join Andrey, Mattias, and Paulina as they talk through practical strategies for chaos engineering. Who should do it? How can you start? And what are the essential prerequisites? Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

Chaos engineering—is it really chaos, or something more structured? Andrey, Paulina, and Mattias talk about what chaos engineering means, how it started, and why you might already be using it unintentionally. Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

This is the final episode of our three-part series on incident response. We focus on what happens after the dust settles. How do you learn from what went wrong and avoid repeating it? Tune in to hear our top recommendations. Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

What keeps an incident from spiraling out of control? How can you organize your team on the spot? We continue our series on incident response, moving from preparation to real-time actions. Mattias shares key points from his course. Listen to learn how we handle incidents step by step. Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

Incident response can be complex, but where do you start? Andrey, Mattias, and Paulina dive into the preparation steps you need to take. Mattias shares his expertise from teaching an incident response course. What’s their top recommendation? Listen and find out! Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

We are looking into recently announced AWS Resource Control Policies. What are they? How are they different from Service Control Policies? What is a Data Perimeter? Tune in to find out! Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

In this episode, Andrey, Mattias, and Paulina break down the new DORA Accelerate State of DevOps report. What’s changed since the last report? What do these insights mean for your team? Tune in for our insightful conversation! Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

Andrey, Mattias, and Paulina are joined by Paul Stack, an IaC tools developer and a frequent guest on the show. He’s back to discuss the general availability of System Initiative and share what has changed since his last visit when they talked about the early beta of the tool. Will this be a revolution or evolution in Infrastructure as Code tooling? Do we really need collaborative infrastructure management tools? Tune in to find out! Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

Join Andrey and Mattias as they sit down with Paulina Dubas, an independent DevOps consultant and public speaker. Who is Paulina, and what experiences does she bring to the table? What topics particularly resonate with her? Tune in to learn more about Paulina since we have a feeling that she is here to stay Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

Julien shares big news with co-hosts Mattias and Andrey. What led to his decision to step down? And what does the future hold for him? Tune in for the off-boarding interview as we look back at the past four years and 60+ episodes we did together! Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

Join Andrey, Julien, and Mattias in this episode of DevSecOps Talks as they delve into building Minimum Viable Products (MVPs) and selecting the best solutions for them. Andrey goes first and, as an AWS consultant, kicks off the discussion by outlining his preferred AWS services for MVP development. Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

In this episode of DevSecOps Talks, co-hosts Andrey, Julien, and Mattias are joined by AWS Consultant Fernando Gonçalves to explore the complexities of AWS organization and account segmentation. Get insights into the debate over development, stage, and production accounts versus micro-segmentation. Don’t miss Julien's take on why he believes staging is a waste of time and money, as well as Fernando’s explanation of what the AWS Landing Zone is. Learn about the tools provided by AWS for multi-account management and the pros and cons of various account segmentation approaches. Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

Join Andrey, Julien, and Mattias in this episode of DevSecOps Talks as they discuss Nats.io, a messaging system popular among people building on top of Kubernetes. Julien explains how Nats is different from Kafka and shares his personal experience with the product. The hosts discuss the various use cases of Nats and explore its features and capabilities. Tune in to find out if Nats is the right messaging system for you! Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

In this episode of DevSecOps Talks, Andrey and Mattias are joined by Timur Bublik, Platform Engineering Lead at TIER Mobility. As always, it's practitioners for practitioners as they discuss the migration from Terraform to OpenTofu, TACOS tools, and how SpaceLift is used in Timur's organization. Listen in as they dive into their three favorite features of SpaceLift and how TACOS tools like SpaceLift fit into the classic CI/CD pipeline. Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

Julien has returned with some exciting AI news. A startup has made the bold claim that they are capable of building AI software engineer. Andrey shares details about another startup that generates infrastructure based on application source code. He also mentions his upcoming talk on the use of LLM-based tools. We also discuss how individuals can stay ahead of the curve and be prepared for changes in their work life. Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

In this episode of DevSecOps Talks, Andrey and Mattias discuss the latest announcements from re:Invent 2023 that are most relevant to DevSecOps practitioners. Which announcements are worth paying attention to? What are the implications for the DevSecOps community? Join us as we dive into the latest developments from AWS. Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

Andrey has been exploring GitHub Actions and has some insights to share. How have CI/CD solutions transformed over time, and what innovations do GitHub Actions bring to the table? Julien drops a few tools that could be useful for GitHub Actions users. Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

Welcome to the first DevSecOps Talks episode of the new year! It's been a whole year since ChatGPT hit the scene – but how has AI adoption shaped our world since then? Join Julien, Mattias, and Andrey as they dive into the impact of AI on their workflows. How have their daily tech tools and practices evolved with AI integration? Plus, Julien gives us an insider's look at running models locally. Are these AI tools enhancing our efficiency? Tune in to find out how these advancements are reshaping the landscape of DevSecOps. Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

Is the grass greener outside the cloud? This episode dives into the trend of companies (notably Hey and Dropbox) migrating away from cloud services. Why are they leaving, and who would benefit from such a move? We also scrutinize the common belief that public clouds are overly expensive. Join us as we dissect various cloud cost optimization tools and techniques. Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

You know our fondness for Terraform, but we are also open to exploring other tools. This episode is no different. We are joined by Igor Soroka, an expert in AWS serverless technology whose tool of choice is AWS CDK, but at the same time, he is no stranger to Terraform. We ask him practical questions about the tool and get answers based on his experience applying it to real-life projects. If you have been curious about CDK, how it functions, and if it's appropriate for you, then tune in to learn more. Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

In this episode, Mattias is joined by Ben Goodman, the founder of dragondrop.cloud, a platform that offers Terraform Best Practices as a Pull Request. They discuss the best workflows for Terraform, open-source tools that can be used in conjunction with Terraform, the most effective best practices, and common pitfalls to avoid when implementing infrastructure as code using Terraform. Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

In this episode of DevSecOps Talks, join Andrey, Julien, and Mattias as they dive into the world of Backstage, the notable internal development platform. Mattias is keen to peel back the layers and understand what makes people think of Backstage as a must-have in modern DevOps toolchains. Andrey highlights the platform's core feature: a comprehensive registry that keeps track of every software service running within a company. Could this signify a revival of IT change management, but with a twist? We've moved on from the days of cumbersome ticketing systems to streamlined internal development platforms. The team also ponders the future role of infrastructure engineers as they navigate the rising tides of AI—will AI become the new face behind these developer portals? Tune in to find out! Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

Our dialogue with Paul Stack resumes on DevSecOps Talks, almost two years after our initial podcast about his work on Pulumi (episode 25). As a warm-up, we talk about what prompted his move from Pulumi and his take on Open Terraform drama. The main topic of the episode is Paul's current focus, System Initiative; we probe into its purpose, the progress so far, and the promise it holds for redefining how we think of doing Infrastructure as Code and DevSecOps workflows in general. Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes, or hear from you, our listeners.

In this episode of DevSecOps Talks, we dive deep into HashiCorp's recent shift to the Business Source License and its implications. Join Andrey, Julien, and Mattias as they unpack what this means for practitioners and explore the timeline of OpenTF initiative. Stay informed about what comes ahead with our latest discussion. Tune in! Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes or hear from you, our listeners.

We had the opportunity to talk with Neatsun Ziv, one of the founders of Ox Security, about the Open Source Software Supply Chain Attack Reference Framework (https://pbom.dev). We delved deeper into possible attack vectors and explored ways to mitigate some of them. During our discussions, we also had a couple of unusual takes on supply chain security. If you are looking to understand the Open Source Software Supply Chain, then this episode is perfect for you. Connect with us on LinkedIn or Twitter (see info at https://devsecops.fm/about/). We are happy to answer any questions, hear suggestions for new episodes or hear from you, our listeners.