SRE and BDD: The Ultimate Power Pair

Reading Time: Approximately 7 minutes.

The responsibilities of a Reliability Engineer are well understood: maintain a high degree of service availability so that customers can have a consistently enjoyable and predictable experience. How these goals are accomplished — establishing SLOs with customers, enforcing them through monitoring SLIs and exercising the platform against failure through Game Days — is also well understood. Much of the literature that exists on SRE goes into great depths talking about these concepts, and for good reason: failing to establish a contract with the customer on availability expectations for the service that they are paying for is a great way for its engineers to spend their entire careers fire-fighting. … »

SRE Communities vs SRE Centers of Excellence

Reading Time: Approximately 7 minutes.

I read Google’s Site Reliability Engineering Workbook on a flight to New York the other day. I read their original book when it came out two years ago and was curious to see how much of it mirrored my own (brief) experience as a Google SRE. Given that it’s been a while since I did pure SRE work, I wanted to keep my skills caught up, and the Workbook seemed like a more accurate reference to follow. … »

Is your Java app ready for Docker? Take this super quick test!

Reading Time: Approximately 1 minutes.

Here’s a really quick test to see if your enterprise Java app is ready for Docker. NOTE: I am not a Java developer; more like a casual observer. Get your pitchforks ready! If I can’t do this: $> docker run --rm --volume "$PWD:/app" --volume "$HOME/.m2:/root/.m2" \ --tty maven:3.6.0-jdk$WHICHEVER_VERSION-alpine mvn build $> docker run --rm --volume "$PWD:/app" --tty openjdk:$WHICHEVER_VERSION-jdk-alpine \ java -jar /path/to/war.war Then either: Your application is not 12-factor and is probably not ready for Docker, Your source code has hidden dependencies that live outside of your pom. … »

Move Fast And Retain Corporate Governance with Pull Requests

Reading Time: Approximately 7 minutes.

DevOps and change control mix like oil and water. Product and development teams want to experiment with and release ideas as quickly as their customers request them, and do so with tight, but unstructured, collaboration across organizations. On the other hand, corporate governance wants auditability, transparent risk mitigation and justification in every step of the way. Consequently, both of these sides often don’t get along with each other well, hindering development speed in the progress. … »

Good Tools Are Important. Ignore At Your Own Peril

Reading Time: Approximately 7 minutes.

I’ve been consulting for some of the world’s largest companies for the last three years and have observed three themes that worry me: Agile is a really controversial word, despite the manifesto being quite clear on the matter, Somewhere within every company, there are many, many engineers that have been waiting weeks for test environments, and Engineers have the heaviest, plasticky-iest, and most unpleasant machines in the entire organization This (hopefully) brief post is about that third point. … »

neurons are firing again! How I eat my own dogfood with my blog.

Reading Time: Approximately 13 minutes.

First, huge shout out to the five of you that actually read stuff from my WordPress blog! You might have noticed that, with the exception of a a few posts for my company, I’ve been mostly silent. I haven’t given up on writing; quite the contrary, in fact! I haven’t run out of neurons to fire either (darn!). I’ve stopped writing on my own site for one reason: I pledged to not write again until I was completely out of WordPress. … »

How To Make Enterprise Container Strategies That Last, Part I

Reading Time: Approximately 11 minutes.

Intro I was in high school when I got introduced to this weird app called VMware Workstation. I thought the idea of using your Windows machine to run other machines was really compelling - a perfect fit of my younger and geekier self. You couldn’t pay me enough back then to believe that almost all[^1] of the world’s most important applications would eventually run on virtual machines…on someone else’s computers! … »

Getting output from Docker containers from within Ansible

Reading Time: Approximately 1 minutes.

The Problem

You want to use Ansible’s docker_container module to do stuff, but want to also perform actions based on their output without specifying a logging driver or writing to a temp file.

The Solution

Do this:

»

A Few Gotchas About Going Multi-Cloud with AWS, Microsoft Azure and HashiCorp tools.

Reading Time: Approximately 11 minutes.

One of the more interesting types of work we do at Contino is help our clients make sense of the differences between AWS and Microsoft Azure. While the HashiCorp toolchain (Packer, Terraform, Vault, Vagrant, Consul and Nomad) have made provisioning infrastructure a breeze compared to writing hundreds of lines of Python, they almost make achieving a multi-cloud infrastructure deployment seem too easy.

This post will outline some of the differences I’ve observed with using these tools against both cloud platforms. As well, since I used the word “multi-cloud” in my first paragraph, I’ll briefly discuss some general talking points on “things to consider” before embarking on a multi-cloud journey at the end.

»

Provisioning VMware Workstation Machines from Artifactory with Vagrant

Reading Time: Approximately 1 minutes.

I wrote a small Vagrantfile and helper library for provisioning VMware VMs from boxes hosted on Artifactory. I put this together with the intent of helping us easily provision our Rancher/Cattle/Docker-based platform wholesale on our machines to test changes before pushing them up.

Here it is: https://github.com/carlosonunez/vagrant_vmware_artifactory_example

Tests are to be added soon! I’m thinking Cucumber integration tests with unit tests on the helper methods and Vagrantfile correctness.

»

Getting Into DevOps.

Reading Time: Approximately 13 minutes.

I’ve observed a sharp uptick of developers and systems administrators interested in “getting into DevOps” within the last year or so. This pattern makes sense, too: in an age where a single developer can spin up a globally-distributed infrastructure for an application with a few dollars and a few API calls, the gap between development and systems administration is closer than ever. While I’ve seen plenty of blog posts and articles about cool DevOps tools and thoughts to think about, I’ve seen fewer content on pointers and suggestions for people looking to get into this work.

My goal with this article is to, hopefully, draw what that path looks like. My thoughts are based upon several interviews, chats, late-night discussions on reddit.com/r/devops and random conversation, likely over beer and delicious food. I’m also interested in hearing feedback from those that have made the jump; if you have, please email me. I’d love to hear your thoughts and stories.

»

Wiring up Docker on Windows to Ubuntu on Windows

Reading Time: Approximately 1 minutes.

Getting docker running on Ubuntu on Windows is pretty simple. After installing the Docker Windows engine and restarting, run this in a bash session to bind the two together:

export DOCKER_HOST=tcp://0.0.0.0:2375

Pop this into your .bashrc and never think about it again.

»

Start small; move fast

Reading Time: Approximately 4 minutes.

Seinfeld wasn’t always the heavily-syndicated network cash cow it is today. The hit show started as an experiment for Jerry and Larry David. They wanted to write a show to describe the life of a comedian in New York, namely, Jerry’s. Despite Jerry’s limited acting and writing experience, they wrote their pilot in the late 1980’s and sold it as “The Jerry Chronicles,” which NBC made its first national appearance of on July 1989.

I’ll spare you the details, but eventually the crew found their beat and, shortly afterwards, historic levels of success. but I will say this: every episode of Seinfeld was based off of, and written by, a personal story from someone on its writing staff. Compared to the sitcom-by-committee shows that prevailed during the time, this was a small, but drastic, change that eventually made its way into the mainstream. (For example, every cast member on The Office, a favorite of mine, wrote their own episode; some more than once.)

»

Winning at Ansible: How to manipulate items in a list!

Reading Time: Approximately 3 minutes.

The Problem

Ansible is a great configuration management platform with a very, very extensible language for expressing yoru infrastructure as code. It works really well for common workflows (deploying files, adding authorized_keys, creating new EC2 instances, etc), but its limitations become readily apparent as you begin embarking in more custom and complex plays.

Here’s a quick example. Let’s say you have a playbook that uses a variable (or var in Ansible-speak) that contains a list of tables, like this:

»

Sleep better with two simple shortcuts.

Reading Time: Approximately 4 minutes.

TL;DR:

Control + ⌘ + Shift + G Home button triple-click.

Why?

Exposing ourselves to bright screens at night while checking our Facebook feed or reddit posts might not be as harmless as it seems. Tons of research, like this and this suggest that viewing things on bright screens right before bed makes our brains think that we’re in daylight longer than we actually are and, consequently, prevent us from falling asleep sooner than we should be. This combined with our early-start culture has been shown to lead to fatigue, decreased concentration and, in some folks, depression.

Additionally, other research has shown that prolonged exposure to artificial light (like those in most offices or our phones) can, over time, damage our eyes’ ability to adjust to incoming light and weaken their sensitivity to it.

I didn’t notice any of this until a Slashdot post introduced me to Flux several years ago. Before using this application, I was usually tired and sore (I rode my bike much more often back then) most of the time, but didn’t think much of it. I went out often back then, and most of the people I came across were just as or more tired than I was, so I thought I was fine.

»