<?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>Systemantics on Brave New Geek</title><link>https://bravenewgeek.com/tag/systemantics/</link><description>Recent content in Systemantics on Brave New Geek</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Fri, 23 Feb 2018 16:10:13 -0600</lastBuildDate><atom:link href="https://bravenewgeek.com/tag/systemantics/index.xml" rel="self" type="application/rss+xml"/><item><title>Building a Distributed Log from Scratch, Part 4: Trade-Offs and Lessons Learned</title><link>https://bravenewgeek.com/building-a-distributed-log-from-scratch-part-4-trade-offs-and-lessons-learned/</link><pubDate>Thu, 18 Jan 2018 16:01:13 -0600</pubDate><guid>https://bravenewgeek.com/building-a-distributed-log-from-scratch-part-4-trade-offs-and-lessons-learned/</guid><description>&lt;p&gt;In &lt;a href="https://bravenewgeek.com/building-a-distributed-log-from-scratch-part-3-scaling-message-delivery/"&gt;part three&lt;/a&gt; of this series we talked about scaling message delivery in a distributed log. In part four, we’ll look at some key trade-offs involved with such systems and discuss a few lessons learned while building NATS Streaming.&lt;/p&gt;
&lt;h3 id="competing-goals"&gt;Competing Goals&lt;/h3&gt;
&lt;p&gt;There are a number of competing goals when building a distributed log (these goals also extend to many other types of systems). Recall from &lt;a href="https://bravenewgeek.com/building-a-distributed-log-from-scratch-part-1-storage-mechanics/"&gt;part one&lt;/a&gt; that our key priorities for this type of system are performance, high availability, and scalability. The preceding parts of this series described at various levels how we can accomplish these three goals, but astute readers likely noticed that some of these things conflict with one another.&lt;/p&gt;</description></item><item><title>You Are Not Paid to Write Code</title><link>https://bravenewgeek.com/you-are-not-paid-to-write-code/</link><pubDate>Wed, 16 Nov 2016 22:20:11 -0600</pubDate><guid>https://bravenewgeek.com/you-are-not-paid-to-write-code/</guid><description>&lt;p&gt;&lt;a href="http://widgetsandshit.com/teddziuba/2010/10/taco-bell-programming.html"&gt;“Taco Bell Programming”&lt;/a&gt; is the idea that we can solve many of the problems we face as software engineers with clever reconfigurations of the same basic Unix tools. The name comes from the fact that every item on the menu at Taco Bell, a company which generates almost &lt;em&gt;$2 billion&lt;/em&gt; in revenue annually, is simply a different configuration of roughly eight ingredients.&lt;/p&gt;
&lt;p&gt;Many people grumble or reject the notion of using proven tools or techniques. It’s boring. It requires investing time to learn at the expense of shipping code.  It doesn’t do this one thing that we need it to do. It won’t work for us. For some reason—and I continue to be &lt;em&gt;completely baffled&lt;/em&gt; by this—everyone sees their situation as a unique snowflake despite the fact that a million other people have probably done the same thing. It’s a weird form of tunnel vision, and I see it at every level in the organization. I catch myself doing it on occasion too. I think it’s just human nature.&lt;/p&gt;</description></item></channel></rss>