<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>blog.lusis.org</title><link>https://blog.lusis.org/</link><description>Recent content on blog.lusis.org</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Sun, 15 May 2016 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.lusis.org/index.xml" rel="self" type="application/rss+xml"/><item><title>So you wanna go on-prem do ya</title><link>https://blog.lusis.org/blog/2016/05/15/so-you-wanna-go-onprem-do-ya/</link><pubDate>Sun, 15 May 2016 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2016/05/15/so-you-wanna-go-onprem-do-ya/</guid><description>If you run a successful SaaS platform, at some point someone is going to come to you with the question: can I run it myself? If you&amp;#8217;re considering offering a private version of your SaaS, this post might be for you.
At this point, I&amp;#8217;ve worked for a few companies that are SaaS vendors. In most cases, we&amp;#8217;ve also done some sort of private install.
Drivers for private installs There are a lot of reasons people want private installs.</description></item><item><title>Review Site Reliability Engineering</title><link>https://blog.lusis.org/blog/2016/04/17/review-site-reliability-engineering/</link><pubDate>Sun, 17 Apr 2016 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2016/04/17/review-site-reliability-engineering/</guid><description>This is a first for me. I&amp;rsquo;ve never reviewed a book before. There&amp;rsquo;s an uncomfortable amount of arrogance I feel in doing so but I thought it was important.
Recently the Site Reliability Engineering book came out. This is the description directly from the O&amp;rsquo;Reilly site:
{% blockquote %} In this collection of essays and articles, key members of Google’s Site Reliability Team explain how and why their commitment to the entire lifecycle has enabled the company to successfully build, deploy, monitor, and maintain some of the largest software systems in the world.</description></item><item><title>How Is Rundeck Formed</title><link>https://blog.lusis.org/blog/2016/04/07/how-is-rundeck-formed/</link><pubDate>Thu, 07 Apr 2016 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2016/04/07/how-is-rundeck-formed/</guid><description>I&amp;rsquo;ve mentioned a few times across various tweets that I&amp;rsquo;m a big fan of Rundeck. Since a few folks have asked why/how we use it I figured a blog post is better
What is rundeck? The way I typically describe rundeck is &amp;ldquo;a web interface for shell scripts&amp;rdquo;. That&amp;rsquo;s a bit unfair but that&amp;rsquo;s the simplest thing for people to grok. If I recall correctly most of the concepts of rundeck were spun out of a larger product from DTO Solutions called Control Tier.</description></item><item><title>Aws Apigateway for Fun and Profit</title><link>https://blog.lusis.org/blog/2015/12/09/aws-apigateway-for-fun-and-profit/</link><pubDate>Wed, 09 Dec 2015 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2015/12/09/aws-apigateway-for-fun-and-profit/</guid><description>At we&amp;rsquo;re currently in the process of reconfiguring our monitoring, logging and alerting setup.
Obviously this is something near and dear to my heart. At my previous employer we did everything in house due to various constraints. I&amp;rsquo;ve got a rich set of experiences in this space so my first inclination was to build not buy. However, due to OTHER constraints, building was not a practical solution at present.
After much research and evaluation, we finally settled on the following stack:</description></item><item><title>Current Status</title><link>https://blog.lusis.org/blog/2015/10/12/current-status/</link><pubDate>Mon, 12 Oct 2015 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2015/10/12/current-status/</guid><description>I just realized it&amp;rsquo;s been almost a year since I wrote a blog post</description></item><item><title>Terraform modules for fun and profit</title><link>https://blog.lusis.org/blog/2015/10/12/terraform-modules-for-fun-and-profit/</link><pubDate>Mon, 12 Oct 2015 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2015/10/12/terraform-modules-for-fun-and-profit/</guid><description>I&amp;rsquo;ve been using it for a while on a smaller scale but a recent project at work had me putting it through its paces and working out the issues I had. A few of my issues in the past have revolved around:
reusability composability lifecycle &amp;ldquo;safety&amp;rdquo; (i.e. don&amp;rsquo;t blow away an entire running stack accidentally) scope Scope One of the mistakes I made when first using terraform was trying to &amp;ldquo;do too much&amp;rdquo; with it.</description></item><item><title>A Few Things</title><link>https://blog.lusis.org/blog/2014/11/21/a-few-things/</link><pubDate>Fri, 21 Nov 2014 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2014/11/21/a-few-things/</guid><description>I can&amp;rsquo;t believe I have to even write this
but it seems that comprehension is hard and sadly I made the mistake of reading comments when someone posted my systemd redux article on HN.
CoreOS Yes I know CoreOS uses systemd. It seems that ONE comment got taken entirely out of context. If you take it WITH the context of the whole post:
If you must use Linux And we&amp;rsquo;ve agreed that systemd is here to stay in Linux Use a Linux &amp;ldquo;distro&amp;rdquo; where you don&amp;rsquo;t care that it&amp;rsquo;s running systemd CoreOS is not a traditional general purpose Linux.</description></item><item><title>Systemd Redux</title><link>https://blog.lusis.org/blog/2014/11/20/systemd-redux/</link><pubDate>Thu, 20 Nov 2014 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2014/11/20/systemd-redux/</guid><description>I figured it was about time for a followup on my systemd post. I&amp;rsquo;ve been meaning to do it for a while but time hasn&amp;rsquo;t allowed.
The end of Linux Some people wrongly characterized this as some sort of hyperbole. It was not. Systemd IS changing what we know as Linux today. It remains to be seen if this is a good or bad thing but Linux is becoming something different than it was.</description></item><item><title>Software Empathy</title><link>https://blog.lusis.org/blog/2014/10/19/software-empathy/</link><pubDate>Sun, 19 Oct 2014 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2014/10/19/software-empathy/</guid><description>Over the past several months, I&amp;rsquo;ve written a lot of blog posts that were critical of various software. If it wasn&amp;rsquo;t clear from these (sometimes) incoherent ramblings, there was a common thread that bound them all together
Why do we write software? I write software every now and then. When I do, if possible, I put it up on github for folks to consume. I&amp;rsquo;ve talked about this before. For me, being able to write code and somehow that code helps someone blows my mind.</description></item><item><title>End of Linux</title><link>https://blog.lusis.org/blog/2014/09/23/end-of-linux/</link><pubDate>Tue, 23 Sep 2014 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2014/09/23/end-of-linux/</guid><description>I&amp;rsquo;ve done a lot of tweeting about systemd lately. My internal conscience constantly reminds me of John Allspaw saying that twitter is just pretty much perfect for snarky comments (paraphrase).
Al Tobey asked me a good question:
{% blockquote %} I honestly want to know why you dislike it so much. You clearly know wtf is going on. I haven&amp;rsquo;t heard a specific technical problem. {% endblockquote %}
First mistake is thinking I know wtf is going on.</description></item><item><title>Berks</title><link>https://blog.lusis.org/blog/2014/07/15/berks/</link><pubDate>Tue, 15 Jul 2014 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2014/07/15/berks/</guid><description>Note this post has comments disabled. This is a first for me but if someone wants to ask me anything else, there are multiple personal ways to contact me.
Recently I posted a message to the chef-users mailing list. It was a hard post for me to write because I was attempting to be as tactful as possible about the issue. While I think it was the right move and some good came out of it, I now feel like I have to defend myself for some reason.</description></item><item><title>Feedback on Paas Realism</title><link>https://blog.lusis.org/blog/2014/06/22/feedback-on-paas-realism/</link><pubDate>Sun, 22 Jun 2014 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2014/06/22/feedback-on-paas-realism/</guid><description>I&amp;rsquo;ve gotten quite a bit of constructive feedback on the PaaS realism post and I wanted to aggregate it here.
OpenShift I was humbled to see a very awesome post from Luke Meyer who works on the OpenShift team. I think if you are going to deploy OpenShift, his post is very important to read.
I wanted to respond to a few points specifically he made (and again say thank you for taking the time to respond/educate me)</description></item><item><title>Paas for Realists</title><link>https://blog.lusis.org/blog/2014/06/14/paas-for-realists/</link><pubDate>Sat, 14 Jun 2014 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2014/06/14/paas-for-realists/</guid><description>I realize I was pretty down on PaaS the past couple of days. Lest I send the wrong message, I figure a clarification is in order
Before we start, we should define some things. It&amp;rsquo;s always important to be on the same page:
PaaS: Platform as a Service (no distinction between public or private). When talking about public, it&amp;rsquo;s usually Heroku. Private PaaS: A PaaS run &amp;ldquo;in-house&amp;rdquo;. I&amp;rsquo;m using &amp;ldquo;in-house&amp;rdquo; loosely here.</description></item><item><title>No Konami for Operations</title><link>https://blog.lusis.org/blog/2014/06/13/no-konami-for-operations/</link><pubDate>Fri, 13 Jun 2014 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2014/06/13/no-konami-for-operations/</guid><description>up up down down left right left right b a select start
I went on a bit of a rip today about all sorts of technology. I figured I should at least clarify some of it in long form.
Vmotion/live migration technologies Vmotion is a scam. I have frequently said that only trivial workloads are safe for vmotion. Here&amp;rsquo;s the reasoning:
live migration realistically requires the workload on the vm being migrated to be quiesced.</description></item><item><title>Omnibus Redux</title><link>https://blog.lusis.org/blog/2014/04/13/omnibus-redux/</link><pubDate>Sun, 13 Apr 2014 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2014/04/13/omnibus-redux/</guid><description>I&amp;rsquo;ve been a pretty big proponent of omnibus. I still think it&amp;rsquo;s the right way to go but recent changes have removed the primary reason for recommending it
I did a lot of evangelism for omnibus last year. Presentations, blogposts, a sysadvent article. It is/was a great tool however it no longer fits the primary usecase.
Original workflow Originally the biggest benefit to omnibus (outside of the core of what it did) was the Vagrantfile it generated.</description></item><item><title>Stop Fighting Distros Part 2</title><link>https://blog.lusis.org/blog/2013/09/23/stop-fighting-distros-part-2/</link><pubDate>Mon, 23 Sep 2013 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2013/09/23/stop-fighting-distros-part-2/</guid><description>I&amp;rsquo;m a pretty harsh person. My wife and I have this discussion all the time about how things I say get interpreted. As the communicator, this responsibility lies squarely on my shoulders.
So before I start, I don&amp;rsquo;t &amp;ldquo;hate&amp;rdquo; distributions or the packaging format they use or the people doing the work. To this even of you who toil to track countless security reports or maintain some software package in an upstream repository because of your love for that software, here&amp;rsquo;s to you.</description></item><item><title>A Historical Compendium of Useless Shit</title><link>https://blog.lusis.org/blog/2013/09/17/a-historical-compendium-of-useless-shit/</link><pubDate>Tue, 17 Sep 2013 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2013/09/17/a-historical-compendium-of-useless-shit/</guid><description>Yes it started on Twitter and ended up here. Circle of life and all that
Fair warning: I&amp;rsquo;m not doing ANY research for this post. Normally I do but I&amp;rsquo;m doing this off-the-cuff so to speak. If I fuck up some specific thing, please feel free to correct. This is basically a personal perspective/history And it&amp;rsquo;s probably full of typos so there&amp;rsquo;s that
So a discussion on twitter started because I brought up Mesos, Docker and OSv.</description></item><item><title>Go for System Administrators</title><link>https://blog.lusis.org/blog/2013/08/11/go-for-system-administrators/</link><pubDate>Sun, 11 Aug 2013 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2013/08/11/go-for-system-administrators/</guid><description>{% blockquote %} If I never directly touch a Go concurrency primitive, I&amp;rsquo;m convinced I&amp;rsquo;m going to write all my cli apps with it just for ease of deployment. {% endblockquote %}
This is something I said the other day. I figured it deserved a more detailed blog post.
NKOTB Most people who know me professionally know two things about me:
I&amp;rsquo;m fairly pragmatic and somewhat conservative about technology decisions I&amp;rsquo;m a language tourist This second one is something Bryan Berry attributed to me in an early FoodFight episode.</description></item><item><title>Devops the Title Match</title><link>https://blog.lusis.org/blog/2013/06/04/devops-the-title-match/</link><pubDate>Tue, 04 Jun 2013 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2013/06/04/devops-the-title-match/</guid><description>I&amp;rsquo;ve noticed an annoying trend recently. I was content to ignore it for a while but now it&amp;rsquo;s getting almost stupid. That trend is the job title of &amp;ldquo;DevOps&amp;rdquo;.
I came across an article tonight that confused the hell out of me. It was an interview. The outlet wasn&amp;rsquo;t a technical one per se but it was a technical interview none the less.
This part is what confused me (highlights mine):</description></item><item><title>Smart Clients</title><link>https://blog.lusis.org/blog/2013/05/13/smart-clients/</link><pubDate>Mon, 13 May 2013 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2013/05/13/smart-clients/</guid><description>&lt;p>Currently &lt;a href="http://ricon.io/east.html">RICON|EAST&lt;/a> is going on in NYC. &lt;a href="https://twitter.com/tsantero">Tom Santero&lt;/a> and the whole Basho crew is doing an awesome job if the content available via the live stream and twitters is to be believed.&lt;/p></description></item><item><title>Future of Noah</title><link>https://blog.lusis.org/blog/2013/01/20/future-of-noah/</link><pubDate>Sun, 20 Jan 2013 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2013/01/20/future-of-noah/</guid><description>This is probably the most difficult blog post I&amp;rsquo;ve had to write. What&amp;rsquo;s worse is I&amp;rsquo;ve been sitting on it for months.
When I started Noah a few years ago, I had a head full of steam. I had some grand ideas but was trying to keep things realistic. I simply wanted a simple REST-ish interface for stashing nuggets of information between systems and a flexible way to notify interested parties when that information changed.</description></item><item><title>How We Vagrant</title><link>https://blog.lusis.org/blog/2012/12/17/how-we-vagrant/</link><pubDate>Mon, 17 Dec 2012 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2012/12/17/how-we-vagrant/</guid><description>People may or may not have noticed but I&amp;rsquo;ve been largely offline for the past 4 weeks or so. This is because I&amp;rsquo;ve been in the middle of a pretty heavy redesign of a few key parts of our application stack. This also required me to learn Java so I&amp;rsquo;ve been doubly slammed.
As part of that redesign, I worked on what we lovingly refer to internally as the &amp;ldquo;solo installer&amp;rdquo;.</description></item><item><title>What Production Means</title><link>https://blog.lusis.org/blog/2012/07/09/what-production-means/</link><pubDate>Mon, 09 Jul 2012 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2012/07/09/what-production-means/</guid><description>This post is something that&amp;rsquo;s been brewing for a while. While it may sound targeted in tone, it&amp;rsquo;s more general than that. Let&amp;rsquo;s just call it an open letter to family, friends and coworkers around the world.
One thing that I have the hardest time communicating to friends and family who aren&amp;rsquo;t in the IT industry is the concept of &amp;ldquo;production&amp;rdquo; and what it means to be on-call. Even coworkers have a hard time understanding what it means.</description></item><item><title>Why Ebs Was a Bad Idea</title><link>https://blog.lusis.org/blog/2012/06/15/why-ebs-was-a-bad-idea/</link><pubDate>Fri, 15 Jun 2012 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2012/06/15/why-ebs-was-a-bad-idea/</guid><description>Since I just tweeted about this and I know people would want an explaination, I figured I&amp;rsquo;d short circuit 140 character hell and explain why I think EBS was the worst thing Amazon ever did to AWS.
First time I&amp;rsquo;ve had to do this but: the following is my personal opinion and in no way reflects any policy or position of my employer
A journey through time I remember when EC2 was first unleashed.</description></item><item><title>Monitoring Sucking Just a Little Bit Less</title><link>https://blog.lusis.org/blog/2012/06/05/monitoring-sucking-just-a-little-bit-less/</link><pubDate>Tue, 05 Jun 2012 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2012/06/05/monitoring-sucking-just-a-little-bit-less/</guid><description>&lt;p>So &lt;a href="http://blog.zenoss.com/2012/06/turning-monitoringsucks-into-monitoringsucksless">it&amp;rsquo;s come to my attention&lt;/a> that today is the &amp;ldquo;anniversary&amp;rdquo; of when I wrote my &lt;a href="http://blog.lusis.org/blog/2011/06/05/why-monitoring-sucks/">first &amp;ldquo;#monitoringsucks&amp;rdquo; blog post&lt;/a>.&lt;/p></description></item><item><title>Configuration Drift and Next Gen Cm</title><link>https://blog.lusis.org/blog/2012/05/24/configuration-drift-and-next-gen-cm/</link><pubDate>Thu, 24 May 2012 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2012/05/24/configuration-drift-and-next-gen-cm/</guid><description>It always starts with a tweet. However it normally doesn&amp;rsquo;t start with a tweet from Cliff Moon.
{% blockquote %} Of all the problems to fix in chef or puppet, the diffusion and drift of state that occurs in idiomatic usage seems highest priority. {% endblockquote %}
Now for sure what spawned this comment was something unrelated but it got me thinking. Oddly enough Tim Dysinger was either poking around in my head or just had the same idea:</description></item><item><title>It Sucks to Be Right</title><link>https://blog.lusis.org/blog/2012/03/20/it-sucks-to-be-right/</link><pubDate>Tue, 20 Mar 2012 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2012/03/20/it-sucks-to-be-right/</guid><description>So it looks like Adrian Cockcroft finally spilled the beans on Netflix (no)Operations and sadly it reads like I expected.
Netflix still does operations Regardless of what words Adrian uses, Netflix still does operations. John Allspaw summed it up pretty well in this tweet:
and here are the things, he mentions:
Metrics collection PaaS/IaaS evaluation/investigation Automation (auto-build, auto-recovery) Fault tolerance Availability Monitoring Performance Capex and Opex forecasting Outage response So what does Adrian get wrong?</description></item><item><title>Why You Should Stop Fighting Distro Vendors</title><link>https://blog.lusis.org/blog/2012/03/16/why-you-should-stop-fighting-distro-vendors/</link><pubDate>Fri, 16 Mar 2012 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2012/03/16/why-you-should-stop-fighting-distro-vendors/</guid><description>Recently I saw a tweet from Kohsuke Kawaguchi that really got me frustrated.
I&amp;rsquo;ve addressed this topic a bit before here. At the time it was addressing specifically dynamic languages. However the post that Kohsuke wrote (and the post that inspired it) have led me to a new line attitude.
Don&amp;rsquo;t bother trying to get your packages into upstream vendor distros
Wait. What? Let&amp;rsquo;s step back a sec Let me clarify something first.</description></item><item><title>Graphs in Operations</title><link>https://blog.lusis.org/blog/2012/03/06/graphs-in-operations/</link><pubDate>Tue, 06 Mar 2012 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2012/03/06/graphs-in-operations/</guid><description>So anyone who knows me knows I spend an inordinate amount of time bitching about Maven. I don&amp;rsquo;t know if it&amp;rsquo;s the type of companies I end up working for or what but I always seem to find myself ass-deep in Maven.
please note that I&amp;rsquo;m drifiting into deeply unfamiliar territory for me. Someone once told me the best way to learn about something is to write about it. Keep that in mind when making comments?</description></item><item><title>Zeromq and Logstash Part 2</title><link>https://blog.lusis.org/blog/2012/02/08/zeromq-and-logstash-part-2/</link><pubDate>Wed, 08 Feb 2012 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2012/02/08/zeromq-and-logstash-part-2/</guid><description>A few days ago I wrote up some notes on how we&amp;rsquo;re making Logstash better by adding ZeroMQ as an option for inputs and outputs. That night we decided to take it a bit further and add support for ZeroMQ as a filter plugin as well.
I&amp;rsquo;ve had a lot of people ask me what&amp;rsquo;s so hot about ZeroMQ. It&amp;rsquo;s hard to explain but I really would suggest you read the excellent zguide.</description></item><item><title>Zeromq and Logstash Part 1</title><link>https://blog.lusis.org/blog/2012/02/06/zeromq-and-logstash-part-1/</link><pubDate>Mon, 06 Feb 2012 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2012/02/06/zeromq-and-logstash-part-1/</guid><description>Every once in a while, a software project comes along that makes you rethink how you&amp;rsquo;ve done things up until that point. I&amp;rsquo;ve often said that ElasticSearch was the first of those projects for me. The other is ZeroMQ.
Edit and update Evidently my testing missed a pretty critical usecase - pubsub. It doesn&amp;rsquo;t work right now. Due to the way we&amp;rsquo;re doing sockopts works for setting topics. However we don&amp;rsquo;t have a commensurate setting on the PUB side.</description></item><item><title>Load Balancing Logstash With Amqp</title><link>https://blog.lusis.org/blog/2012/01/31/load-balancing-logstash-with-amqp/</link><pubDate>Tue, 31 Jan 2012 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2012/01/31/load-balancing-logstash-with-amqp/</guid><description>AMQP in Logstash is one of the most complicated parts of the workflow. I&amp;rsquo;ve taken it on myself, as the person with the most AMQP experience (both RabbitMQ and Qpid) to try and explain as much as need for logstash users.
Patrick DeBois hit me up with a common logstash design pattern that I felt warranted a full detailed post.
Warning: This is an image heavy post. Terminal screenshots are linked to larger versions</description></item><item><title>Load Balancing Logstash With Redis</title><link>https://blog.lusis.org/blog/2012/01/31/load-balancing-logstash-with-redis/</link><pubDate>Tue, 31 Jan 2012 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2012/01/31/load-balancing-logstash-with-redis/</guid><description>After yesterday&amp;rsquo;s post about load balancing logstash with AMQP and RabbitMQ, I got to thinking that it might be useful to show a smilar pattern with other inputs and outputs. To me this, is the crux of what makes Logstash so awesome. Someone asked me to describe Logstash in one sentence. The best I could come up with was:
{% blockquote %} Logstash is a unix pipe on steroids {% endblockquote %}</description></item><item><title>Lowtech Monitoring With Jenkins</title><link>https://blog.lusis.org/blog/2012/01/23/lowtech-monitoring-with-jenkins/</link><pubDate>Mon, 23 Jan 2012 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2012/01/23/lowtech-monitoring-with-jenkins/</guid><description>I mentioned briefly in my previous post that I got quite a few people coming up to me after the panel and asking me for advice on monitoring.
I tweeted about this scenario not long after it happened but here&amp;rsquo;s the gist:
{% blockquote %} I just need something simple to check on the status of a few jobs and run some SQL statements. I&amp;rsquo;m a DBA and I can&amp;rsquo;t get any help from my ops team.</description></item><item><title>Scale10x Recap</title><link>https://blog.lusis.org/blog/2012/01/22/scale10x-recap/</link><pubDate>Sun, 22 Jan 2012 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2012/01/22/scale10x-recap/</guid><description>This past week I had the awesome pleasure of participating in my first SoCal Linux Expo. As I later discovered, this was the 10th installment of this awesome event (hence the 10x).
The email and enStratus I got an email from Ilan Rabinovitch just as things were going down with me headed to enStratus. Since the event was going to be right around the time I started, I pretty much put it out of my mind.</description></item><item><title>2011 in Review</title><link>https://blog.lusis.org/blog/2012/01/02/2011-in-review/</link><pubDate>Mon, 02 Jan 2012 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2012/01/02/2011-in-review/</guid><description>The holidays are a busy time for me. I was hoping to get this written before the end of the year but it didn&amp;rsquo;t happen.
I can say, wihtout a doubt, that 2011 has been the most awesome year both professionally and personally in my life. And I have pretty much everyone else to thank for it.
Some special shoutouts There are so many folks to thank for this year. I owe so many beers that I can&amp;rsquo;t keep count.</description></item><item><title>Github Trolling for Fun and Profit</title><link>https://blog.lusis.org/blog/2011/11/22/github-trolling-for-fun-and-profit/</link><pubDate>Tue, 22 Nov 2011 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2011/11/22/github-trolling-for-fun-and-profit/</guid><description>Last Friday was a pretty crappy day.
I&amp;rsquo;m a fairly active Twitter user.
Patrick has joked that it&amp;rsquo;s as if I have Twitter wired directly to my brain. It&amp;rsquo;s not far from the truth. I like to engage people and normally Twitter is great medium for engaging folks. Unfortunately, the message size limit makes Twitter an imperfect medium for involved discussions.
I know better but sometimes I forget.
Anyway, last friday I realized near the end of the day that I had pretty much gone off the rails.</description></item><item><title>Deploy All the Things</title><link>https://blog.lusis.org/blog/2011/10/18/deploy-all-the-things/</link><pubDate>Tue, 18 Oct 2011 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2011/10/18/deploy-all-the-things/</guid><description>&lt;p>&lt;em>This is part 2 in a post on deployment strategies. The previous post is located &lt;a href="http://blog.lusis.org/blog/2011/10/18/rollbacks-and-other-deployment-myths/">here&lt;/a>&lt;/em>&lt;/p>
&lt;p>My previous post covered some of the annoying excuses and complaints that people like to use when discussing deployments. The big take away should have been the following:&lt;/p>
&lt;ul>
&lt;li>The risk associated with deploying new code is not in the deploy itself but everything you did up to that point.&lt;/li>
&lt;li>The way to make deploying new code less risky is to do it more often, not less.&lt;/li>
&lt;li>Create a culture and environment that enables and encourages small, frequent releases.&lt;/li>
&lt;li>Everything fails. Embrace failure.&lt;/li>
&lt;li>Make deploys trivial, automated and tolerant of failure.&lt;/li>
&lt;/ul>
&lt;p>I want to make one thing perfectly clear. I&amp;rsquo;ve said this several times before. You can get 90% of the way to a fully automated environment, never go that last 10% and still be better off than you were before. I understand that people have regulations, requirements and other things that prevent a fully automated system. You don&amp;rsquo;t ever have to flip that switch but you should strive to get as close as possible.&lt;/p></description></item><item><title>Rollbacks and Other Deployment Myths</title><link>https://blog.lusis.org/blog/2011/10/18/rollbacks-and-other-deployment-myths/</link><pubDate>Tue, 18 Oct 2011 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2011/10/18/rollbacks-and-other-deployment-myths/</guid><description>&lt;p>I came across an interesting post today via HN. I&amp;rsquo;m surprised (only moderately) that I missed it the first time around since this is right up my alley:&lt;/p>
&lt;p>&lt;a href="http://briancrescimanno.com/2011/09/29/why-are-you-still-deploying-overnight/">Why are you still deploying overnight?&lt;/a>&lt;/p>
&lt;p>I thought this post was particularly apropos for several reasons. I just got back from DevOpsDays EU &lt;strong>AND&lt;/strong> I&amp;rsquo;m currently in the process of refactoring our deploy process.&lt;/p>
&lt;p>I&amp;rsquo;m breaking this up into two parts since it&amp;rsquo;s a big topic. The first one will cover the more &amp;ldquo;theoretical&amp;rdquo; aspects of the issue while the second will provide more concrete information.&lt;/p></description></item><item><title>The Configuration Management Divide</title><link>https://blog.lusis.org/blog/2011/08/22/the-configuration-management-divide/</link><pubDate>Mon, 22 Aug 2011 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2011/08/22/the-configuration-management-divide/</guid><description>wherein John admits he was wrong about something
As I was checking my Github feed tonight (as I&amp;rsquo;ve been known to do on occassion), I saw an update for a project that I was watching. This project is, for all intents and purposes, a redo of Capistrano with some additional system management stuff on top. From the description:
All together mixed to make your life easier. As mentioned before do is a fun mix of capistrano, rake, thor and brew.</description></item><item><title>Fun With Celluloid</title><link>https://blog.lusis.org/blog/2011/08/13/fun-with-celluloid/</link><pubDate>Sat, 13 Aug 2011 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2011/08/13/fun-with-celluloid/</guid><description>&lt;p>&lt;em>warning! This is a really long post&lt;/em>&lt;/p>
&lt;p>In the course of rewriting the &lt;a href="https://github.com/lusis/Noah">Noah&lt;/a> callback daemon, I started to get really frustrated with EventMachine. This is nothing against EventMachine by any stretch of the imagination. I really like it.&lt;/p>
&lt;p>What I was having issues with is making the plugin framework as dirt simple as possible. By using EM, I had no choice but to require folks to understand how EM works. This primarily meant not blocking the reactor. Additionally, through no fault of EM, I was starting to get mired in callback spaghetti.&lt;/p>
&lt;h1 id="actors">Actors&lt;/h1>
&lt;p>I&amp;rsquo;ve mentioned several times before that I love the actor model. It makes sense to me. The idea of mailboxes and message passing is really simple to understand. For a while, there was project that implemented actors on top of EM called Revactor but it stalled. I started following the author (Tony Arcieri) on GitHub to see if he would ever update it. He did not but I caught wind of his new project and it was pretty much exactly what I was looking for.&lt;/p>
&lt;p>Actors have a proven track record in Erlang and the Akka framework for Scala and Java uses them as well.&lt;/p>
&lt;h1 id="celluloid">Celluloid&lt;/h1></description></item><item><title>Migrating From Blogger</title><link>https://blog.lusis.org/blog/2011/08/13/migrating-from-blogger/</link><pubDate>Sat, 13 Aug 2011 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2011/08/13/migrating-from-blogger/</guid><description>&lt;p>Many, many years ago I started blogging. It&amp;rsquo;s fun and I like to feel self-important by dumping my ideas. I enjoy writing so blogging is cool like that.&lt;/p>
&lt;p>Over the past 12 years I&amp;rsquo;ve gone through various tools to help me do that (in no particular order):&lt;/p>
&lt;ul>
&lt;li>PHPnuke&lt;/li>
&lt;li>Postnuke&lt;/li>
&lt;li>Moveable Type&lt;/li>
&lt;li>Plone&lt;/li>
&lt;li>CakePHP&lt;/li>
&lt;li>rst2html vim plugin&lt;/li>
&lt;li>Blogger&lt;/li>
&lt;li>Wordpress&lt;/li>
&lt;li>Homegrown shit&lt;/li>
&lt;/ul>
&lt;p>With the exception of one, all of these tools were simply a pain in the ass. They required lots of moving pieces, we&amp;rsquo;re bug ridden and security nightmares.
The one tool I enjoyed the most?&lt;/p>
&lt;p>rst2html in Vim&lt;/p>
&lt;p>The only reason I used those tools was because I hated writing HTML. I hated dealing with styling. About 3 years ago I finally settled on using Blogger. Now I&amp;rsquo;m changing again.&lt;/p></description></item><item><title>Monitoring Sucks Watch Your Language</title><link>https://blog.lusis.org/blog/2011/07/21/monitoring-sucks-watch-your-language/</link><pubDate>Thu, 21 Jul 2011 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2011/07/21/monitoring-sucks-watch-your-language/</guid><description>&lt;p>&lt;em>The following post is a recap of what was discussed in the 07/21/11 #monitoringsucks irc meeting&lt;/em>&lt;/p>
&lt;p>Before I get any further, I just want to thank everyone who attended,
either in virtual person or in spirit. There have been so many awesome
discussions going around this topic since we started. I am truly
priviledged to interact with each and every one of you. I struggle to
count myself a peer and I can only hope that I provide something in
return.&lt;/p>
&lt;p>I mentioned to someone today that I’m literally sick of the current
landscape. I consider the current crop of monitoring solutions to be
technologically bankrupt. The situation is fairly untenable at this
point.&lt;/p>
&lt;p>I just installed (after having a total loss of an existing Zenoss setup)
Nagios again. I’m not joking when I say that it depressed the everliving
hell out of me. The monitoring landscape simply has not kept up with
modern developments. At first it was mildly frustrating. Then it was
annoying. Now it’s actually a detriment.&lt;/p>
&lt;p>Now that we have that out of the way….&lt;/p></description></item><item><title>Why Monitoring Sucks</title><link>https://blog.lusis.org/blog/2011/06/05/why-monitoring-sucks/</link><pubDate>Sun, 05 Jun 2011 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2011/06/05/why-monitoring-sucks/</guid><description>&lt;p>&lt;em>(and what we&amp;rsquo;re doing about it)&lt;/em>&lt;/p>
&lt;p>About two weeks ago someone made a tweet. At this point, I don&amp;rsquo;t
remember who said it but the gist was that &amp;ldquo;monitoring sucks&amp;rdquo;. I
happened to be knee-deep in frustrating bullshit around that topic and
was currently evaluating the same effing tools I&amp;rsquo;d evaluated at every
other company over the past 10 years or so. So I did what seems to be
S.O.P for me these days. I started something.&lt;/p></description></item><item><title>On Noah Part 4</title><link>https://blog.lusis.org/blog/2011/05/20/on-noah-part-4/</link><pubDate>Fri, 20 May 2011 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2011/05/20/on-noah-part-4/</guid><description>&lt;p>&lt;em>This is the fourth part in a series on Noah. &lt;a href="http://goo.gl/l3Mgt">Part 1&lt;/a>, &lt;a href="http://goo.gl/Nj2TN">Part 2&lt;/a> and &lt;a href="http://goo.gl/RsZtZ">Part 3&lt;/a> are available as well&lt;/em>&lt;/p>
&lt;p>In Part 1 and 2 of this series I covered background on Zookeeper and
discussed the similarities and differences between it and Noah. Part 3
was about the components underneath Noah that make it tick.&lt;/p>
&lt;p>This post is about the &amp;ldquo;future&amp;rdquo; of Noah. Since I&amp;rsquo;m a fan of Fourcast
podcast, I thought it would be nice to do an immediate, medium and long
term set of goals.&lt;/p></description></item><item><title>On Noah Part 3</title><link>https://blog.lusis.org/blog/2011/05/18/on-noah-part-3/</link><pubDate>Wed, 18 May 2011 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2011/05/18/on-noah-part-3/</guid><description>&lt;p>&lt;em>This is the third part in a series on Noah. &lt;a href="http://goo.gl/l3Mgt">Part 1&lt;/a> and &lt;a href="http://goo.gl/Nj2TN">Part 2&lt;/a> are available as well&lt;/em>&lt;/p>
&lt;p>In Part 1 and 2 of this series I covered background on Zookeeper and
discussed the similarities and differences between it and Noah. This
post is discussing the technology stack under Noah and the reasoning for
it.&lt;/p>
&lt;h1 id="a-little-back-story">A little back story&lt;/h1>
&lt;p>I&amp;rsquo;ve told a few people this but my original intention was to use Noah as
a way to learn Erlang. However this did not work out. I needed to get a
proof of concept out much quicker than the ramp up time it would take to
&lt;a href="http://learnyousomeerlang.com/">learn me some Erlang&lt;/a>. I had this
grandiose idea to slap mnesia, riak_core and webmachine into a tasty
ball of Zookeeper clonage.&lt;/p></description></item><item><title>On Noah Part 2</title><link>https://blog.lusis.org/blog/2011/05/17/on-noah-part-2/</link><pubDate>Tue, 17 May 2011 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2011/05/17/on-noah-part-2/</guid><description>&lt;p>&lt;em>This is the second part in a series on Noah. Part 1 is available&lt;/em> &lt;a href="http://goo.gl/l3Mgt">here&lt;/a>&lt;/p>
&lt;p>In part one of this series, I went over a little background about
ZooKeeper and how the basic Zookeeper concepts are implemented in Noah.
In this post, I want to go over a little bit about a few things that
Noah does differently.&lt;/p></description></item><item><title>On Noah Part 1</title><link>https://blog.lusis.org/blog/2011/05/16/on-noah-part-1/</link><pubDate>Mon, 16 May 2011 00:00:00 +0000</pubDate><guid>https://blog.lusis.org/blog/2011/05/16/on-noah-part-1/</guid><description>&lt;p>&lt;em>This is the first part in a series of posts going over Noah&lt;/em>&lt;/p>
&lt;p>As you may have heard (from my own mouth no less), I&amp;rsquo;ve got a smallish
side project I&amp;rsquo;ve been working on called
&lt;a href="https://github.com/lusis/Noah">Noah&lt;/a>.&lt;/p></description></item></channel></rss>