<?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>Resilience Engineering on Brave New Geek</title><link>https://bravenewgeek.com/tag/resilience-engineering/</link><description>Recent content in Resilience Engineering on Brave New Geek</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Fri, 23 Dec 2016 12:05:50 -0600</lastBuildDate><atom:link href="https://bravenewgeek.com/tag/resilience-engineering/index.xml" rel="self" type="application/rss+xml"/><item><title>Take It to the Limit: Considerations for Building Reliable Systems</title><link>https://bravenewgeek.com/take-it-to-the-limit-considerations-for-building-reliable-systems/</link><pubDate>Tue, 20 Dec 2016 19:55:52 -0600</pubDate><guid>https://bravenewgeek.com/take-it-to-the-limit-considerations-for-building-reliable-systems/</guid><description>&lt;p&gt;Complex systems usually operate in failure mode. This is because a complex system typically consists of many discrete pieces, each of which can fail in isolation (or in concert). In a microservice architecture where a given function potentially comprises several independent service calls, &lt;em&gt;high&lt;/em&gt; availability hinges on the ability to be &lt;em&gt;partially&lt;/em&gt; available. This is a core tenet behind resilience engineering. If a function depends on three services, each with a reliability of 90%, 95%, and 99%, respectively, partial availability could be the difference between 99.995% reliability and 84% reliability (assuming failures are independent). Resilience engineering means designing with failure as the normal.&lt;/p&gt;</description></item><item><title>Designed to Fail</title><link>https://bravenewgeek.com/designed-to-fail/</link><pubDate>Tue, 21 Jul 2015 20:17:17 -0500</pubDate><guid>https://bravenewgeek.com/designed-to-fail/</guid><description>&lt;p&gt;When it comes to reliability engineering, people often talk about things like fault injection, monitoring, and operations runbooks. These are all critical pieces for building systems which can withstand failure, but what’s less talked about is the need to design systems which &lt;em&gt;deliberately&lt;/em&gt; fail.&lt;/p&gt;
&lt;p&gt;Reliability design has a natural progression which closely follows that of architectural design. With monolithic systems, we care more about preventing failure from occurring. With service-oriented architectures, controlling failure becomes less manageable, so instead we learn to anticipate it. With highly distributed microservice architectures where failure is all but guaranteed, we &lt;em&gt;embrace&lt;/em&gt; it.&lt;/p&gt;</description></item></channel></rss>