🔥 Top Story
How Mapfre USA modernized fraud claims with Amazon EMR Serverless
AWS published a case study on how Mapfre USA -- the No. 1 auto and home insurer in Massachusetts, operating across 11 US states as part of the global Mapfre Group -- modernized its fraud detection using Amazon EMR Serverless together with AWS and Neo4j. The initiative combines graph-derived features with machine learning models, starting with Massachusetts auto insurance and later expanding to home insurance, delivering more than $5 million in net present value with realized savings beating projections. The solution runs on Mapfre's in-house "Atenea" data platform, using Apache Iceberg tables on Amazon S3 organized into Silver, Gold, and Platinum layers, governed through AWS Glue Data Catalog and AWS Lake Formation. Processing pipelines run on Amazon EMR Serverless orchestrated with Amazon MWAA, while a Neo4j graph database supplies network-based features such as suspicious claim linkages and provider-centrality metrics. Fraud scores are pushed into the Guidewire Claims system via an S3-triggered Lambda function that calls Guidewire's API one claim at a time, with retries, an SQS dead-letter queue, and SNS alerts handling failures, and credentials managed through AWS Secrets Manager. The result was a 50-135% improvement in fraud detection accuracy over baseline methods, plus faster fraud-ring identification for investigators using Neo4j Bloom visualizations.
💡 Why it matters: For cloud/DevOps engineers, this is a solid reference architecture for pairing EMR Serverless, Iceberg, and MWAA for elastic batch/near-real-time scoring while using Lambda, an SQS DLQ, and Secrets Manager to isolate failures and manage credentials when integrating with a legacy claims system like Guidewire.
🔗 Read more · AWS Architecture
Kubernetes & Cloud Native
KeycloakCon Japan 2026: Navigating cloud native identity and the AI frontier
CNCF
CNCF previewed KeycloakCon Japan, a half-day, single-track event co-located with KubeCon + CloudNativeCon Japan 2026 in Yokohama, running Tuesday, July 28 from 9:00 a.m. to 12:30 p.m. at Pacifico Yokohama (Level 3, Rooms 313-314). The dominant theme is identity and authorization for autonomous AI agents and the Model Context Protocol (MCP), addressing how traditional authorization models break down when an agent acts on a user's behalf and calls downstream APIs across trust boundaries. Yuxiang Lin of Midships Global will argue purpose-built AI identity vendors are unnecessary since OAuth 2.0 token delegation, token exchange, fine-grained scope enforcement, and audit trails are already production-ready in Keycloak, while Mustafa Dayıoğlu of TUBITAK will demo a keyless, zero-trust AI agent pattern on Kubernetes using SPIRE-issued JWT-SVIDs and DPoP to block token replay. Halil Özkan of Keymate will show Keycloak Authorization Services acting as a centralized policy control plane via Istio Ambient mode, waypoint proxies, and a WebAssembly enforcement extension that evaluates service-to-service traffic without touching application code, and IBM's Keycloak maintainer Alexander Schwartz will cover new features including SPIFFE/SPIRE and Kubernetes-token machine identities, Passkey authentication, and SCIM-based cross-domain sync. The event closes with an evening reception sponsored by Octopus Deploy (5:00-6:15 p.m.) and can be added as an option to a KubeCon registration pass.
💡 In an era where MCP-based AI agents call APIs across a production service mesh, teams should redesign authorization around SPIFFE/SPIRE workload identity and OAuth token delegation instead of static secrets, and extending an existing Keycloak/Istio stack can cover this without adopting a separate AI-specific IAM product.
AI Engineer World’s Fair 2026: The Runtime Is Where Agent Trust Is Won
Docker
Docker recapped its week at AI Engineer World's Fair 2026 in San Francisco, where dedicated tracks like Evals, Context Engineering, Harness Engineering, Memory, Sandbox & Platform Engineering, and Inference showed how much the AI-native SDLC has matured into its own discipline. Sandbox and platform engineering emerged as this year's biggest topic, with a full track still debating whether an agent sandbox should be a full VM, a lightweight runtime, or Kubernetes-based. Docker's own three talks argued agent trust is won at the runtime layer. EVP of engineering Tushar Jain's mainstage talk invoked Simon Willison's "lethal trifecta" -- private data access, untrusted content exposure, and the ability to act externally -- arguing the fix belongs in isolation, network policy, trusted images, and credentials, not prompts. Staff product manager Rowan Christmas demoed a read-only coding agent that pieced together his banking activity within minutes, then showed Docker's microVM-based sandbox letting developers define filesystem, network, and tool boundaries per session. Principal engineer Jim Clark addressed "shadow MCP," demoing every MCP server routed through an org-managed, signed catalog with default-deny for anything unapproved.
💡 For teams actually running agents in production, the practical takeaway is that trust has to be enforced at the runtime and platform layer -- trusted images, hardware sandboxing, MCP allowlisting -- not just through prompts.
Is a Pod the right deployment unit for an AI agent?
CNCF
CNCF's blog walks through how the Kubernetes-native agent framework kagent rethought whether a Pod is the right deployment unit for AI agents. kagent originally ran every agent in its own Pod, Service, and ServiceAccount, gaining process isolation, native Kubernetes identity and auth, compatibility with existing network and admission policies, per-agent observability, and native scheduling -- later hardened further with agent-sandbox. But agents behave nothing like always-on microservices: they wake only when assigned work, run for seconds to minutes, can spawn subagents dynamically, act on a user's behalf, or pause mid-execution awaiting human approval, making a dedicated long-lived Pod per agent wasteful. kagent's answer is "agent-substrate," an additional control plane layered on Kubernetes: Kubernetes still manages Pods, Services, networking, storage, and compute, while agent-substrate manages the lifecycle and placement of AI "Actors" using its own abstractions -- WorkerPool (like a NodePool), Worker (like a Node), and ActorTemplate (like a PodTemplate). Example manifests show a gVisor-based image (ghcr.io/kagent-dev/substrate/ateom-gvisor:v0.0.6) and a runsc configuration; each Worker still maps to one real Pod, but Actors are scheduled onto it only when work arrives and removed when done, letting a fixed number of Pods support far more logical agents than one-Pod-per-agent ever could. This raises questions Kubernetes wasn't built to answer, including whether agent identity should attach to the ActorTemplate/namespace/tenant instead of the Pod, whether policy should route through something like agentgateway, and how ownership, multi-tenancy, and observability follow an Actor across the different Workers it runs on.
💡 Running one Pod per short-lived agent doesn't scale for fleets of bursty, seconds-long agents, so cluster operators should watch designs like kagent's agent-substrate that keep Pods as reusable execution workers and add a separate scheduling layer for agent lifecycle.
No single pane of glass: Anatomy of an Azure permission takeover
Sysdig
The Sysdig Threat Research Team analyzed an incident where an attacker turned a single leaked Azure service-principal secret into full tenant takeover within about a day. Starting from that one non-human identity (NHI) credential, the attacker obtained Global Administrator rights in Entra ID, Owner-level Azure RBAC access across every subscription, storage account keys, Event Hub keys, and Key Vault access -- all in roughly an hour of active effort, using nothing but legitimate Azure API calls with no malware or zero-days. Post-incident analysis found the attack moved through five separate, non-interoperable Azure permission systems: Entra ID directory roles (the Global Administrator grant), Azure RBAC (Owner/Contributor/User Access Administrator scoped to subscriptions and resource groups), resource-level policies such as Key Vault access policies that operate independently of RBAC, shared keys and SAS tokens on services like Storage and Event Hubs that grant identity-less, by-default-unlogged data-plane access, and Microsoft Graph API application permissions -- visible only in a separate "API permissions" blade rather than the "Roles and administrators" view. The attacker planted backdoor secrets on 26 separate application registrations for persistence, each with its own independent credential list, so revoking the Global Administrator grant or rotating the original leaked secret did nothing to remove them. The investigation was only fully reconstructable because control-plane logs had already been shipped to immutable, off-tenant storage the attacker couldn't reach, even though the attacker held the Event Hub root keys for the telemetry pipeline itself. Sysdig's 2026 Cloud-Native Security and Usage Report notes non-human identities make up roughly 97% of managed identities in cloud environments while being the least instrumented, and Sysdig contributed four new open-source Falco detection rules, including one for the cross-plane bridge move, in direct response to the gaps this incident exposed.
💡 Because Azure permissions are scattered across five non-overlapping planes (Entra roles, RBAC, resource-level policies, shared keys, and Graph API permissions), incident responders can't call a tenant clean just by pulling a Global Administrator grant -- they need to check every plane and app registration credential, and ship control-plane logs to immutable off-tenant storage before an attacker can reach them.
AI & ML
Celebrating 25 years of visual search innovation
Google AI
Google marked the 25th anniversary of Google Images, which launched in 2001, by unveiling two new features. The first is a redesigned, browseable home for Google Images featuring a dynamic, real-time gallery of images pulled from across the web, with saved collections appearing as tabs above the gallery for easy return visits. The second brings image generation directly into AI Overviews in Search, letting users create an image on the spot when the exact one they're picturing doesn't already exist online. The post, written by Brad Kellett and published July 14, 2026, walks through 25 years of milestones: Google Images (2001), Similar Images (2009), Search by Image (2011), Google Lens in Search (2018), Multisearch in Lens (2022), Circle to Search (2024), Lens + AI Mode and Search Live and visual results in AI Mode (2025), and Circle to Search multi-object recognition plus an "intelligent search box" (2026). It's a retrospective/celebratory piece framing Search's evolution from a text-only tool into a visual exploration platform.
💡 Behind the celebratory framing, the notable engineering signal is that image generation now runs inline inside search results (AI Overviews), meaning a chunk of search traffic shifts from static retrieval to real-time generative inference -- with real implications for caching strategy, latency budgets, and serving cost.
How to manage AI investments in the agentic era
OpenAI
In a blog post published July 14, 2026, OpenAI laid out five ways enterprises should manage AI investment in the agentic era. Token prices per million tokens have fallen 97% from GPT-4 to GPT-5.4, and the newest GPT-5.6 cuts output tokens by 54% and time per task by 57% on the Artificial Analysis Coding Agent Index. But OpenAI argues token price alone doesn't show value -- leaders should track "useful work per dollar," meaning tasks completed, time saved, decisions improved, and workflows ready to scale. First, sharpen visibility into usage and spend via the Admin Console's analytics and spend controls, which break down adoption and cost by user, product, and model. Second, evaluate model efficiency by outcome ROI rather than token price, since a cheaper model that fails and retries can end up costing more than a pricier one that succeeds faster -- tracking cost per accepted outcome is the recommended metric. Third, govern advanced workflows like connectors and Computer Use with access controls, approval steps, and options such as Zero Data Retention before they scale. Fourth, fund AI investment like a portfolio spanning broad everyday access, function-specific workflows, and a smaller number of strategic bets, funding shared capabilities like identity and evaluation centrally, and fifth, match capacity to proven demand using commercial options such as Guaranteed Capacity, Scale Tier, Batch API, Flex Processing, and Prompt Caching.
💡 For cloud/DevOps teams the actionable point is to build FinOps tracking around cost-per-accepted-outcome and workload-matched capacity commitments now, before agent usage scales spend beyond what per-token pricing alone can explain.
How data science teams use ChatGPT Work
OpenAI
OpenAI published a guide on OpenAI Academy showing how data science teams can use ChatGPT Work (formerly branded as Codex) to handle ambiguous, recurring requests -- why a KPI moved, whether an experiment worked, what a dashboard should track. Fed with scattered inputs like dashboards, metric definitions, data exports, experiment notes, and business context, the tool assembles a first-draft deliverable complete with charts, caveats, source links, and review questions. Supported outputs include root-cause briefs, business impact readouts, KPI memos, scoped analyses, dashboard specs, experiment summaries, and dashboard QA checklists. The workflow has moved from the standalone Codex app into ChatGPT Work, now accessible via chatgpt.com and the desktop app. OpenAI frames the tool as producing a faster starting draft for human review, not replacing an analyst's judgment. The guide is part of a broader "Codex for work" series covering different functional teams.
💡 For cloud/DevOps teams the practical value is less about the AI itself and more about whether internal data access controls and governance can be safely wired into this kind of automated reporting pipeline.
How sales teams use ChatGPT Work
OpenAI
OpenAI released a guide on OpenAI Academy showing how sales teams can use ChatGPT Work (formerly Codex) to turn scattered account context -- CRM fields, call notes, emails, Slack threads, decks, customer docs -- into usable drafts: pipeline briefs, meeting prep packets, forecast reviews, account plans, and stalled-deal diagnoses. Its pipeline prioritization use case reviews account records, rep portfolios, call notes, emails, and usage signals to rank accounts by trigger events, pain points, stakeholder access, urgency, and likely next action. Its meeting-prep use case pulls account history and open threads into briefing questions, then drafts customer follow-ups, CRM updates, and internal Slack recaps once post-meeting notes or a transcript exist. Its forecast-review use case produces a sourced view of which deals should stay in commit, move to upside, or get pulled from forecast. The guide is explicit that sellers and managers still own relationship strategy and judgment; the tool just gets a working draft in front of the team faster. It mirrors a parallel guide OpenAI published for data science teams under the same "Codex for work" series.
💡 The relevant takeaway for engineers isn't the sales use case itself but that wiring CRM, Slack, and email into any LLM automation pipeline runs into the same API auth, data-access scoping, and audit-logging problems regardless of the team using it.
Cloud Updates
Google named a Leader in the 2026 IDC MarketScape for Worldwide Foundation Model Software
Google Cloud
Google announced it was named a Leader in the IDC MarketScape: Worldwide Foundation Model Software 2026 Vendor Assessment (Doc #US54427726, published July 2026). The post, authored by Michael Gerstenhaber, VP of Product Management for Cloud AI, credits the recognition to years spent building global infrastructure, security frameworks, and data platforms for large enterprises well before generative AI became mainstream. The core claim is that Google's track record of turning Google DeepMind's frontier research into secure, production-grade systems was a key strength in the assessment. The post positions Gemini Enterprise as the unified system for the "agentic era," combining the Gemini Enterprise app as the front-end for business users with the Gemini Enterprise Agent Platform for developers to build and orchestrate agents. It also highlights Gemini 3.5 Flash, the first release in the Gemini 3.5 series unveiled at I/O this year, co-designed with Google's custom AI infrastructure to handle long-horizon agentic tasks efficiently. Gemini 3.5 Flash is available through the Gemini Enterprise Agent Platform, Google AI Studio, and Antigravity.
💡 The analyst badge itself matters less than the fact that IAM, governance, and cryptographic identity are baked into a single agent platform by default, which is the practical argument enterprise teams weigh when deciding to consolidate on one vendor instead of stitching together point solutions.
Claude at scale on Google Cloud: Frontier AI, built for enterprise production
Google Cloud
Google Cloud published a technical post, authored by Schneider Larbi (Sr Manager, Global Partner Technical Architecture) and Ivan Nardini, on how Claude runs as production-grade frontier AI on its platform. Claude is offered as a fully managed Model-as-a-Service through Agent Platform's Model Garden, with Google Cloud handling compute provisioning, autoscaling, load balancing, and failover so teams can focus on building features rather than inference infrastructure. Calling Claude uses the same IAM, VPC Service Controls, and Cloud Logging/Monitoring stack as any other Google Cloud service. Three endpoint types are available: global endpoints that auto-route to whichever region has capacity, regional endpoints for strict data-residency needs, and multi-region endpoints that give US/EU residency while adding resilience against regional outages. On security, FedRAMP High and HIPAA compliance make it deployable in government, healthcare, and financial-services environments. For cost and performance, the platform supports prompt caching (cutting latency by up to 80% and cost by up to 90%), extended context windows up to 1M tokens (Claude Opus/Sonnet 4.6 and newer), batch prediction, and provisioned throughput for guaranteed capacity -- plus the Agent Development Kit (ADK) to build Claude-based agents deployable to Agent Runtime, Cloud Run, or GKE and interoperable with other agents via the A2A protocol.
💡 The practical win for engineers is that Claude calls stay inside the existing IAM/VPC-SC perimeter with no separate API keys to rotate, and the choice among global, regional, and multi-region endpoints lets teams satisfy data-residency and latency/failover requirements simultaneously -- enabling frontier-model deployment in regulated environments without running your own inference cluster.
A broken DNSSEC rollover took down .AL. Now 1.1.1.1 tells you when validation is bypassed
Cloudflare
In July 2026, a botched DNSSEC key rollover on Albania's .AL top-level domain effectively broke resolution for the entire TLD. Cloudflare's timeline shows the .AL operator published a new DNSKEY around 14:15 UTC while the root zone's DS record still pointed to the old key (ID 26319), causing validation failures; around 17:00 UTC the operator removed the new DNSKEY too, leaving the zone with no DNSKEY at all; and only around 19:15 UTC did the operator remove the DS record from the root zone, restoring resolution by making resolvers stop expecting DNSSEC entirely -- leaving .AL unsigned to this day. Unable to reach the .AL operator via DNS-OARC's Mattermost, Cloudflare applied a Negative Trust Anchor (NTA, per RFC 7646) to all 1.1.1.1 users by 17:15 UTC, bypassing validation to restore lookups. The catch is that NTA-served responses look identical to fully validated ones, giving users no way to tell validation was skipped. To close that gap, Cloudflare co-authored a new Extended DNS Error code, EDE 33 ("Negative Trust Anchor"), with Babak Farrokhi of Quad9, now assigned by IANA and implemented on 1.1.1.1 alongside the underlying error code. The Internet-Draft has gone to the IETF DNSOP working group for discussion at the Vienna IETF meeting July 18-24, and the Knot project's kdig tool already recognizes it, with an Unbound patch under review.
💡 An NTA trades security for availability silently, so unless your resolver and monitoring stack are updated to parse the new EDE 33 signal, a validation bypass upstream stays invisible until it causes a real incident.
Zero trust workload identity manager version 1.1 generally available on Red Hat OpenShift
Red Hat
Red Hat announced general availability of Zero Trust Workload Identity Manager 1.1 on Red Hat OpenShift. Built on the upstream SPIRE project, the reference implementation of the SPIFFE standard, it dynamically issues short-lived, cryptographically attested workload identities at runtime instead of relying on long-lived secrets or static certificates. Version 1.1 adds three notable capabilities. First, native SPIFFE Helper integration bridges legacy applications that can't talk to the SPIRE Workload API directly, automatically fetching, rotating, and hot-reloading credentials without code changes. Second, integration with Istio-based Red Hat OpenShift Service Mesh automates multi-cluster SPIRE federation, enabling strict mutual TLS across clusters, regions, and clouds. Third, cert-manager and Vault plug-in support for UpstreamAuthority lets enterprises hook the identity plane into their existing PKI. The operator, previously exclusive to Red Hat OpenShift Platform Plus, is now available under standard Red Hat OpenShift Container Platform entitlements as well. Red Hat also frames the release as relevant to agentic AI, since attesting AI agent workloads with the same SPIFFE/SPIRE principles extends accountability and traceability to non-human actors.
💡 For cluster operators, the real win is that multi-cluster mTLS federation and bring-your-own-PKI support are now available on standard OpenShift entitlements, cutting the operational burden of rotating static certs and secrets by hand.
Why the future of telco depends on open, ecosystem-led architectures
Red Hat
Red Hat published a blog arguing that as 5G and AI push network complexity to the edge, telecom operators must move beyond legacy, single-vendor vertical stacks toward open, ecosystem-led architectures. It frames the "one vendor per domain" model as an automation bottleneck that creates unmanageable silos and unsustainable operating costs. The proposed alternative is a shared, horizontal, cloud-native platform that decouples infrastructure from applications; Red Hat cites research claiming 30-40% operational savings and double-digit TCO improvement when operators migrate from siloed vertical stacks to this common architecture. It points to production examples: a joint Red Hat/Ericsson/HPE/Intel effort running Ericsson's Cloud RAN portfolio natively on Red Hat OpenShift, and Telstra's multivendor self-healing network built with Red Hat, Dell, and Cisco. On the AI side, the Red Hat AI Factory with NVIDIA (with partners including Nokia) is rolling out autonomous network agents across hybrid clouds, while Mavenir is integrating its telco software with Red Hat OpenShift AI for on-premise conversational AI and service assurance. Verizon and KDDI (working with Samsung) are also named as adopters applying this ecosystem approach to 5G billing and OpenRAN. Red Hat's conclusion is that no single vendor can solve modern edge engineering challenges alone -- only an open, interoperable common platform can.
💡 From an infrastructure operator's view, consolidating vendor-locked vertical stacks onto a common OpenShift platform widens automation and multivendor interoperability, but the payoff hinges on how many partner workloads can actually be run and operated together on that shared foundation.
Storage processing accelerates VM migrations in the migration toolkit for virtualization 2.12
Red Hat
Red Hat released Migration Toolkit for Virtualization (MTV) 2.12, aligned with Red Hat OpenShift 4.22 and focused on advanced storage processing, expanded source-provider support, and AI tooling. The headline feature is NetApp Shift Toolkit integration, which performs zero-copy cold migrations at the storage virtualization layer by instantly cloning the file system within the same NetApp ONTAP array -- the source hypervisor keeps running against the original VM the whole time, so downtime is near-zero. Storage offload for warm migrations also reached general availability, handing snapshot processing off to supported enterprise storage arrays to reduce hypervisor load and shrink the final cutover window. Two new source providers land in Technology Preview: Microsoft Hyper-V and Amazon EC2, opening migration paths off Hyper-V and within AWS public cloud. On the AI front, integration work with Red Hat OpenShift Lightspeed is underway to support natural-language troubleshooting of migration issues, and a Model Context Protocol (MCP) server for MTV is now in Developer Preview, letting LLM-based AI assistants help plan and analyze VM migrations.
💡 For teams running large-scale VM migrations, storage-layer zero-copy cold migration and GA storage offload for warm migrations are concrete wins that directly cut downtime and shrink the cutover window rather than just marketing polish.
DevOps & Infrastructure
“We did not adapt and move quickly enough”: What IBM’s earnings miss says about enterprise AI spending
The New Stack
IBM issued a preliminary second-quarter earnings update that came in well below Wall Street's expectations, and the stock cratered 25% in a single day -- its worst trading day on record, surpassing the 23.7% drop from October 19, 1987. CEO Arvind Krishna attributed the shortfall largely to clients cutting spending on IBM products and redirecting capital expenditure toward servers, storage, and memory purchases ahead of anticipated price increases tied to the AI buildout. Krishna acknowledged the failure directly, saying "We did not adapt and move quickly enough, and numerous large deals failed to close on the timelines we expected, driving the majority of our shortfall." The New Stack frames this as evidence that enterprises are cutting software budgets to fund AI hardware purchases, a shift happening faster than incumbent vendors like IBM can adjust to. The broader takeaway is that this pattern is pushing some development teams toward building custom integrations with open-source tools instead of relying on traditional vendor software.
💡 It's a signal that enterprises are rapidly shifting IT budgets toward AI hardware and infrastructure, so platform/DevOps teams should re-prioritize securing cloud compute/GPU capacity and building open-source-based custom integrations over renewing traditional vendor software contracts.
OpenAI hits 8 million Codex users — what developers need to know
The New Stack
OpenAI launched GPT-5.6 (internally called Sol) last week and folded Codex into its unified ChatGPT desktop app, and it now says Codex plus ChatGPT Work have surpassed 8 million active users within days of launch. Growth was extremely rapid: 6 million users by July 12, 7 million about 24 hours later, and 8 million by the following Sunday. The surge put significant strain on OpenAI's compute infrastructure, prompting the company to reset usage limits for all users and keep the five-hour rate limit suspended for now. On coding benchmarks, GPT-5.6 Sol reportedly comes within one percentage point of a leading rival model while costing about half as much and taking a little over half the time. The New Stack notes that this rapid adoption is reshaping the competitive landscape for AI coding tools and putting pressure on competitors, including Anthropic, to respond.
💡 This shows a coding assistant's traffic spiking by millions of users within days, so DevOps teams wiring these tools into CI/CD or internal tooling should build in fallback strategies for sudden vendor rate-limit and quota changes or API availability swings.
AWS will now watch Microsoft’s cloud for you
The New Stack
On Tuesday, July 14, AWS announced an expansion of Security Hub, its security operations service, to monitor Microsoft Azure resources in addition to AWS resources. The new capability automatically discovers Azure virtual machines, Azure Container Registry (ACR) container images, Azure Function Apps, and Azure identities, then evaluates them for misconfigurations, internet exposure, and software vulnerabilities. Findings from both AWS and Azure appear in a single unified queue using the same format and automation workflows, letting security teams triage from one console instead of switching between tools. Azure resources are billed at the same rates as equivalent AWS resources with no multicloud surcharge, and AWS is offering a separate 30-day free trial specifically for Azure coverage. The same update also adds AI workload protection features -- GuardDuty AI Protection for Bedrock and SageMaker, an AI asset inventory, and AI-powered investigations in preview -- positioning AWS to compete more directly with Microsoft Defender for Cloud and Wiz in the multicloud security market.
💡 For security and platform teams running multicloud environments, this means AWS and Azure vulnerabilities and exposures can now be triaged through a single existing Security Hub workflow instead of a separate Azure-only tool, cutting down on tool sprawl and alert fatigue.
Shipping Is Your Company's Heartbeat: A Letter from a CTO
Honeycomb
This Honeycomb blog post is framed as an open letter from Darragh Curran, CTO and Head of Engineering at Fin, addressed to engineering leaders everywhere. Its central claim is that "shipping is your company's heartbeat" -- software only becomes valuable once it reaches real customers, and before that it's just an accumulation of costly assumptions. Curran argues AI is not a "magic wand" but an "amplifier": it amplifies whatever engineering practices already exist, whether good or bad. The conclusion drawn from that framing is that as AI adoption grows, engineering rigor -- code review, testing, observability -- becomes more important, not less. Curran draws on his own experience running engineering at Fin to make the case, and the piece is positioned alongside Honeycomb's recently released second edition of "Observability Engineering." Overall, it's a leadership-facing message that shipping speed and engineering fundamentals must be maintained together in the AI era.
💡 The warning for engineering leaders is that loosening observability, review, or test gates just because you've adopted an AI coding assistant will amplify incidents and bad deploys just as much as it amplifies good practices -- so pipeline guardrails need to get tighter, not looser, as AI usage grows.
Automated Incident Remediation with AWS DevOps Agent and Kiro CLI
AWS DevOps
This AWS DevOps blog post covers how AWS DevOps Agent and Kiro CLI combine to automate incident response from investigation through to a deployed fix (note: direct fetch of the full article was blocked in this session, so this summary draws on publicly available context found via search plus the title and excerpt). The framing is that automated incident remediation -- turning investigation findings into deployed fixes without manual toil -- is described as the next challenge for teams running distributed workloads on AWS. Once AWS DevOps Agent produces a root-cause finding, engineers can select "Generate mitigation plan" to get a structured remediation plan, or automate the loop programmatically via CLI commands such as aws devopsagent create-backlog-task and update-backlog-task to trigger investigations and approve mitigation plans (per related posts in the same AWS blog series). Each plan follows four phases -- Prepare, Pre-Validate, Apply, Post-Validate -- with the agent proposing concrete commands to update infrastructure-as-code templates or configuration. When code-level changes are needed, the agent hands off an agent-ready spec to Kiro CLI, whose coding agent implements the fix directly in the codebase, connecting incident diagnosis to code remediation in one workflow.
💡 Root-cause detection and mitigation-plan generation can be automated via CLI, but if the actual Apply step runs without a human reviewing and approving the change first, a wrong root-cause guess turns straight into a production incident -- so teams need a clear operational policy on exactly how far auto-approval is allowed to go.
Building Service Topology at Scale: Architecture, Challenges, and Lessons Learned
Netflix
Netflix's engineering blog (by Parth Jain, Rakesh Sukumar, Yingwu Zhao, Renzo Sanchez-Silva, and Nathan Fisher) detailed the architecture decisions and production firefighting behind its real-time Service Topology system, which maps service dependencies at Netflix's scale. It streams eBPF network flows, IPC metrics, and distributed traces into physically separate graph layers, delivering topology updates within tens of minutes instead of the hours-or-days lag of batch processing. To resolve network hops through intermediaries like load balancers and NAT gateways into true application-to-application edges, the team built a three-stage distributed aggregation pipeline, replacing gRPC with Server-Sent Events plus backpressure between stages to cut CPU overhead. Getting the first version (V1) into production surfaced serious issues: Kafka consumer lag, "hot nodes" where some instances took on 100x the traffic of others, and garbage collection pauses that ate more CPU than the actual business logic. The hot-node problem was solved by redistributing load twice across the three-stage pipeline, and the GC pressure was solved by deliberately breaking Scala's immutability convention and using mutable data structures on the hot path, cutting heap allocation by over 50%. In V2, the team kept optimizing -- removing redundant object conversions, standardizing on JSON serialization, tuning stream parallelism, and batching graph database writes -- and added a "time travel" feature that reconstructs historical topology from 5-minute aggregate snapshots plus property-level mutation tracking. The system now processes millions of flow records per second with sub-second query latency and is used daily across Netflix for incident investigation and blast-radius analysis.
💡 For SREs and platform engineers building large-scale observability pipelines, this is a concrete case study showing that consistent hashing alone can't prevent hot nodes under power-law traffic -- multi-stage redistribution, backpressure, and measurement-driven departures from convention are what actually keep production stable.
This digest was collected from RSS feeds and summarized by AI (Claude). See the original links for full details.