Kubernetes and other cloud-native strategies might be putting configuration management out to pasture, but I found myself writing a playbook recently while learning how to create infrastructure as code for Azure. I needed to start my Flask web server and Postgres database with systemd, which isn’t a pattern that’s easily supported by Docker. I got this working with Docker Compose, however, and this post will show you how! Create a Docker Compose file with the following services: version: '2. … »

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. … »

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. … »

Computing is expensive. Desktops and laptops cost lots of money. Printers cost even more money. (Printers are really funny, actually; buying one or two isn’t so bad, but once you’re managing tens or hundreds or more laser printers and printing hundreds or thousands of pages per day, the cost of toner/ink and repair skyrocket like a SpaceX shuttle.) Desks cost even more money. Accessories cost even more money. The list goes on and on,infinitum ad nauseum.

Now that we live in an age where downloading high-def movies takes less time than starting up your car, leveraging the cloud and having people bring in their own devices has become a highly lucrative alternative. The bring-your-own-device, or BYOD, movement has picked up a lot of steam over the years, so much so that Gartner expects for “half of the world’s companies” to enact it. Over a billion devices are expected to be using BYOD by 2018, and as more and larger companies begin to take advantage of cloud computing, this trend will only accelerate.

I’ll spend the next three posts talking about three key components of most BYOD environment:

1. Virtual desktops,
2. Laptops and desktops, and
3. Mobile phones and tablets

I’ll explain who the major players involved with each component are, their importance in BYOD and some things to watch out for during considerations.

Your servers are useless, and you should sell them.

Many businesses small and large buy servers for many wrong reasons. Some businesses want a server for an application they wrote. Some others want to keep their data “private.” Others still want servers for “better speed.” All of these reasons are wrong. There are only three reasons that I can think of that justify the purchase of physical servers (feel free to list more in the comments!):

1. A regulator your business is beholden to requires it,
2. Your app really does need that kind of performance (read on to find out if this is you), and
3. You have a strong passion for burning money.