LAPTOP i7

devops per process swap usage

awk /Name/{name=$2}; /VmSwap/{printf "%20s %s %s ",name,$2,$3}END{ print ""} /proc/*/status

inspired from: adnans

Output:

DevOps people are worth their weight in platinum

One guy had an issue where if you loaded up a pallet full of shampoo, the database server would start having timeouts...

http://news.ycombinator.com/item?id=1293849

DevOps in Southern California

If youre a networking/DevOps person in Southern California, here is a meetup I recommend:

UUASC - on Meetup

The UNIX Users Association of Southern California is mostly about DevOps and system administration.  The last talk I attended was on Googles Kubernetes. Kubernetes is a lightweight system for deploying, scaling, and maintaining containerized applications. You can run on top of nearly anything: bare metal, Vagrant, AWS, Google GKE, OpenStack, Mesos... the list is enormous.

Devministrators and DevOps

Yesterday evening while reading a free sample of Jeff Barrs "Host Your Website In the Cloud" I downloaded from Sitepoint, I happened upon a term Id never seen before: devministrator.

The way the word is used in the book seems to indicate a software developer who also does system administration tasks, so on that basis I guess I could describe myself as a devministrator - Im the sole sys admin supporting my personal Ubuntu system used for my Linux development work - but a Google search turns up surprisingly little in the way of a concrete definition.

Google does pull up a few blog postings however, including one by Kris Buytaert who in turn references it from a 2008 Cloud Cafe podcast (about an open source configuration management tool called Puppet) which might even be the source of the word, describing system administrators who apply software development best practices (e.g. version control, continuous integration testing and automated scripting) to solve their administration problems.

However in looking these up I came across another term which aims to encapsulate a similar idea and which seems to have gained more traction: the DevOp (apparently a contraction of "developer" and "sysop" - itself a contraction of "system operator"). As described in this recent article from IT World "The New Type of Programmer: DevOp" [warning: link opens with an ad] brings together coding expertise with a detailed understanding of how to manage and configure the environments that the code operates in. And bringing me full circle, according to the article, its the brave new world of cloud computing thats creating the need for this "new type of programmer": "A cloud developer needs to understand the operating environment ... as well as the development environment."

On that basis Im probably more devministrator than DevOp. But anyway, theres an interesting overview of the DevOp movement (almost a manifesto) by Patrick Debois, What Is This DevOps Thing, Anyway, which offers a much broader perspective than just cloud development - though Id also recommend the free sample of Jeff Barrs book if (like me) youre a non-expert looking for a reasonably detailed introductory overview of the technical aspects of developing for the cloud.

DevOps Availability and Risk

excellent points from an episode of Arrested DevOps, entitled "Who Owns Your Availability?" (TLDR: you do!) https://www.arresteddevops.com/availability/

My thoughts:

- technical risk can produce business risk, as in "your hundred employees cant do anything for an hour", up to "your database is gone therefore the company is gone" kinds of risk.  Or, "feature X doesnt work for user class Y" kinds of risk. Do you as a business prioritize consumers paying you, or you delivering their stuff, or your admins/phone people delighting your customers, or your developers fixing bugs?

From the show (Charity Majors, Pete Cheslock, ADO crew). (Quotes are my foggy recollections, not quotes.):

- cache ("vendor") your dependencies

If you cant deploy to production because GitHub or a 3rd party package server in China is down, things are not good.  Likewise, if your server is connecting to China and all your packages are local, perhaps its time for a security check. (If you dont know what servers your server is talking to, thats another risk.)

- what is your Risk Profile? What is considered acceptable risk?

As your company starts its probably fine to rely on the internet being always available all the time. Not being able to deploy for an hour/day might be okay. Spending resources on growing your company might be a good tradeoff vs security and availability.

- your dependencies are cached. What about deps of deps of deps?

- "Packerize the base"

If your system has a baked, reliable base, with a little bit of changes on top, then its easier to track down and fix things that break.

One mechanism is "baking" all your random dependencies to a Docker layer.  Or, network volume -- Amazon S3 for example (deb-s3).  It can still go down, but if its up you get everything in one place. Itll be there for you even if the original host is not happy for whatever reason. One person mentioned she had more problems with GitHubs reliability than her own.

Another failure mode: known-good version is broken. Your business depends on the "beer-1.0" package. Its been working fine for months.  Developer gets drunk and uploads a broken package, but uses the same version number -- "beer-1.0" is now broken.  You can no longer make changes to your business!  Since you own your availability, its your problem.

- "if you treat your devs like children, theyll act like children. Theyll become subject matter experts on doing things the wrong way. We as devops can be spirit guides, career counselors for your leveling up skills." Developers own the code, the availability. Give them pagers and wake them up when the site has problems.

- site should have "circuit breakers" - if the site is in "continuous partial failure", thats better than just being down for everyone, full stop.


I dig the Arrested DevOps podcast, and listen to it often. Thanks!