# load balancer Published articles for load balancer. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## MCP went stateless: What changed in the 2026-07-28 spec DevFeed: [MCP went stateless: What changed in the 2026-07-28 spec]() Original publisher: [Read original article]() Author: WorkOS Published: 2026-09-16T00:00:00Z Content type: article Language: en Sources: [WorkOS Blog]() Topics: [Model Context Protocol](), [migration](), [HTTP](), [servers](), [client]() Tags: [api](), [client](), [http](), [load-balancer](), [mcp](), [replacement](), [request](), [routing](), [server](), [servers](), [sessions](), [stateless](), [stream]() ### AI overview The 2026-07-28 MCP specification removes protocol-level sessions, the initialize handshake, and stream resumability, making the protocol behave more like an ordinary HTTP API. Most migrations are mechanical, but lost stream requests can cause reliability regressions or duplicated side effects when retried, so side-effecting tools need application-level idempotency keys. The elicitation change also requires architectural rework. ### Source excerpt Sessions, the initialize handshake, and stream resumability are all gone. Here is what replaced them, and what breaks if you ignore it. ## How We Built Automated Capacity Testing for Kafka Consumers DevFeed: [How We Built Automated Capacity Testing for Kafka Consumers]() Original publisher: [Read original article]() Author: Kaan Karakaya Published: 2026-09-14T09:46:34Z Content type: tutorial Language: en Sources: [Booking.com Development - Medium]() Topics: [Kafka](), [Testing](), [HTTP]() Tags: [automated](), [capacity](), [health-checks](), [kafka](), [load](), [load-balancer](), [parallelism](), [partition](), [recovery](), [scale](), [site-reliability-engineer](), [sre](), [testing]() ### AI overview This article describes Booking.com's extension of an existing capacity-testing platform for Kafka consumers. It explains how changing partition assignment can provide a controlled, measurable way to test consumer throughput and whether remaining consumers can absorb reassigned work after an instance or failure domain disappears. ### Source excerpt Photo by GuerrillaBuzz on Unsplash Kafka makes it easy to distribute work across consumer instances. It is much harder to prove, safely and repeatedly, how those instances behave when the distribution changes and one of them has to carry more than its usual share. For teams that run Kafka at scale, this is a practical reliability question: how much load can a consumer instance actually handle? We had automated capacity testing for HTTP services, but Kafka consumers were still tested with manual drills. Those drills could tell us something, but they were disruptive, difficult to reproduce, and risky precisely when the system was close to its limit. We wanted a controlled way to answer three questions: What is the maximum sustainable throughput of a consumer instance? If an instance or failure domain disappears, can the remaining consumers absorb the reassigned work? Are we overprovisioning resources because we do not know the real limit? The result was an extension to our capacity-testing platform that turns Kafka partition assignment into a safe, measurable load-control mechanism. Why HTTP capacity testing did not translate Our existing platform was designed for request-response services behind a load balancer. A scheduled test selects one instance, routes an increasing share of traffic to it, runs health checks after each step, and records the highest ratio the instance can sustain. After the test, traffic returns to its normal distribution and the result is reported to the service owner. Kafka has no equivalent traffic knob. Consumers pull records, and the unit of parallelism is the partition. Within a consumer group, each partition is owned by one consumer at a time. If a topic has 12 partitions and four equally loaded instances, each instance owns about three. When one instance disappears, a rebalance gives the survivors more partitions -- and the extra work arrives as a step change, not as a smooth increase from a load balancer. The key translation: for an HTTP ## 【kube-apiserver】运维与升级：HA、flags、graceful shutdown 与 etcd 联检 DevFeed: [【kube-apiserver】运维与升级：HA、flags、graceful shutdown 与 etcd 联检]() Original publisher: [Read original article]() Author: Liao Tonglang Published: 2026-08-28T00:00:00Z Content type: tutorial Language: zh Sources: [土法炼钢 - 系统与基础设施]() Topics: [Kubernetes](), [Encryption]() Tags: [api](), [apiserver](), [audit](), [backend](), [config](), [distributed](), [encryption](), [etcd](), [flag](), [graceful-shutdown](), [ha](), [kubernetes](), [leader-election](), [load-balancer](), [operations](), [retry](), [servers](), [upgrade](), [v1-30-3]() ### AI overview This Chinese-language operations tutorial explains kube-apiserver high availability and upgrades for Kubernetes v1.30.3. It clarifies that multiple apiserver instances run concurrently without internal leader election, sharing an etcd cluster, and covers key flags, graceful shutdown, encryption configuration, audit webhooks, upgrade checks, and version-skew guidance. ### Source excerpt kube-apiserver 高可用模式：多实例共享 etcd、无需内部 leader election；核心 flag 语义（--etcd-servers、--etcd-servers-overrides、--shutdown-delay-duration、encryption-provider-config）；与 etcd/14 的联合升级检查单；Kubernetes 版本偏差策略与 etcd 矩阵指针。 ## Safer Kubernetes rollouts with minReadySeconds DevFeed: [Safer Kubernetes rollouts with minReadySeconds]() Original publisher: [Read original article]() Author: Andre Newman Published: 2026-08-20T00:00:00Z Content type: article Language: en Sources: [Gremlin Blog]() Topics: [Kubernetes](), [Availability](), [Deployment]() Tags: [availability](), [deployment](), [kubernetes](), [load-balancer]() ### AI overview This article explains how Kubernetes minReadySeconds makes newly created pods remain Ready for a defined period before rollout controllers remove the pods they replace. It describes how the setting improves rolling-update safety, supports pod disruption budgets, and allows time for external load balancers to register new backends. ### Source excerpt minReadySeconds makes new pods prove they can stay ready before a rollout moves on. Learn what it controls, how to set it, and how to find workloads missing it. ## Understanding Load Balancing for Beginners DevFeed: [Understanding Load Balancing for Beginners]() Original publisher: [Read original article]() Author: Pramodh Kumar M Published: 2026-08-17T17:00:34Z Content type: tutorial Language: en Sources: [Kubernetes - KodeKloud Blog | DevOps, Cloud, Kubernetes, AI Tutorials & More]() Topics: [backends](), [networking](), [Algorithms]() Tags: [backend](), [beginners](), [cloud](), [connection-draining](), [devops](), [failover](), [health-checks](), [high-availability](), [kubernetes](), [layer-4-vs-layer-7](), [least-connections](), [load-balancer](), [load-balancer-for-beginners](), [load-balancing](), [load-balancing-algorithms](), [networking](), [nginx](), [round-robin](), [session-affinity](), [sre](), [sticky-sessions](), [thundering-herd](), [traffic-management]() ### AI overview This beginner-oriented article explains load balancing as both traffic distribution and backend failure detection. It compares round robin and least-connections algorithms, distinguishes Layer 4 from Layer 7 routing, and discusses health checks, failover, draining, sticky sessions, and the risks of overly aggressive checks. ### Source excerpt Spreading traffic is the easy half of load balancing. The half that decides whether an outage lasts ten seconds or ten minutes is noticing that a backend has stopped working, and most health checks cannot. ## What your AI SRE can't see (and what you can do about it) DevFeed: [What your AI SRE can't see (and what you can do about it)]() Original publisher: [Read original article]() Author: Ryan Detwiller Published: 2026-08-06T00:00:00Z Content type: opinion Language: en Sources: [Gremlin Blog]() Topics: [Artificial Intelligence](), [SRE](), [incident](), [Availability](), [telemetry](), [Latency](), [Memory Leaks](), [Deployment]() Tags: [ai](), [availability](), [config](), [dependency](), [deployment](), [latency](), [load-balancer](), [memory](), [outage](), [outages](), [sre]() ### AI overview The article argues that AI SRE tools can speed up triage, reduce alert fatigue, and automate frontline incident response, but they do not solve all reliability problems. It identifies gaps including acting only after failures begin and being unable to predict sudden failures without detectable warning signals. ### Source excerpt AI SRE is having a moment. And let's be honest: faster triage, less alert fatigue, and automated frontline response are wins for understaffed teams. But there are still five gaps in their capabilities, and if you don't understand those gaps before you deploy, you'll find out during an outage. ## Splunk and Isovalent Runtime Security: Protecting the Platform Behind Splunk DevFeed: [Splunk and Isovalent Runtime Security: Protecting the Platform Behind Splunk]() Original publisher: [Read original article]() Author: Dean Lewis Published: 2026-07-09T06:02:44Z Content type: article Language: en Sources: [Isovalent - The latest articles covering eBPF-based Networking, Observability, and Security]() Topics: [Security]() Tags: [cilium](), [customer](), [ebpf](), [hubble](), [isovalent](), [kubernetes-networking](), [load-balancer](), [mesh-networking](), [platform](), [runtime-security](), [security](), [tetragon](), [website]() ### AI overview Splunk uses Isovalent Runtime Security, built on Tetragon, to protect its customer-facing platform. ### Source excerpt Splunk uses Isovalent Runtime Security, built on Tetragon, to protect its customer facing platform. ## Taming the AI Double Threat with Isovalent Runtime Security DevFeed: [Taming the AI Double Threat with Isovalent Runtime Security]() Original publisher: [Read original article]() Author: Paul Arah Published: 2026-06-26T18:47:44Z Content type: opinion Language: en Sources: [Isovalent - The latest articles covering eBPF-based Networking, Observability, and Security]() Topics: [Security](), [ai-assisted attacks](), [Artificial Intelligence]() Tags: [ai](), [ai-assisted-attacks](), [attacks](), [cilium](), [ebpf](), [hubble](), [infrastructure](), [isovalent](), [kubernetes-networking](), [load-balancer](), [mesh-networking](), [runtime-security](), [security](), [tetragon](), [website]() ### AI overview This blog post examines how AI-assisted attacks change assumptions about adversaries, the new attack surface introduced by AI workloads, and the infrastructure, identity, and runtime controls needed to address these risks with Isovalent Runtime Security. ### Source excerpt This blog post explores how AI-assisted attacks are changing the assumptions we make about the adversary, the new attack surface AI workloads introduce, and the infrastructure, identity, and runtime controls they require, and finally, how teams can address this new threat landscape with Isovalent Runtime Security. ## Tetragon 1.7 adds fentry sensing, environment variable capture, parent-process visibility, and scoped policies DevFeed: [Tetragon 1.7 adds fentry sensing, environment variable capture, parent-process visibility, and scoped policies]() Original publisher: [Read original article]() Author: Paul Arah Published: 2026-06-09T14:01:46Z Content type: release Language: en Sources: [Isovalent - The latest articles covering eBPF-based Networking, Observability, and Security]() Topics: [Processes](), [Environment Variables](), [context]() Tags: [cilium](), [ebpf](), [environment-variables](), [hubble](), [isovalent](), [kubernetes-networking](), [load-balancer](), [mesh-networking](), [policy](), [process](), [runtime-security](), [sensor](), [tetragon](), [visibility](), [website]() ### AI overview Tetragon 1.7 introduces a new fentry sensor, environment variable capture, parent-process visibility, and granular policy scoping with hostSelector. ### Source excerpt Tetragon 1.7 introduces a new fentry sensor, environment variables capturing, parent process visibility, granular policy scoping with hostSelector and more! ## Isovalent Private Networks and Cisco Nexus One: BGP EVPN Integration for the Enterprise Data Center DevFeed: [Isovalent Private Networks and Cisco Nexus One: BGP EVPN Integration for the Enterprise Data Center]() Original publisher: [Read original article]() Author: Marcos Hernandez, Camillo Rossi Published: 2026-06-04T16:42:52Z Content type: release Language: en Sources: [Isovalent - The latest articles covering eBPF-based Networking, Observability, and Security]() Topics: [virtualization](), [networking](), [BGP](), [Cisco](), [evpn](), [VXLAN](), [datacenter]() Tags: [bgp](), [cilium](), [cisco](), [data-center](), [ebpf](), [evpn](), [hubble](), [isovalent](), [kubernetes-networking](), [load-balancer](), [mesh-networking](), [networking](), [nexus-one](), [runtime-security](), [tetragon](), [virtualization](), [vxlan](), [website]() ### AI overview Isovalent announces the general availability of Isovalent Networking for Virtualization and highlights its BGP EVPN/VXLAN integration with Cisco NX-OS for enterprise data centers. ### Source excerpt Today we're announcing the General Availability (GA) of Isovalent Networking for Virtualization alongside a deeper look at one of its core connectivity capabilities: BGP EVPN/VXLAN integration with Cisco NX-OS, part of the Cisco Nexus One strategic alignment. ## OpenAI Uses Isovalent for a Common Networking for AI Infrastructure DevFeed: [OpenAI Uses Isovalent for a Common Networking for AI Infrastructure]() Original publisher: [Read original article]() Author: Dean Lewis Published: 2026-06-03T10:42:00Z Content type: article Language: en Sources: [Isovalent - The latest articles covering eBPF-based Networking, Observability, and Security]() Topics: [Cilium](), [OpenAI](), [AI Infrastructure](), [Kubernetes](), [networking]() Tags: [ai](), [ai-infrastructure](), [cilium](), [ebpf](), [hubble](), [infrastructure](), [isovalent](), [kubernetes](), [kubernetes-networking](), [load-balancer](), [mesh-networking](), [networking](), [openai](), [policy](), [runtime-security](), [tetragon](), [troubleshooting](), [uses](), [website]() ### AI overview The article reports that OpenAI uses Isovalent Networking for Kubernetes, built on Cilium, to provide consistent networking, policy, and troubleshooting across its AI infrastructure. ### Source excerpt OpenAI uses Isovalent Networking for Kubernetes, built on Cilium, for consistent networking, policy, and troubleshooting across AI infrastructure. ## Isovalent Networking for Virtualization: Enterprise-Grade Network Segmentation and Multi-Tenancy for VMs in Kubernetes DevFeed: [Isovalent Networking for Virtualization: Enterprise-Grade Network Segmentation and Multi-Tenancy for VMs in Kubernetes]() Original publisher: [Read original article]() Author: Marcos Hernandez Published: 2026-06-02T12:59:28Z Content type: release Language: en Sources: [Isovalent - The latest articles covering eBPF-based Networking, Observability, and Security]() Topics: [virtualization](), [Network Segmentation](), [Multi-tenancy](), [Kubernetes]() Tags: [cilium](), [ebpf](), [hubble](), [isovalent](), [kubernetes](), [kubernetes-networking](), [load-balancer](), [mesh-networking](), [migrations](), [multi-tenancy](), [network-segmentation](), [policy](), [product](), [runtime-security](), [tetragon](), [virtualization](), [website]() ### AI overview Isovalent announced the general availability of Isovalent Networking for Virtualization, a product that provides network segmentation, multi-tenancy, and policy enforcement for virtual machine workloads running in Kubernetes. It also streamlines migrations to KubeVirt. ### Source excerpt We're formally announcing the General Availability of Isovalent Networking for Virtualization (INV), a purpose-built product that brings full network segmentation, multi-tenancy, and policy enforcement to virtual machine workloads running in Kubernetes, in addition to streamlining migrations to KubeVirt. ## Customers over control: how we measure On-call reliability DevFeed: [Customers over control: how we measure On-call reliability]() Original publisher: [Read original article]() Author: Mike Fisher Published: 2026-05-28T16:29:00Z Content type: article Language: en Sources: [The incident.io Blog]() Topics: [SRE](), [Availability](), [site-reliability-engineering](), [nginx](), [Amazon Web Services](), [API](), [Network](), [incident]() Tags: [2025](), [api](), [availability](), [aws](), [customers](), [http](), [incident](), [incident-channel](), [incident-management](), [incident-response](), [load-balancer](), [metrics](), [network](), [on-call](), [outage](), [post-mortem](), [slack-incident](), [sre]() ### AI overview This article explains how incident.io measures the reliability of its On-call product from the customer's perspective. It focuses on two critical functions, defines SLIs and monthly SLOs, and describes monitoring at the GCP load balancer, alerting, replicated components, and lessons from an AWS outage. ### Source excerpt Instead of thinking about reliability as an exercise in figuring out what we can control, and ignoring anything beyond that, we think about what we'll be really proud to offer to customers. ## Three 5xx and one 4xx: the codes I actually care about DevFeed: [Three 5xx and one 4xx: the codes I actually care about]() Original publisher: [Read original article]() Author: Sridhar Rajarao Published: 2026-05-26T00:00:00Z Content type: tutorial Language: en Sources: [Sridhar Rajarao]() Topics: [HTTP](), [site-reliability-engineering](), [API](), [nginx](), [servers]() Tags: [api](), [http](), [load-balancer](), [nginx](), [production](), [reliability](), [scale](), [sre]() ### AI overview An SRE-oriented guide to interpreting HTTP status codes 500, 502, 503, and 429 in production. It connects each code with likely causes and recommended operational responses, including checking logs, investigating backend failures, load shedding, and client backoff. ### Source excerpt How I read 500, 502, 503, and 429 in production at scale, and what each one is really telling you. ## Buzzing Beyond Clouds: The Illustrated Children's Guide to Cilium DevFeed: [Buzzing Beyond Clouds: The Illustrated Children's Guide to Cilium]() Original publisher: [Read original article]() Author: Bill Mulligan, Katie Meinders Published: 2026-05-19T10:23:39Z Content type: release Language: en Sources: [Isovalent - The latest articles covering eBPF-based Networking, Observability, and Security]() Topics: [Cilium]() Tags: [book](), [cilium](), [ebpf](), [hubble](), [isovalent](), [kubernetes-networking](), [load-balancer](), [mesh-networking](), [runtime-security](), [tetragon](), [website]() ### AI overview Buzzing Beyond Clouds is an illustrated children's guide to Cilium. The book is presented as a follow-up to an illustrated guide to eBPF and is intended for readers with varying levels of technical expertise. ### Source excerpt Buzzing Beyond Clouds: The Illustrated Children's Guide to Cilium, and follow up to Buzzing Across Space: The Illustrated Children's Guide to eBPF, is now available. This second illustrated book brings the Cilium story to life in a way that can be digested by readers of all ages and levels of technical expertise. ## Five Deployment Strategies for Safer Software Releases DevFeed: [Five Deployment Strategies for Safer Software Releases]() Original publisher: [Read original article]() Author: Saurabh Dashora Published: 2026-05-12T07:05:17Z Content type: article Language: en Sources: [System Design Codex]() Topics: [Deployment Strategies](), [Deployment](), [progressive delivery](), [App]() Tags: [blue-green-deployment](), [deployment-strategies](), [downtime](), [load-balancer](), [progressive-delivery](), [rollback]() ### AI overview This article discusses deployment strategies for reducing release risk, downtime, and user impact. It explains blue/green deployment and canary deployment, including their workflows, benefits, tradeoffs, and suitable use cases, and introduces A/B testing as part of a release process. ### Source excerpt Every developer should know these ## Operating Trino at Scale With Trino Gateway DevFeed: [Operating Trino at Scale With Trino Gateway]() Original publisher: [Read original article]() Author: Prakhar Sapre Published: 2026-03-24T12:01:00Z Content type: article Language: en Sources: [Expedia]() Topics: [gateway](), [Load Balancing](), [Routing (disambiguation)](), [data analytics](), [Authentication](), [SQL]() Tags: [analytics](), [authentication](), [clusters](), [concurrency](), [data-science](), [downtime](), [gateway](), [load-balancer](), [load-balancing](), [open-source](), [sql](), [trino](), [trino-gateway](), [trinos]() ### AI overview This article explains how Trino Gateway routes queries across multiple Trino clusters and centralizes routing, authentication, load balancing, monitoring, and cluster management. It describes the project's origins as Presto Gateway at Lyft and its role in supporting larger analytics platforms with more complex workloads and higher concurrency. ### Source excerpt Expedia Group Technology -- DataWorkload-aware routing for TrinoPhoto by Joseph Barrientos on Unsplash Trino -- a fork of PrestoSQL -- is a powerful tool in modern data analytics, enabling organizations to query large datasets quickly and efficiently. As a distributed SQL query engine, Trino provides fast, scalable insights without requiring data relocation. While Trino is robust on its own, its capabilities are further enhanced when paired with a Gateway, which introduces features such as query routing, strong security, and streamlined cluster management. A brief overview The Gateway project originated at Lyft as Presto Gateway, serving as a proxy and load balancer for PrestoDB. It was later forked and integrated into the Trino ecosystem, with contributions from various organizations and the open-source community. The Gateway serves as a central point for managing and routing queries, providing a unified interface for users and administrators. As organizations scale their analytics platforms, they often encounter challenges such as increased query complexity, higher concurrency, and the need for specialized cluster configurations. Directing users to specific cluster endpoints becomes impractical as the user base grows. A Gateway addresses these challenges by routing queries to the most appropriate clusters based on workload, improving efficiency and responsiveness. The Gateway acts as a vital intermediary between users and the Trino query engine. By abstracting the complexities of distributed query execution, it manages critical functions such as routing, authentication, and load balancing across diverse backend clusters. This ensures that queries are efficiently directed to the optimal processing cluster. With an intuitive user interface, the Gateway transforms what was once a convoluted process into a manageable and transparent experience empowering administrators with real-time insights and precise control over their backend cluster infrastructure. Whether it's mon ## Cost Optimisation in ECS: Integrating Spot Instances at Scale DevFeed: [Cost Optimisation in ECS: Integrating Spot Instances at Scale]() Original publisher: [Read original article]() Author: Aakash Singhal Published: 2025-09-12T00:00:00Z Content type: article Language: en Sources: [Deliveroo]() Topics: [Amazon Elastic Container Service](), [Amazon EC2](), [Amazon Web Services](), [Cloud](), [Automation](), [Resilience](), [Availability](), [container]() Tags: [automation](), [availability](), [aws](), [container](), [cost](), [cost-optimisation](), [ec2](), [ecs](), [infrastructure](), [load-balancer](), [resilience](), [scale](), [stateless](), [storage]() ### AI overview Deliveroo describes how it integrated EC2 Spot Instances into Amazon ECS to reduce compute costs while maintaining service stability. The approach routes only eligible workloads to Spot capacity and uses criteria such as fast shutdown, task redundancy, statelessness, and load balancer deregistration timing. ### Source excerpt At Deliveroo, we're always refining how we scale - especially when it comes to managing compute costs in the cloud. After optimising our Amazon ECS workloads with Reserved Instances and Savings Plans, we saw an opportunity to push further using EC2 Spot Instances, which offer up to 90% savings compared to On-Demand prices. But Spot comes with challenges: Their availability can fluctuate, and they can be terminated with just a two-minute warning. To unlock these savings without compromising service stability, we had to engineer a robust solution across infrastructure, workload qualification, and automation. The Challenge: Balancing Cost and Reliability Our ECS infrastructure initially relied entirely on On-Demand EC2 instances, provisioned through Auto Scaling Groups (ASGs) connected to ECS Capacity Providers. While reliable, this approach didn't take advantage of AWS's surplus compute capacity. We aimed to layer Spot Instances into our clusters, but selectively. Our goal was clear: route only eligible workloads to Spot capacity while ensuring no service degradation during unexpected terminations. Spot Instances: Power and Pitfalls Spot Instances provide dramatic cost reductions but introduce several operational caveats: Ephemeral by nature: AWS can terminate them at any time with a two-minute warning. Capacity variability: Availability depends on AWS's excess capacity in each AZ and can shift unpredictably. Scaling limitations: Auto Scaling may fail if the desired instance types are not currently available. To avoid introducing fragility into our stack, we established technical eligibility criteria that workloads must meet before being scheduled on Spot. Defining Spot Eligibility We formalised the following criteria to assess whether a workload could safely tolerate Spot interruptions: Fast Shutdown Support Constraint: stopTimeout must be < 120 seconds in the container definition. Reason: Ensures ECS has time to gracefully shut down the task before AWS's 2-minute te ## How Klarna Built Cloud Inventory for AWS Configuration Management DevFeed: [How Klarna Built Cloud Inventory for AWS Configuration Management]() Original publisher: [Read original article]() Author: Maxim Savin Published: 2025-06-06T06:38:06Z Content type: article Language: en Sources: [Klarna Engineering]() Topics: [configuration-management](), [cloud-infrastructure](), [Amazon Web Services](), [configuration](), [Cloud](), [Security](), [digital]() Tags: [automated](), [aws](), [change-management](), [cloud](), [cloud-infrastructure](), [cloud-inventory-software](), [configuration-management](), [engineering-management](), [lead-time](), [load-balancer](), [logs](), [rds](), [security](), [snapshots](), [technical-change]() ### AI overview Klarna describes Cloud Inventory, an ecosystem of services for collecting, normalizing, mapping, and serving information about ICT assets across its cloud infrastructure. The article explains how it supports configuration management through automated controls and reports faster control rollout and large-scale infrastructure optimization work. ### Source excerpt A long time ago, as a punishment for his crimes, Hades, the king of the underworld, made Sisyphus roll a huge enchanted boulder endlessly up a steep hill. Since then, many tech companies have learned to do that at scale by the hardships of cloud configuration management. Consider an Engineer who wants to ensure that the data that moves through their system is encrypted along the way. This is a noble goal, and to achieve it they must identify every classic load balancer in their AWS environment to replace it with an application load balancer that enforces encryption in transit. Now imagine doing that at the scale of a company like Klarna, where teams collectively own more than a thousand AWS accounts? Add to this a multitude of other configuration challenges -- databases that have not been deployed in a multi-availability zone set-up, missing Cloudwatch logs, expired digital certificates, systems running on unsupported framework versions -- the list is endless. Identifying and rectifying violating cloud assets often feels like an endless game of whack-a-mole played blindfolded. This is the steep price tech companies pay to operate their systems securely and confidently, day by day. Klarna Engineering Platform (KEP) has been on a mission to facilitate configuration management for Klarna Engineers. After a few iterations we have built an ecosystem of Klarna services designed to collect, normalize, map, and serve data on ICT assets within Klarna's cloud infrastructure. We call this system Cloud Inventory. Over the last few months Klarna has: Rolled out over 100 automated controls enhancing every aspect of our configuration management (security, governance, and operational excellence), each control aimed to help system owners to identify and fix violations quickly. Reduced the lead time of rolling out a control from several weeks to a matter of minutes And as a result, successfully completed several large-scale cloud infrastructure optimization projects, such as a company- ## Using Kamal 2.0 in Production DevFeed: [Using Kamal 2.0 in Production]() Original publisher: [Read original article]() Published: 2025-05-29T00:00:00Z Content type: opinion Language: en Sources: [The Fly Blog]() Topics: [Deployment](), [Docker](), [GitHub Copilot](), [Markdown](), [configuration](), [Database](), [Rails]() Tags: [cdn](), [close-to-users](), [configuration](), [database](), [deploy-app-servers](), [deployment](), [docker](), [elixir](), [fly](), [fly-io](), [github](), [github-copilot](), [heroku-alternative](), [heroku-competitor](), [hosting](), [i](), [load-balancer](), [markdown](), [networking](), [postgresql-clusters](), [servers](), [ssh]() ### AI overview An opinionated guide to using Kamal 2.0 in production, covering the surrounding Docker ecosystem, container repositories, secrets, load balancing, managed databases, backups, searchable logs, monitoring, security, SSH keys, and hosting choices. The author explains that GitHub Copilot helped convert XML notes to Markdown and proofread the resulting online publication. ### Source excerpt Agile Web Development with Rails 8 is off to production, where they do things like editing, indexing, pagination, and printing. In researching the chapter on Deployment and Production, I became very dissatisfied with the content available on Kamal. I ended up writing my own, and it went well beyond the scope of the book. I then extracted what I needed from the result and put it in the book. Now that I have some spare time, I took a look at the greater work. It was more than a chapter and less than a book, so I decided to publish it online. This took me only a matter of hours. I had my notes in the XML grammar that Pragmatic Programming uses for books. I asked GitHub Copilot to convert them to Markdown. It did the job without my having to explain the grammar. It made intelligent guesses as to how to handle footnotes and got a number of these wrong, but that was easy to fix. On a lark, I asked it to proofread the content, and it did that too. Don't get me wrong, Kamal is great. There are plenty of videos on how to get toy projects online, and the documentation will tell you what each field in the configuration file does. But none pull together everything you need to deploy a real project. For example, there are seven things you need to get started. Some are optional, some you may already have, and all can be gathered quickly if you have a list. Kamal is just one piece of the puzzle. To deploy your software using Kamal, you need to be aware of the vast Docker ecosystem. You will want to set up a builder, sign up for a container repository, and lock down your secrets. And as you grow, you will want a load balancer and a managed database. And production is much more than copying files and starting a process. It is ensuring that your database is backed up, that your logs are searchable, and that your application is being monitored. It is also about ensuring that your application is secure. My list is opinionated. Each choice has a lot of options. For SSH keys, there are a ## Top 10 Launches of Launch Week 14 DevFeed: [Top 10 Launches of Launch Week 14]() Original publisher: [Read original article]() Author: Wen Bo Xie Published: 2025-04-04T07:00:00Z Content type: article Language: en Sources: [Supabase Blog]() Topics: [Supabase](), [MCP](), [Model Context Protocol](), [dashboards](), [Databases](), [SQL](), [Artificial Intelligence](), [Latency](), [Shadcn UI](), [Claude](), [Command-line interface](), [Docker]() Tags: [claude](), [configuration](), [cursor](), [data](), [errors](), [integration](), [latency](), [launch](), [load-balancer](), [mcp](), [mcp-server](), [openai](), [release](), [shadcn-ui](), [sql](), [stripe](), [third-party](), [tooling]() ### AI overview Supabase highlights ten launches from Launch Week 14, including dashboard-based Edge Function deployment, scalable database-triggered Realtime Broadcast, routing Data API requests to the nearest read replica, a Supabase UI Library, an official MCP server, declarative database schemas, Clerk Auth integration, and a Postgres Language Server. The supplied text does not include the full details of the final launches. ### Source excerpt Highlights from Launch Week 14 ## Data API Routes to Nearest Read Replica DevFeed: [Data API Routes to Nearest Read Replica]() Original publisher: [Read original article]() Author: José Ledesma Published: 2025-04-04T07:00:00Z Content type: article Language: en Sources: [Supabase Blog]() Topics: [API](), [Latency](), [Database](), [Algorithms, Complexity](), [networking]() Tags: [algorithms](), [api](), [data](), [geospatial](), [latency](), [load-balancer](), [mapping](), [network](), [read-replica](), [round-robin]() ### AI overview Supabase is releasing geo-routing for Data API requests, directing each request to the geographically nearest read replica. The feature uses network-edge geolocation, regional coordinate mapping, distance calculations with the Haversine formula, and round-robin distribution when multiple databases share a region. It is available by default through a load balancer endpoint and requires only a project URL update. ### Source excerpt Route your Data API (PostgREST) requests to the nearest Read Replica ## Let's Consign CAP to the Cabinet of Curiosities DevFeed: [Let's Consign CAP to the Cabinet of Curiosities]() Original publisher: [Read original article]() Author: Marc Brooker Published: 2024-07-25T00:00:00Z Content type: opinion Language: en Sources: [Marc Brooker's Blog](), [Marc Brooker's Blog]() Topics: [distributed-systems](), [Availability](), [Cloud](), [Internet of things]() Tags: [availability](), [cloud](), [distributed-systems](), [dns](), [iot](), [load-balancer]() ### AI overview The article argues that CAP theorem is largely irrelevant to engineers building cloud-style distributed systems and cloud applications. It contends that systems can provide both strong consistency and uncompromised availability to clients on the majority side of a partition, while noting that CAP is more applicable to intermittently connected mobile and IoT applications. It also highlights how differing definitions of availability create confusion. ### Source excerpt Let's Consign CAP to the Cabinet of Curiosities CAP? Again? Still? Brewer's CAP theorem, and Gilbert and Lynch's formalization of it, is the first introduction to hard trade-offs for many distributed systems engineers. Going by the vast amounts of ink and bile spent on the topic, it is not unreasonable for new folks to conclude that it's an important, foundational, idea. The reality is that CAP is nearly irrelevant for almost all engineers building cloud-style distributed systems, and applications on the cloud. It's much closer to relevant for developers of intermittently connected mobile and IoT applications, and space where the trade-off is typically seen as common sense already. We'll start with this excellent diagram from Bernstein and Das's Rethinking Eventual Consistency: CAP interests itself in the first two boxes. If there's no partition (everybody can speak to everybody), we're OK. Where CAP goes off the rails is the second box: if a quorum of replicas is available to the client, they can still get both strong consistency, and uncompromised availability. What do we mean when we say Available? Consider the quorum system below. We have seven clients. Six are on the majority (quorum1) side, and are smiling because they can enjoy both availability and strong consistency (provided the system doesn't allow the seventh client to write). The frowning client is out in the cold. They can get stale reads, but can't write, so they're frowning. The formalized CAP theorem would call this system unavailable, based on their definition of availability: every request received by a non-failing node in the system must result in a response. Most engineers, operators, and six of seven clients, would call this system available. This difference in definitions for a common everyday term causes no end of confusion. Including among those who (incorrectly) claim that this system can't offer consistency and availability to the six happy clients. It can. Can we make the seventh client h ## How to load-balance across multiple availability zones for improved redundancy DevFeed: [How to load-balance across multiple availability zones for improved redundancy]() Original publisher: [Read original article]() Author: Andre Newman Published: 2024-07-11T00:00:00Z Content type: article Language: en Sources: [Gremlin Blog]() Topics: [Availability](), [Cloud](), [Amazon Web Services](), [VPC](), [Amazon EC2](), [networking](), [Routing (disambiguation)](), [Kubernetes]() Tags: [availability](), [aws](), [blog](), [cloud](), [data-center](), [how-to](), [kubernetes](), [load-balancer](), [network](), [reliability-management](), [routing](), [vpc]() ### AI overview This blog explains cross-zone load balancing across multiple availability zones, including how it improves redundancy, reliability, and resource utilization. It uses AWS examples involving VPCs, EC2 instances, and Application Load Balancers, and describes how to enable the feature. ### Source excerpt Load balancers are great at distributing traffic across individual hosts, but what about zones? This blog explains cross-zone load balancing, and how it can help you improve throughput and reliability. [Next page]()