<?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>Consistency on Brave New Geek</title><link>https://bravenewgeek.com/tag/consistency/</link><description>Recent content in Consistency on Brave New Geek</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Fri, 23 Feb 2018 16:09:46 -0600</lastBuildDate><atom:link href="https://bravenewgeek.com/tag/consistency/index.xml" rel="self" type="application/rss+xml"/><item><title>Building a Distributed Log from Scratch, Part 2: Data Replication</title><link>https://bravenewgeek.com/building-a-distributed-log-from-scratch-part-2-data-replication/</link><pubDate>Wed, 27 Dec 2017 12:26:55 -0600</pubDate><guid>https://bravenewgeek.com/building-a-distributed-log-from-scratch-part-2-data-replication/</guid><description>&lt;p&gt;In &lt;a href="https://bravenewgeek.com/building-a-distributed-log-from-scratch-part-1-storage-mechanics/"&gt;part one&lt;/a&gt; of this series we introduced the idea of a message log, touched on why it’s useful, and discussed the storage mechanics behind it. In part two, we discuss data replication.&lt;/p&gt;
&lt;p&gt;We have our log. We know how to write data to it and read it back as well as how data is persisted. The caveat to this is, although we have a durable log, it’s a single point of failure (SPOF). If the machine where the log data is stored dies, we’re SOL. Recall that one of our three priorities with this system is high availability, so the question is how do we achieve high availability and fault tolerance?&lt;/p&gt;</description></item><item><title>Distributed Systems Are a UX Problem</title><link>https://bravenewgeek.com/distributed-systems-are-a-ux-problem/</link><pubDate>Wed, 03 Jun 2015 19:33:29 -0500</pubDate><guid>https://bravenewgeek.com/distributed-systems-are-a-ux-problem/</guid><description>&lt;p&gt;Distributed systems are not strictly an engineering problem. It’s far too easy to assume a “backend” development concern, but the reality is there are implications at every point in the stack. Often the trade-offs we make lower in the stack in order to buy responsiveness bubble up to the top—so much, in fact, that it rarely &lt;em&gt;doesn’t&lt;/em&gt; impact the application in some way. Distributed systems affect the user. We need to shift the focus from system properties and guarantees to business rules and application behavior. We need to understand the limitations and trade-offs at each level in the stack and why they exist. We need to assume failure and plan for recovery. &lt;strong&gt;We need to start thinking of distributed systems as a UX problem.&lt;/strong&gt;&lt;/p&gt;</description></item><item><title>If State Is Hell, SOA Is Satan</title><link>https://bravenewgeek.com/if-state-is-hell-soa-is-satan/</link><pubDate>Sun, 08 Mar 2015 12:33:18 -0600</pubDate><guid>https://bravenewgeek.com/if-state-is-hell-soa-is-satan/</guid><description>&lt;p&gt;More and more companies are describing their &lt;a href="http://nginx.com/blog/microservices-at-netflix-architectural-best-practices/"&gt;success stories&lt;/a&gt; regarding the switch to a service-oriented architecture. As with any technological upswing, there’s a clear and palpable hype factor involved (Big Data™ or The Cloud™ anyone?), but obviously it’s not just puff.&lt;/p&gt;
&lt;p&gt;While microservices and SOA have seen a staggering &lt;a href="http://www.enterprisecioforum.com/en/blogs/enadhan/secrets-behind-rapid-growth-soa"&gt;rate of adoption&lt;/a&gt; in recent years, the mindset of developers often seems to be stuck in the past. I think this is, at least in part, because we seek a mental model we can reason about. It’s why we build abstractions in the first place. In a sense, I would argue there’s a comparison to be made between the explosion of OOP in the early 90’s and today’s SOA trend. After all, &lt;strong&gt;SOA is as much about people scale as it is about workload scale&lt;/strong&gt;, so it makes sense from an organizational perspective.&lt;/p&gt;</description></item><item><title>From Mainframe to Microservice: An Introduction to Distributed Systems</title><link>https://bravenewgeek.com/from-mainframe-to-microservice-an-introduction-to-distributed-systems/</link><pubDate>Sat, 01 Nov 2014 18:12:38 -0600</pubDate><guid>https://bravenewgeek.com/from-mainframe-to-microservice-an-introduction-to-distributed-systems/</guid><description>&lt;p&gt;I gave a talk at &lt;a href="http://iowacodecamp.com/"&gt;Iowa Code Camp&lt;/a&gt; this weekend on distributed systems. It was primarily an introduction to them, so it explored some core concepts at a high level.  We looked at why distributed systems are difficult to build (right), the CAP theorem, consensus, scaling shared data and CRDTs.&lt;/p&gt;
&lt;p&gt;There was some interest in making the slides available online. I’m not sure how useful they are without narration, but here they are anyway for posterity.&lt;/p&gt;</description></item><item><title>Distributed Messaging with ZeroMQ</title><link>https://bravenewgeek.com/distributed-messaging-with-zeromq/</link><pubDate>Wed, 11 Jun 2014 16:56:03 -0600</pubDate><guid>https://bravenewgeek.com/distributed-messaging-with-zeromq/</guid><description>&lt;blockquote&gt;
&lt;p&gt;&lt;em&gt;“A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable.” -Leslie Lamport&lt;/em&gt;&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;With the increased prevalence and accessibility of cloud computing, distributed systems architecture has largely supplanted more monolithic constructs. The implication of using a service-oriented architecture, of course, is that you now have to deal with a myriad of difficulties that previously never existed, such as fault tolerance, availability, and horizontal scaling. Another interesting layer of complexity is providing consistency across nodes, which itself is a problem surrounded with endless research. Algorithms like &lt;a href="http://en.wikipedia.org/wiki/Paxos_(computer_science)"&gt;Paxos&lt;/a&gt; and &lt;a href="https://ramcloud.stanford.edu/wiki/download/attachments/11370504/raft.pdf"&gt;Raft&lt;/a&gt; attempt to provide solutions for managing replicated data, while other solutions offer eventual consistency.&lt;/p&gt;</description></item></channel></rss>