<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Middleware on Severin Bucher | Blog</title><link>https://severinbucher.com/tags/middleware/</link><description>Recent content in Middleware on Severin Bucher | Blog</description><generator>Hugo</generator><language>en</language><lastBuildDate>Fri, 30 May 2025 00:00:00 +0000</lastBuildDate><atom:link href="https://severinbucher.com/tags/middleware/index.xml" rel="self" type="application/rss+xml"/><item><title>Introducing a Baby Chaos Monkey for Our Microservices</title><link>https://severinbucher.com/posts/introducing-a-baby-chaos-monkey-for-our-microservices/</link><pubDate>Fri, 30 May 2025 00:00:00 +0000</pubDate><guid>https://severinbucher.com/posts/introducing-a-baby-chaos-monkey-for-our-microservices/</guid><description>&lt;p>In a microservice system, the only real way to know how resilient you are is to break things on purpose and watch what happens. That&amp;rsquo;s the idea behind chaos engineering. Netflix&amp;rsquo;s Chaos Monkey is the famous example: it randomly kills services in production so the team finds out early whether the system can take it.&lt;/p>
&lt;p>Killing live services is overkill for most teams, especially outside production, but the underlying idea is worth borrowing. So we added a small piece of middleware to one of our services: a manually triggered, route-level failure tool that acts like a baby Chaos Monkey.&lt;/p></description></item></channel></rss>