Sascha D, Bratty Redhead
Bratty Redhead Blog, The sarcasm is free!

Shenanigans

I’ve been trying to think of a thoughtful and engaging way to tell everyone the news. I feel like I should reflect on the last two years of independent consulting life and offer up some deep thoughts and wise advice. But I got nothing.

Starting August 5th, I'll be an Opscode employee.

The truth is, I’m super excited to go to work with my friends and eventually move out of the snow-addled state of MN. A big reason I am independent is because I was tired of being an Enterprise employee. I have always been willing to consider work with small companies but I also want a basis of friendship with my co-workers.

I’m confident enough about who I am and what I do now that I’m not interested in what I have been calling “arranged marriage” jobs - the kind where you have a few interviews, get really excited and then discover you’ve walked into a clusterfk egofest. I don’t want to have to evaluate companies and people on the basis of a few interviews. I also don’t want to have to engage in the inevitable dominance posturing and pissing contests that seem to be inevitable with many tech teams.

On the other hand, working with smart people is one of the best things in the world. Being independent means you’re often working alone and don’t get to hang with other smart people very much. It’s why I’m so enthusiastic about conferences, because that’s where I get to hang with my smart friends.

You can read in the very first post on this blog about how transformational it was for me to begin working with open source software, and Chef played a pivotal role in that. I’ve worked with the tool now for over 3 years and I love it.

While I do love the product, what draws me to Opscode is their attitude about culture, both internally and the community. HugOps is a real thing and I love that it’s a lifestyle choice. Between this and the fact that I like without reservation every Opscoder I’ve met makes this the beginning of an exciting adventure for me.

I expect shenanigans to ensue almost immediately.

********************

Cleaning Up the Clubhouse

I’ve been a bit reluctant to enter this discussion on my blog; partly because there are some amazing, thoughtful posts already that eclipse anything I could say and also because any of these discussions seem to spark a lot of outrage and anger regardless of the actual topic content. That kind of drama is a big turnoff for me. But I did want to say a few things about a recent experience at devopsdays because it seems to be an angle we aren’t discussing.

At devopsdays Silicon Valley this year, one of the breakout sessions was “Encouraging Women in Dev/Ops,” led by Doug Ireton, one of the awesome automation engineers at Nordstrom’s. I was already dragging from Velocity and hadn’t planned to go to any sessions, much less yet another “how do we get more women in tech” discussion.

If I sound impatient, it’s because I am, a bit. In general, I don’t have any really strong opinions on the “women in tech” discussions. This is because I feel we have the same discussions over and over again without covering any new ground or making any difference in how people think. This may actually not be a fair feeling as the discussion has certainly changed the way I think. Or, more accurately, it’s made me think about it. I don’t actually think we should be worrying about how to get MORE women in tech as much as how to make it a comfortable place for people who are already here. Take care of that and balance will come eventually.

Some History

I entered tech during the 2000s internet boom where any warm body would do and you didn’t have to be a decent human being to keep your job. I know this because I often was not a decent human being myself. I was grumpy and petulant, at least in my head, and folks from those early days would probably agree (Kiosk level 2 support team who I pissed off in a major way and worked hard to repair that relationship, are you out there anywhere?). I did eventually grow up and become a moderately self-aware decent human being and have even managed to develop some empathy for people outside my direct life experience.

Not only have I worked in Tech most of my adult life, my dad was a wargamer and RPGer. I was exposed to many strains of nerds and geeks growing up and some of the biggest treats of my 8 year old self involved getting to stay up late with the grownups while they played D&D and maybe even being given a character sheet.

I lived in a house with 4 other guys in college where I learned to watch Star Wars and Repo Man on repeat on one TV while playing video games on the second TV until 2am.

What I’m trying to communicate with this history is that, while there are certainly some women in all of these lifestyle choices (wargames, rpg, tech support, web ops), we make up a small percentage. So I spent my life getting used to being one of very few women in any tech or social group. Sometimes it’s fine, sometimes it’s not fine. It largely depends on the company I’m keeping.

Regardless, I was taught to communicate by social groups who probably shouldn’t be teaching anything. But I learned early that guys tease and insult when they like you and that you shouldn’t worry until they are polite, kind or ignore you. That also became my style of communicating for a long time because that’s what I knew. To this day I am comfortable with it. Dick/Boob jokes don’t bother me. Profanity doesn’t bother me. It was co-workers on the clock that introduced me to such great things in life as Triumph, the insult comic dog, South Park and all kinds of inappropriately funny youtube videos. Calling me a girl doesn’t bother me. Calling me a princess doesn’t bother me because there are plenty of boy princesses out there and I’ve called them on it.

Things that DO bother me: overt misogyny, hatefulness and guys who constantly bitch at work about how their wife makes their life miserable. People who won’t admit there is a problem with “isms” in the world because they themselves don’t perpetuate it or see it. There is a big difference between a dick joke in private with friends/colleagues and making one at a party where you don’t know people. Context is everything.

The Effects of HTFU or GTFO

To be clear, I’m not saying I’ve sailed through life happily making dick jokes. I have experienced a lot of internal turmoil and emotional anguish over all-guy teams that I have been on, especially early in my career where it was still really hard to gain acceptance and professional respect. But 10 years ago it was HTFU or GTFO. And so that’s what I did. And when you make that a condition for acceptance, you greatly shrink the available population and personality types who stick around, both men and women.

The modern discussion of sexism (specifically because it relates to me) has taken me from an attitude of “most of it doesn’t bother me and I don’t know why people care” to “A lot of perceived exclusionary sexism doesn’t bother me, but other people have different expectations from their professional lives now; I entirely respect that and will work to make my professional sphere a welcoming and safe place.” In order to attract the next generation of women into tech, everyone is going to have to come at least this far in their thinking. And it’s not just sexism; it’s ableism, genderism, homophobia, and on and on.

But to get back to why I’m bored with the women-in-tech discussion people keep wanting to have, I don’t see it making a diff and I’m still getting a big vibe from guys of “I don’t do it and I don’t see it and how is it possibly a problem?” I ended up going to the discussion because I really like Doug and wanted to be supportive of his efforts. In general, it was pretty much what I always hear and it usually boils down to “we’re really nice guys and we can’t find any women to hire.” I get that there are not a lot of us out there. BUT…

Self Awareness is the Key

My answer to everyone who feels like this, and I gave it to the Nordstrom’s guys when we talked about it later, is this: work on your own self-awareness. I’m sure you think you’re a reasonable person who never had a sexist thought in their life. I’m pretty sure this is not true, because even I have made pissy comments about women drivers, although only in the privacy of my own car by myself. But I still think it. And I’m a woman!

So work on your self awareness. If you really care, go around to every woman in your professional and personal life and ask them to please offer you feedback if they feel you’ve ever done something sexist or demeaning either to them or in their presence, no matter how trivial it seems. Because I have news for you guys, we don’t offer that stuff uninvited. We expect to be scoffed at or ignored because so many people think sexism is drama. Example: I have a friend I’ve worked with at two places now and it took me 3 minutes to spit out “can I offer you some feedback?” before calling him on the fact that he’d talked over and for me in a meeting; something I find particularly galling.

None of this is going to get MORE women in tech. But it’s going to comfort the ones who are already here and word of mouth is a particularly powerful advertiser, as every viral video ever should tell you. And honestly, I think it’s going to do more for everyone if we clean up the house first before inviting more women over and asking them to help us clean it up for them.

******************************

Screencasts: Context Is Everything

Yesterday I tweeted in frustration about being confronted with yet another screencast/video when searching for help on the internet. This has been a growing frustration for me as I branch out away from pure command line/coding tools.

I find help videos in general to be obnoxious. I read and comprehend fast and generally want to skim some text to understand the thing that I’m looking for. I find “new user feature” videos that we end up from Google and stuff to be especially annoying.

I get that not everyone wants to just figure stuff out, but I generally can figure things out way faster than you can tell me about it.

A few months ago I was writing my first public talk and also using Keynote for the first time. I kept having to search the Internet for answers to questions because (2 years later) I’m still getting used to the way OSX presents things and am never sure where to look for formatting-type stuff. Something that really set me off was trying to figure out how to make new masters for Keynote. When I looked around, all I could find were videos lasting several minutes on the topic. Seriously. All I wanted was a paragraph on the general method and maybe a line with the actual tool bar clicks to begin with. Eventually, on the second presentation I worked on, I found what I was looking for. But I was really annoyed by the whole exercise.

On the other hand. I subscribe to RubyTapas. I find that an appropriate use of a screencast. Similar to a podcast, it’s a discussion of a complex topic that doesn’t have an answer at the end. When I want to figure out how to do something, I want to read about it on stack overflow, not watch a movie. BUT, if I’m interested in the how and why of a learning topic, then I love a good screencast. I especially like the short and sweet nature of the RubyTapas because they are not a major time commitment to listen to one.

But if I have a question, and that question has a fairly simple answer like “click here, here and here and type these things” I’m not sitting through a slow moving video to find out the answer. Yesterday I was looking for the start command for a tool I’d just downloaded and, when I clicked on the “getting started with Tool” link, it took me to a screencast which is what sent me over the edge and caused that tweet.

It was interesting to me that this is probably my top ever retweeted tweet. I think there’s an assumption out there that people want video instead of words. I never watch video on news sites either. I hate it. I want to skim stuff. Maybe places making these assumptions should recalibrate. Or maybe those of us who can read and comprehend faster than someone else can talk are actually in the minority? We’ll probably never know.

***************************

Pieces and Parts: Managing Your Ruby Toolchain (Part 1)

I recently received an email from someone who attended my ChefConf talk and asked me to expand on a few things. As I started to answer the email, I could see it was going to turn into a dissertation, so I migrated it over into a blog post. As I started to write the blog post, it seemed to grow into a book, so now I’ve decided to break it down into multiple posts. In this post I’ll try to summarize the question and situational environment and cover the easiest answers first: scripting languages and RVM.

The Question
Given the dynamic nature of Ruby tooling and the uncertainty of internet connections, and given that I work in the Enterprise, how should I design my supporting infrastructure and should I make Ruby my default scripting language?

The Situation
Situated in the Enterprise, working with Red Hat/CentOS Enterprise Linux(EL).

Concerns
* Rapidly changing versions of gems and software on the internet
* A constant need to download and compile Ruby (also compilers in production)
* The dynamic nature of downloading an RVM script from the internet on every install
* No connection to the internet (I’m not sure if this was a concern of his, but I’m betting it’s one of yours)

Let’s look at our major parts, shall we? In this set of posts we’ll cover
* Scripting Languages
* RVM
* [Package Repositories]
* [Package Versions]
* [Ruby Management]
* [Rubygems]

Scripting Languages
The question was, should we go all in on Ruby as a scripting language? My answer to that is, unless everyone loves Ruby, that’s probably an unnecessary hardship to impose while also trying to adopt Chef. Generally you find some combination of Shell, Python, Perl or Ruby on most enterprise server systems. I think you should script in the language that works best for you, where “works best” is a combination of what you’re comfortable with and what will best suit your immediate need.

Honestly I think we’ll never move entirely away from Shell scripting and that’s ok. It’s easy to learn and suits functional tasks like cron jobs and other server-specific work. Do I think you should have a script suite in 4 different interpreted languages? Well, no. If it were me, I’d pick Shell and Ruby for my options. But there’s no reason it can’t be Shell and Python or any other combo.

Me? I love Ruby and have an irrational dislike of Perl that stems from my early days in ops dealing with travesties of unreadable scripts. So I like Ruby first and Shell second, Python third and Perl never. But it’s hard enough learning a new tool like Chef. Don’t impose artificial constraints on your team.

Also, Your devs are probably already programming in Java or C or whatever. Over time most devs pick up a smattering of shell. If you force Ruby on them too it’s likely to breed resentment.

RVM
While I’m not an expert on RVM and other Ruby managers, I have heard that it’s not meant to be a server tool. I do use RVM for workstation development and I’ve used Rbenv as well. I don’t mind compiling Ruby from scratch when installing it locally although I will love it when RVM gets precompiled rubies for OSX.

A Slight Digression on Workstation Automation

I’ve written workstation automation using Fletcher Nichol’s chef-rvm cookbook. A frustrating problem I have run into is that RVM undergoes frequent development and at first I had people coming to me because the workstation toolchain install wouldn’t work and it was almost always because the RVM version had changed and something was now wonky in the settings or install chain. So I started pinning the RVM version to install with occasional revisits to bump the version when I could.

If you want to look at workstation automation for OSX 10.8 try a couple of these repos:

  • Sprout-wrap - This used to be Pivotal Workstation and is now basically an instruction page for getting going with Soloist
  • SoloWizard - a browser based checklist that will assemble a chef solo provisioner for your workstation.
  • Joshua Timberman’s workstation-chef-repo and mac_os_x-cookbook for his personal collection of workstation automation
  • Puppet-RVM - Puppet module for installing and managing RVM
  • Boxen - A tool for automating OSX with Puppet. Links to a blog post with details.

I have written workstation automation but I don’t maintain it these days and I’ll probably try Soloist when I get my next new Mac.

TL;DR:
* Use RVM on workstations not servers
* If you’re automating for many people over time, pin your RVM version

Wrap Up To keep the blog post readable, this is all I want to discuss in this first post, but I’m about to publish Part 2 as well: a rant about package repos. I’m extremely interested in feedback on this series as I was only half joking about writing a book, though it would likely be an online doc of some kind. This type of discussion evolves too quickly to commit to paper.

****************************

Managing Your Ruby Toolchain Part 2: The Package Repo Rant

TL;DR Use package repos for all your static software

Last weekend I wrote a blog post that started exploring standards for managing your Ruby toolchains. To review, I had a query from someone on how to cope with the dynamic nature of Ruby-based tooling and managing a Chef infrastructure. and the fact that you don’t always want to go to the internet to get stuff, it’s a pain to be compiling things on servers all the time AND to do that, you need a compiler which is regarding as a Bad ThingTM in Production.

The question came to me via a talk I did at Chef conf and I’m going to use Chef examples, but, unless someone tells me different, I’m going to come down on the side of you can use this advice with Puppet and CFEngine and any other CM tool out there. It works without CM too, but why would you ever?

In this blog post, I want to talk about why I am so adamant about package repositories and offer some real world examples. I pick on Tomcat a lot here. Nothing against Tomcat. It’s something most people understand and that I have also had personal experience with it not being managed as a package and creating much distributed pain.

Broken Record Much?

I can’t shut up about package repos. Why am I so passionate about the need for all package repos all the time and to have a team actively managing and grooming them?

As part of the decentralization of Ops teams and the rise of DevOps, we now see multiple autonomous teams simultaneously working on similar projects but not collaborating or communicating on infrastructure. It behooves the infrastructure managers, whether that’s ops or devops or the tools team or a central collaborative group comprised of reps from all the teams, to own and groom a collection of package repositories.

But Why?
With the rise of self-service, all you can eat virtual machines, development teams are expected and want to be independent from the corporate server supply chain. Unfortunately this also decouples them from people they depend on: infrastructure and middleware experts(Yes Ops, that’s you). They may sail gayly on and do their best or trudge forward grudgingly, resenting all of the extra work they now have to do because the Enterprise wants to be “like a startup.” Either way, they’re going to move forward, and when you don’t offer them ways to easily use software, they’ll figure out ways to [cope][]; ways that will horrify you when you discover them.

I work at a startup because Enterprise is stupid like that.
Nope. It’s not only the Enterprise that needs to fear the chaos of unmanaged, difficult to use infrastructure. Say your whole startup is fewer than 20 people? You’re the “devops engineer” and you work with a 5 person dev team. The dev team may or may not include you in everything. You might not know of actions they’ve taken to [cope][] with problems you don’t even know they have. They don’t realize there could be a simple solution to their problems because they are brilliant startup devs and they will just figure it out. Then they’ll hand you their giant shiny mud pie and you will cry because you could have saved them a bunch of work with a few well placed repos and a web proxy.

Package repos create a beautiful garden where you static software can flourish and discourages tarball weeds from springing up in the cracks everywhere.

If you establish a well known, central location for packages, people will know to look there first for an existing package that meets their needs. And they will ask to place packages they need there as well.

Ex: In the situation where someone thinks

“I need Tomcat7 and Red Hat only ships with Tomcat5”

Their correlating thought will NOT be

“I should go download that from the internet and store it on the jumphost”

but instead

“I wonder if we have that in our custom repo?”

or in an even more mature organization

“I should include our Tomcat cookbook in my runlist and override the attributes that are unique for my situation”

When you make package repos easy to access and use, you

  • Eliminate several slightly different copies of software (ex: tomcat) floating around your infrastructure.
  • Eliminate several slightly different versions of packages deployed to Production.
  • Discourage placing random tarballs in version control or Chef cookbook files.
  • Make your configuration management tool easy and intuitive to use.

The Problem With Tarballs - a Real Life Example

Config management tools are designed to be idempotent, which means they only do things once and ensure things look the same regardless of how many times you run the the same process. Tarballs subvert the use of configuration management primitives, requiring the use of non-idempotent execute blocks to manipulate them. Real world example:

Without a package repo in place, this happens:

1
2
3
4
5
6
7
8
9
10
11
remote_file "/tmp/tomcat7.tar.gz" do
  source "https://www.sometomcaturl.com"
  not_if { File.exists?("#{node[:tomcat][:home]}/bin") }
end

execute "extract_tomcat" do
  command "tar xf /tmp/tomcat7.tar.gz"
  cwd "opt"
  not_if { File.exists?("#{node[:tomcat][:home]}/bin") }
  only_if { File.exists?("/tmp/tomcat7.tar.gz") }
end

Or this utter travesty:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
bash "install_tomcat6" do
  tomcat_version_name = "apache-tomcat-#{node.tomcat.version}"
  tomcat_version_name_tgz = "#{tomcat_version_name}.tar.gz"
  user "root"
  code <<-EOH
   curl --proxy https://aproxy.com:8080/ --user user:pass https://myartifactoryurl.com/artifactory/
ext-release-local/apache-tomcat/apache-tomcat/#{node.tomcat.version}/#{tomcat_version_name_tgz} -o /tmp/#{tomcat_version_name_tgz}
tar -zxf /tmp/#{tomcat_version_name_tgz} -C /tmp rm /tmp/#{tomcat_version_name_tgz} mv /tmp/#{tomcat_version_name} #{node.tomcat.install_path} chown -R #{node.tomcat.run_user}:#{node.tomcat.run_group} #{node.tomcat.install_path} chmod -R 755 #{node.tomcat.install_path} rm -rf #{node.tomcat.install_path}/webapps/ROOT EOH end

Notice that they very carefully delete that tarball when they are done, ensuring that it will be re-downloaded 30 minutes later on the next run. They also untar the file and then move it to the install location without checking to see if anything is already there. Again, 30 minutes later the entire process happens again despite whatever is already there.

Now look at what happens with a package repo in place:

1
2
3
package 'tomcat7' do
  action :install
end

You may have to customize config files and init scripts, but this is a far simpler and less error prone way to install the base software.

In this case, Chef knows what OS you are using, what your package manager should be, repository connection details and how to install the package. Puppet does the exact same thing. So does every other config management system in the history of ever. The less code you have to write and the less verification code you have to write, they happier you’ll be and the people who come after you will be.

The End

I’ve heard a lot of complaints from ops and tools folks that devs do “crazy” stuff and they are much affronted that the devs don’t seem to understand the unpublished rules of operationalizing apps and the best way to use tools, and omg did you see the travesty of a Tomcat cookbook they wrote?

I have spent years on ops teams, tools teams and automation teams now. I have been one of those self-righteous, affronted peeps. This behavior doesn’t scale, yo.

One of the best messages that DevOps has for all of us is, if you don’t like the way someone’s doing something, talk to them and find out why. You’ll probably learn that there were great reasons for everything, including “I didn’t know how to do it, Chef is hard, Tomcat is hard, and I was just a Java developer until you guys started making me do all this automation stuff without telling me the rules or offering guidelines, so I copied another team’s Tomcat cookbook. I had no idea it’s crap. It installs Tomcat and that’s all I care about.”

Indeed. That’s all they care about. If you care about more than just the install, maybe you should reach out and offer to partner with them on the parts you care about. Don’t like the way devs are building application infrastructure? Well maybe you should do it for them. Provide them with a consistant VM build from a stable package repo and possibly infrastructure cookbooks with sane defaults and overrideable parameters. Chances are good devs don’t like recreating that crappy Tomcat wheel any more than you like them doing it. It’s likely they will be pathetically grateful because, while they are coping with the tasks they’ve been handed, they don’t really know what to do in detail and researching JVM tuning parameters is not their idea of a good time.

Why am I telling you this story? Because I believe that a major piece of your infrastructure stability is created with package repos. Making them easy to find, use and contribute to will help smooth any number of peripheral problems you are trying to solve. In my next post I’ll talk about practical considerations for repositories, packages and toolchains.

*************************************

Minneapolis - St Paul Infracoders Meetup Recap

Last night we had a fun second meetup of the Twin Cities Infracoders group. On the docket were presentations and demos for Vagrant and Sensu. We had about 18 people show up and a lively discussion ensued on why you’d want to use something like Vagrant and implementation strategies.

Most of us have partnered with development teams who have asked for things that are difficult to provide or unwise and one of the best use cases for Vagrant is the ability to hand someone a development environment homogenous to the team and easy to troubleshoot. It’s homogenous because everyone uses the same base OS box file and also uses the same provisioner to create the environment, whether that’s Chef, Puppet or Bash scripts or anything else. It also shortens time required to bootstrap a new team member.

Mike Goetz and Tom Duffield gave us a great compressed Wordpress install demo on a local VM with Vagrant and Chef. Then they gave us a second demo of spinning up two ec2 instances to separate the front and back end pieces of Wordpress.

After Vagrant, we ran through some Sensu slides and looked at some basic info about Sensu. There were technical difficulties around the demos we were working on so demoing was minimal but discussion around why Sensu, how Sensu and when you might switch was great and we’re looking forward to a more detailed demo at next month’s meetup.

Here is the collection of tools and links from last night:

Vagrant
Vagrant Plugins
Sensu
Sean Porter’s Slides
Wordpress Demo(this link will be available shortly)

Coming up:

Next month’s meetup, hosted again at the Nerdery, will be a presentation on using Selenium for automated testing and QA as well as our enhanced Sensu Server and client nodes deployed with Vagabond on LXCs inside a Vagrant VM. I hope we get a great turnout.

On another note, I have been talking lately about how I want to organize a Chef hackday. After last night’s discussions around tooling and workflow, I think it might be nice to instead do a tool-agnostic Workflow Tooling hack and help day. Many of us have gotten workflows configured successfully, but depending on your experience beating on the Ruby toolchain, it can be challenging the first couple times you do it. The Nerdery said they would probably be willing to host and I was thinking about asking CoCo Minneapolis if they had any interest in hosting.

I’ll post up a question in the meetup group about location and date preferences to see if I get enough interest to make it a thing. I’ll also send someone to shill at the monthly DevOps meetup that I can never attend due to my work travel schedule.

If you haven’t made it out to an Infracoder meetup yet, I hope you because we are having some great tech discussions and getting to hear about other people’s uses cases for things is fascinating. Also, the Nerdery takes super great care of us and feeds us Pizza for dinner.

******************************

Devops Consulting: Why I Don't

I had an interesting exchange with Adam Jacob yesterday on Twitter around devops consulting. It’s a topic I’ve discussed often with friends as we work out how to spread the devops message in our consulting adventures. After the Twitter chat, I’m motivated to say a few words about devops consulting, not because there was an argument, but because it’s something I’ve thought about often since I started independent consulting and I think it’s important.

The twitterings began with me trolling Adam on a topic about which I learned my first, best lessons from him. Two years ago, my ideas around devops were still mostly unformed when I saw him give his “What is Devops” and “The No Assholes Rule” vignettes at Velocity. These two 5 minute segments clarified several nebulous thoughts I’d been having and form the base for how I approach devops today.

My trolling quickly transformed into an exchange as to whether devops consulting is a valid thing. Here’s my take:

Devops is The New Black

As far as toolmakers, tool-consumers and recruiters are all concerned, devops is the new black. I get frustrated with the “slap a devops on it and they will come” attitude we see prevailing. It makes me want to never use the word “devops” to describe anything ever because of things like this:

  • If it’s a tool for scaling or automation or monitoring or cloud, it’s now a “devops tool”.

  • If you have a job for some poor schlub to do production support for the dev team, you call it “looking for a devops engineer with build experience.”

  • A tooling company has a giant virtual sticker on the website: “Designed by devops.”

  • If you want to get some other poor schlub to join your overworked ops team you call it a “devops engineering” position but it’s really just another day in the life of duct-taping together prod.

I already hear colleagues succumbing to the terminology “devops Tool” because it’s a phrase understood by (or at least familiar to) upper management and business users. I can even see the day when I give in and start calling things devops tools. This makes me sad.

Emo Devops

Call me cynical, but this sort of devaluation discourages me and has turned me into something of a hipster goth. You know, the girl in all black with the black nail polish listening to Bauhaus and denying she’s goth because she transcends labels in her non-originality. I can make fun of this girl because I was her in high school.

But as I see tool companies and recruiters slapping devops across everything and large companies begging for the devops panacea, I become less and less inclined to talk about devops and the hipster goth in me is damned if she’s going to cash in on all the quick bucks of devops consulting.

Devops Consulting - Why I Don’t

Last year I had a company try to hire me as a devops consultant, but the very idea made me shudder. It felt utterly pretentious even though they had the best of intentions and were knowledgeable about devops. My business card says Devops Enthusiast. That’s it. I love it and I try to live it every day I walk into an office, whether it’s my home office, a client office or any other place with people in it.

But my business card will never say Devops Consultant. Why not?

Devops Isn’t a Deliverable - When I get done with you, you don’t have a devops. It’s possible that the things we’re working on will bring you closer to a lifestyle and culture that is devops. And that’s super. Working at scale demands extraordinary feats of technical prowess, but it also demands empathy and trust, key components of devops culture. I expect this to be a natural byproduct of my tenure, not the thing I craft.

Consultants Have No Moral Authority - This is the classic water and horse thing. You can hire someone to tell you how to do devops, but unless everyone is signed on and excited, it’s going to be the consultant and the person who hired the consultant drinking from the trough and a bunch of other horses standing around dehydrating. I have no desire to earn a living doing this.

I’m Not Qualified - I learn new things every day and I often remind myself that devops isn't just me preaching DevOpyness, but also involves me actively empathizing with and trusting people I find difficult or frustrating to work with. This stuff is hard, and I’m not even close to perfect. I’d rather lead by example than preach. I feel like a hypocrite telling other people how to put their house in order when I’m still cleaning my own.

I’d Rather Be Crafting - Let’s face it. If I say Devops Consultant, that’s management consulting. As much as I’ve considered going into management because of the ignorance I see in charge of stuff, I’d rather be making things. This is a selfish thing, right? I love to CLI and hack on Ruby and play with Chef and figure out why stuff is broken, mentor newer engineers and coach devs on how to operationalize their apps. I don’t get to do that if I’m teaching senior management about devops. It’s why I like consulting. There’s always a new problem to solve.

Is Continuous Delivery a valid Euphemism for devops?

This was also touched on yesterday. Jeff Sussna wrote a well-articulated article for why we should just call it Continuous Delivery instead of devops. I think Adam and I were not actually disagreeing about anything in our chat today, unless he was postulating that CD is as nebulous as devops. I don’t think it is. I think Continuous Delivery is a measurable deliverable and a valid consulting field. If done right, it results in not just a great pipeline, but also devops culture because CD should be impossible with crappy culture.

What About devops?

I know some folks who are doing the devops consulting thing. They generally want to do the management consulting thing and they believe wholeheartedly in devops as cultural shift and in CAMS, which I think is the key to making it work, if that’s what you really want to do.
There are also some super fantastic companies with amazing cultures; some calling it devops, others not but still living the lifestyle. I’m not panning everything calling itself devops. However, the more I see vendors and recruiters latch onto the word and commoditize it without sincerity, the less I want to actually associate with the word myself and the more grains of salt I require when I get yet another email from someone telling me about their great devops job for which I’d be a perfect fit.

****************************

Coffee Nerdery: Chromatic Coffee

Chromatic Coffee
Location: Santa Clara, CA, a few miles from the Apple campus
Espresso: Emperor
Hardware: La Marzocco and heavily modded grinders of unknown origin (see picture)
Coffee Art: heck yeah
Wifi: Yes
Drink: Cappuccino
Served in: 5oz ceramic cups
Visited: Daily in February and March 2013

I first met Chromatic Coffee when it was a franchise under another name in June 2012. For the record, it was super then too. I recently acquired a client in Santa Clara, CA and knew I would be traveling out here every week. Strangely, Silicon Valley does NOT have a great artisan coffee shop on every corner. A lot of the area is actually office park and strip mall hell. When I found this place last year, I drove 8 miles from the Hyatt Convention Hotel to get some decent coffee. (For the other record, all of the espresso served at the Hyatt is utterly vile).

So I immediately thought of this location when I set up weekly trips to California. In the meantime I discovered the shop had changed its name to Chromatic Coffee but was the same crew of awesome baristas that I’d met last year. I actually managed to find a good hotel near the shop, putting me about 5 miles from the client but worth every commuting minute, knowing I’d have decent coffee at least once a day (I work in office park hell).

I am happy to say that breaking off on their own has only improved things over here. In my chats with the baristas, I’ve learned that the owner is a tech obsessed uber coffee nerd. You can see this in the fact that they are their own roastery and hey, check out the grinders. Heavily modded, the barista couldn’t remember the original brand on them, but informed me that the owner is actually working on his own equipment as well. (uber techie coffee nerds unite!).

So I can’t tell you enough how much I love Chromatic. Everyone there is super nice and super knowledgeable about the coffee and will happily nerd out over coffee talk when it’s not busy. There’s also a Hario pourover bar and they tell me they make cold brew as well, which I will be sampling next week. In addition to all the other awesome, they hold classes on everything from pour-over technique to barista art.

Bonus: They are not snooty coffee snobs here. You can order your drink with skim milk or to go and no one will look down their nose at your or inform you snottily that they only use whole milk from locally approved cows.

I wish I could keep gushing, but you should really get in here and try them for yourself. Don’t be fooled by their strip mall exterior. They are beyond awesome.

***************************

Shell Scripts Are Like Gremlins

Today I ended up in a heated discussion with some team mates over deployment strategies. As is often the case with this team, myself included when I don’t stop and think, we often leap right to arguing over which tool is best before discussing the problem we want to solve. It wasn’t the first time.

The source of this discussion was brought on while we were reviewing some chef work I’m doing with a development team. My work was mainly to assist them in getting to functioning cookbooks that also had their app logic separate from global cookbooks. I basically copied their intent wherever it made sense while shoring up design and Chef styling. One of the things they were doing was making a call to our Artifactory server for a latest snapshot of a WAR file, downloading it into the Tomcat directory and restarting Tomcat. Works for me.

Getting to this point in the review triggered a long, heated debate over

  1. whether you ever wanted this to happen,
  2. whether you should use Chef to manage deployments, use Jenkins to kick off shell scripts or use some other orchestration tool to do something else or
  3. just copy the world by hand (well, no one really believes that last is a good idea).

I was like, geez guys, I’m just mimicking the dev team’s functionality, why are we are arguing about this? But this has been a topic of discussion often recently and, with another team announcing yesterday they were writing a homegrown tool to manage jboss, deploy ATG ears and manage config files all retrieved from Artifactory, I don’t expect the subject to die soon.

I don’t think there’s one right answer to how you deploy your code, but I think there are many poorly thought out ones. I’m not here to necessarily make an argument for Chef as a deployment orchestrator. While there are people deploying with Chef at scale, I am not one of them, nor have I been. My work with Chef has been mainly in development with some provisioning and so I have a lot of theories, but that’s really all. What I do want to talk about is why I don’t like shell scripts for deployments or orchestration and what I want in a deployment system. This is the first part of at least a 2 on this topic.

Shell Scripts are like Gremlins. You start out with one adorably cute shell script. You commented it and it does one thing really well. It’s easy to read, everyone can use it. It’s awesome! Then you accidentally spill some water on it, or feed it late one night and omgwtf is happening!?

The Fixer: Someone else comes along and found an edge case your shell script doesn’t deal with. They add in some logic for the edge case, voila, problem solved.

The Refiner: Eventually someone realizes the logic for the edge case is not specific enough and is causing deployments to fail sometimes, so they refine the logic.

The Slippery Slope: After that, someone might decide it’s a good idea to automate stopping the apache server from sending traffic during deployments and decides to do it in the same script. Great idea! That’s such an awesome idea that everyone starts adding functionality to the tiny beautiful shell script, now no longer tiny nor beautiful.

OMG GREMLINS! Then you come back along and find all the extra stuff in your shell script that doesn’t belong there. You’re horrified. You might even be feeling a little bit violated (come on, we’ve all been there at least once). So what do you do? You pour some water on it. You break out the shell script into several functional bits. Now we have LOTS of gremlins instead of just one. Now you have a suite of scripts that are once again beautiful. But now the deployment is complex. You have a suite of bash perl ruby python scripts that also need a wiki page to describe intended flow, what to do if something doesn’t work and any edge cases that you haven’t gotten around to scripting yet.

The Exodus: Next up: You get a call from a buddy who is dying to have you come work for his Next Big Thing startup. So you quit your job, pack your bags and move to Silicon Valley Sitcom with ne’er a backwards glance, leaving a couple of forlorn junior sysadmins desperately reading wiki pages trying to figure out what to do with your shell scripts as a new application is launched that requires a bunch of new logic for deployment. These guys do the best they can and start tacking on if statements everywhere they need to in order to make the deployments go.

Subsistance Living: 6 months later, one of these guys leaves and the company hires 3 more guys with no understanding of the history of the deployment scripts. Sometimes they work, sometimes they don’t, people aren’t entirely sure why and just self correct by hand at the command line until things work(phew!). Everyone is afraid to touch them because they are fragile, the code connecting them is obscure and there are similar logic blocks found in several sections, sometimes commented out, sometimes used, but you’re not really sure whether it’s necessary. The original wiki page gets updated sometimes but not often and not usually by the person maintaining the scripts but by the people using them in the middle of the night.

And that’s why I hate shell scripts and think you should never use them for deployment scaffolding.

True story: my first venture with Chef involved deconstructing an organically grown Kickstart post that had been originally written for Red Hat 3 and subsequently updated for RH 4, 5 and 6. I was removing functionality from the postscript and rewriting it in Chef blocks when one of the admins came and yelled at me for omitting a block of host names from /etc/hosts and I was like, GUYS, those host names are for servers in a data center that was decommissioned when I started here 3 years ago.

You can tune in for the second half of this blog post, what I want in a decent deployment system, when it goes up next week on the Sysadvent blog. Woohoo!

*********************************

Learning to Let Go (or How I Stopped Worrying and Learned to Love the Bomb)

Today I was having a conversation about consulting and how important it is to not be emotionally attached to your solutions. As a consultant, you exist to be an enabler. You help others succeed with tasks that, without your expertise, they might fail instead. As consultants, our value comes from a long history of observing and participating in spectacular failures and fantastic successes. We know what works and what doesn’t work and we can articulate the reasons why. But our value can be compromised if we can’t interact effectively with our clients. This means checking your emotions and inner schadenfreude at the door and working with clients to discover a solution that is practical for their environment.

BOFH

Back in the day, I worked on a silo’d web operations team at a big retail company. We knew how we liked things done and, although we might argue amongst ourselves, we presented a united bullying front to the dev teams. For example, we didn’t allow them to deploy apps into production when they came with the caveat of “you have to restart the app every night.” We drank developer tears with breakfast, and we liked it that way.

Guess what? Consultants don’t have that luxury. I might also argue that internal operations teams no longer have that luxury, but that’s a blog for another day.

In that job, I saw every kind of connection leak, OOM and spectacular cascading infrastructure disaster you can think of and I participated in resolving several. Eventually I moved on to consulting for a large company where I designed and deployed infrastructure for large web-based applications. My previous experience was not just invaluable for designing infrastructure in diverse environments, It also enabled me to advise client development teams on how to write robust applications and assist them in tracking down performance problems during the development process. I was full of ideas! They were all brilliant! Wait, what!? Where is everyone going? How can you not like my ideas?

Keep your WTFs to yourself

As a new consultant, I had excellent technical knowledge, some decent communication skills, and a host of opinions. I knew the right way to get things done and people should listen to me because I was the consultant. But technical knowledge and opinions can only take you so far. Some people aren’t suited to life with clients. Often there is no one to shield you from difficult people they way your manager would in a normal job. You need to work with all types of personalities, while maintaining a calm demeanor. You need to be able to not take things personally. You must be capable of articulating the why’s behind your ideas and speak objectively about ideas from the client, even if you think it’s the worst idea since Greedo shooting first.

You can’t say things like, “That’s the dumbest thing I’ve ever heard,” or “Why in god’s name would you ever do that?” A favorite that I had to give up was, “Why do you want to make me cry?”

Don’t Get Attached

A concept that challenged me is that there is no absolute right or wrong way to design something. The corollary to that is you will always disagree with at least one thing the client wants to do. Sometimes you will disagree with many. Sometimes they will disagree with your solutions and expect you to implement what they want, not what you want.

Well, WTF? You think to yourself, how am I supposed to do that? Newsflash: You need to figure it out because that’s why you get paid the big bucks. As an independent consultant now, I have some leeway to do my due diligence and decline projects that look risky or are implementing tech stacks of which I don’t approve. As an employee for a consulting company, I went where they pointed me and I liked it. And I figured it out, because they paid me a boatload of money to use my brain.

Something you will hear often as a consultant: “That’s a great idea, but we’re not going to it.” A client once decided to implement mission critical queuing on WebSphere Application Server’s internal message bus. I could and did explain that this solution was not robust until I was blue in the face, but the fact is, WebSphere MQ software is expensive and open source wasn’t an option(because). Retail order fulfillment queuing was implemented where they wanted it and I spent my days and nights reading up on how to ensure as little data loss (orders, right?!) as possible if the unclustered, non-redundant server went down. As an aside, I should note that this client has since gone out of business.

You can’t be emotionally attached to your ideas. I know you think you have the one true path to success. You don’t. Regardless of how smart you are, the customer knows their systems better and they know their politics better. They know what can be accomplished. Get used to having your ideas shot down and don’t let it upset you. Don’t hang on to them. You need to get over it and move on. If you’re still hanging on to today’s disagreements tomorrow, you won’t be able to think clearly tomorrow about new technical challenges.

Pick Your Battles

Sometimes you’ll encounter strong opposing opinions. If you’re an IT consultant, it’s guaranteed. Remember, 95% of battles do not need to be fought. Just because you don’t approve of a naming convention is no reason to argue, especially if another engineer is in love with it. You might implement applications that need nightly rolling restarts, even if you could prove they don’t need it, just because management has been burned in the past. Don’t fight it. Nightly restarts aren’t the end of the world. You might meet a team who wants to migrate all of their bash scripts verbatim into configuration management. This would be a hard one for me to let go, and I might try to convince people not to do it, but I would concede in the end, because refactoring exists.

Save up your argues for when it matters. Eventually you will come upon something you absolutely won’t want to compromise. If you haven’t been arguing about everything up to this point, it’s likely people will actually listen when you bring it up.

Your job isn’t to say no. It’s to say yes. If your first inclination is to dismiss an idea or say no, stop and think about why. Do you have valid concerns? What is a valid concern? A valid concern might be a high availability requirement with only one database server in the plan. That’s a problem. But you still don’t get to say no. That’s not your job. Instead you should point out the very obvious risk involved in zero redundancy. Several years ago, I was presented with a client’s server plan that I knew would never survive the first engagement. In this case, we knew they were trying to save as much money as possible, so the consulting team got together in a room and came up with a perfect world scenario and then two less expensive alternatives that allowed for some robustness while saving on hardware expenses. I then power pointed the entire thing and presented to senior management. I had been consulting for all of 3 months at the time and was petrified but we won them over to one of our solutions in the end.

This isn’t relevant to me, I’m a full time employee

Are you on an ops team? Do you work with development teams to get apps into production? How about a monitoring team? Do you work with devs to create coherent actionable alerts? Then you are a consultant. Developers care about one thing: writing code. Some developers do care about more and have the background to be interested in more, but in general, especially in big companies or outsourced development, all devs care about is writing code. They don’t know how anything else works. It doesn’t make them dumb, it makes them part of a world of which you only see a part.

This makes you their enabler and a consultant. You have knowledge critical to their success. It’s not just your job to provide them with an app container and now buzz off. You’re their lifeline to the rest of the infrastructure. Telling them “no” or ridiculing an idea will only make them angry and determined to circumvent all the sane safeguards you’ve put into place for everyone’s good.

Instead of treating development teams like they know nothing, take a moment to find out why they want to do what they’re doing. Many times you’ll find that they’ve actually just spent two solid days trying to solve a prickly problem and this is the only working viable option they’ve found. Maybe your perspective will help you advise them on a better way, or they could be right and you could be stuck with something suboptimal. At this point, instead of being grumpy about it, start figuring out ways to limit the damage or make it more robust and work with your dev instead of against him. Full time employees, I’m talking to you.

Consulting isn’t for everyone. If you can’t learn to take deep breaths and count to ten, it might not be for you. I still make mistakes and have often been grateful for working remote where I can wear my rage face in private. In the end, you have to be able to let it all roll over you. This isn’t your infrastructure and sometimes compromises must be made.

For me, consulting is emotionally easier in some ways because I can accept decisions with which I don’t necessarily agree, knowing that I won’t be around to see the heartache in a year. All I can do is my best with whatever is under my control. And my best is impressive. I am a master tweaker and I document the hell out of ALL THE THINGS. But I often see sacrifices of stability for expediency and it does hurt me. I’ve just learned to not let it hurt too much. The great thing about consulting is, if this project didn’t work out exactly the way you wished, the next one is right around the corner, waiting for you bring it all your awesomeness.

Wherein Sascha Ponders a Question

That's Already Been Asked a Million Times

What is DevOps? 2 years ago I had no idea. I was living the cycle of poorly planned, crappily implemented projects where artisan server builds were the only way anything was built, even when it meant 125 servers. I actually had a PM say to my team, We don't have TIME to plan! You need to start building servers! I was gone for two weeks to Europe right after that and when I came back, one of my sysadmins had indeed kickstarted all 125 servers. We then spent the next 6 months fixing configurations via ssh cli foo (for i in servers; do ssh $i some monkeypatch;done).

I tell you this anecdote so you can understand the utter delight and abandon with which I embraced the DevOps movment when introduced 18 months ago. I was immediately wowed by the positive, inclusive attitude. I read about continuous deployment, continuous integration, test driven deployment, configuration management tools and the personal experiences of several people. I found the DTO blog, the Agile Admin and, of course, the Etsy Code as Craft blog.

It's great to see people engaged, animated and motivated to make things awesome. Instead of being beat down, embracing the ops-as-victims lifestyle, they've taken charge of their world and started trying to change what's not working instead of just turning into the troll under the bridge. I've spent over 10 years in corporate and I know how easy it is to feel beat down by the constant cycle of develop, implement, fail, support the failure forever. So I love me a movement that engages and tries to proactively to end the failure cycle.

In June I had my first community interaction events at Velocity and Devopsdays, in San Jose. The atmosphere was different from any other industry conference I've attended in the past. It was awesome. The energy was amazing. Many of the talks were inspiring(John Allspaw, Adam Jacob, I'm talking to you). I finished the week with a hyperactive energy and desire to channel that energy into about 10 new things I'd learned about.

A common theme during presentations, panels and over beer was the attempt to define the DevOps movement. I heard a lot of people at Velocity tell me what it's not. It's not a tool, it's not a job, it's not a job description; it's not a title. I heard a lot of, if you claim to be 'devops,' yer doin it wrong.

Interestingly, in high school and college, I ran with a punk rock/goth crowd with a similar attitude. If you claim you're punk rock or goth, yer doin it wrong. We were too cool for labels. In our own minds, we were outside the labeling system. Sticking a label on us or on yourself was lame and small minded. We'd say things like, I'm not goth. I'm just myself. I don't conform to labels. We were pretentious by pretending that only pretentious people actually labeled themselves. If you claimed to be punk, obviously you were a poser.

I'm sensing a lot of that same attitude from the folks who say, if you call yourself a devop, yer doin it wrong. I understand some of the desire to protect the movement from spoilage and the term from overuse. We want to keep our counterculture to ourselves. It's not for the likes of HP and IBM and their re-branding of old, tired products.

I understand what people mean. Labels get in the way of the movement. Labels are limiting and, if you say you do devops you risk limiting yourself and the perceptions of others. I can even empathize. Every time a job comes through my inbox labeled devops, I cynically assume it's someone who wants to rope some poor sap of a sysadmin into a crap job by labeling it with something cool, probably hoping to get two kinds of work for the price of one.

Everyone claims to be living in the DevOps moment, but what does it really mean? Several people have asked this question and tried to answer it. My business card has 'DevOps' on it. But it also says Problem Solving, Middleware and other things. How dare I list Devops among my skill set? Here's the thing. If DevOps isn't a tool, if it isn't a job description, if it isn't a title, it still must describe something right? It can't be an empty set. Here's what I was thinking when I put it on my card. DevOps is a framework and a philosophy. It's a lightly codified framework for an attitude and approach to solving problems. DevOps contains the seeds from which a better culture can grow. It assumes inclusiveness, accountability and that everyone is smart. It dismisses boundaries. When I put DevOps on my business card, what I'm saying is, the word defines part of the way I think, the way I approach problem solving and it also defines the attitude I'm looking for when evaluating engagements.

Because of all the positive vibe around DevOps, it bothers me when I see snotty tweets or hear snarky remarks during conference presentations. You can call bullshit when HP starts trying to claim that its monitoring suite is devops friendly, or when Gartner starts writing articles that could be subtitled How to cash in on the DevOps movement. But projecting an attitude of exclusivity or just plain snark because you're feeling protective can only hurt things. New folks are continually stumbling upon parts of DevOps or agile infrastructure as a movement. Some of them have been living the attitude for years and maybe just now realizing there are others out there. I guess I'd rather be a hippy flashing a peace sign at people who happen across DevOps than a hipster turning my nose up at anyone who doesn't meet my specific criteria for cool.

Wherein Sascha Ponders a Question

That's Already Been Asked a Million Times

What is DevOps? 2 years ago I had no idea. I was living the cycle of poorly planned, crappily implemented projects where artisan server builds were the only way anything was built, even when it meant 125 servers. I actually had a PM say to my team, We don't have TIME to plan! You need to start building servers! I was gone for two weeks to Europe right after that and when I came back, one of my sysadmins had indeed kickstarted all 125 servers. We then spent the next 6 months fixing configurations via ssh cli foo (for i in servers; do ssh $i some monkeypatch;done).

I tell you this anecdote so you can understand the utter delight and abandon with which I embraced the DevOps movment when introduced 18 months ago. I was immediately wowed by the positive, inclusive attitude. I read about continuous deployment, continuous integration, test driven deployment, configuration management tools and the personal experiences of several people. I found the DTO blog, the Agile Admin and, of course, the Etsy Code as Craft blog.

It's great to see people engaged, animated and motivated to make things awesome. Instead of being beat down, embracing the ops-as-victims lifestyle, they've taken charge of their world and started trying to change what's not working instead of just turning into the troll under the bridge. I've spent over 10 years in corporate and I know how easy it is to feel beat down by the constant cycle of develop, implement, fail, support the failure forever. So I love me a movement that engages and tries to proactively to end the failure cycle.

In June I had my first community interaction events at Velocity and Devopsdays, in San Jose. The atmosphere was different from any other industry conference I've attended in the past. It was awesome. The energy was amazing. Many of the talks were inspiring(John Allspaw, Adam Jacob, I'm talking to you). I finished the week with a hyperactive energy and desire to channel that energy into about 10 new things I'd learned about.

A common theme during presentations, panels and over beer was the attempt to define the DevOps movement. I heard a lot of people at Velocity tell me what it's not. It's not a tool, it's not a job, it's not a job description; it's not a title. I heard a lot of, if you claim to be 'devops,' yer doin it wrong.

Interestingly, in high school and college, I ran with a punk rock/goth crowd with a similar attitude. If you claim you're punk rock or goth, yer doin it wrong. We were too cool for labels. In our own minds, we were outside the labeling system. Sticking a label on us or on yourself was lame and small minded. We'd say things like, I'm not goth. I'm just myself. I don't conform to labels. We were pretentious by pretending that only pretentious people actually labeled themselves. If you claimed to be punk, obviously you were a poser.

I'm sensing a lot of that same attitude from the folks who say, if you call yourself a devop, yer doin it wrong. I understand some of the desire to protect the movement from spoilage and the term from overuse. We want to keep our counterculture to ourselves. It's not for the likes of HP and IBM and their re-branding of old, tired products.

I understand what people mean. Labels get in the way of the movement. Labels are limiting and, if you say you do devops you risk limiting yourself and the perceptions of others. I can even empathize. Every time a job comes through my inbox labeled devops, I cynically assume it's someone who wants to rope some poor sap of a sysadmin into a crap job by labeling it with something cool, probably hoping to get two kinds of work for the price of one.

Everyone claims to be living in the DevOps moment, but what does it really mean? Several people have asked this question and tried to answer it. My business card has 'DevOps' on it. But it also says Problem Solving, Middleware and other things. How dare I list Devops among my skill set? Here's the thing. If DevOps isn't a tool, if it isn't a job description, if it isn't a title, it still must describe something right? It can't be an empty set. Here's what I was thinking when I put it on my card. DevOps is a framework and a philosophy. It's a lightly codified framework for an attitude and approach to solving problems. DevOps contains the seeds from which a better culture can grow. It assumes inclusiveness, accountability and that everyone is smart. It dismisses boundaries. When I put DevOps on my business card, what I'm saying is, the word defines part of the way I think, the way I approach problem solving and it also defines the attitude I'm looking for when evaluating engagements.

Because of all the positive vibe around DevOps, it bothers me when I see snotty tweets or hear snarky remarks during conference presentations. You can call bullshit when HP starts trying to claim that its monitoring suite is devops friendly, or when Gartner starts writing articles that could be subtitled How to cash in on the DevOps movement. But projecting an attitude of exclusivity or just plain snark because you're feeling protective can only hurt things. New folks are continually stumbling upon parts of DevOps or agile infrastructure as a movement. Some of them have been living the attitude for years and maybe just now realizing there are others out there. I guess I'd rather be a hippy flashing a peace sign at people who happen across DevOps than a hipster turning my nose up at anyone who doesn't meet my specific criteria for cool.


I do nerdy stuff with computers. Sometimes I talk about it here. Beware of opinions. I have them. They totally reflect my employer since I employ myself.

Email Sascha




Search Bratty Redhead

The sidebar

The sidebar, spanning 1 of 3

The sidebar, spanning 1 of 3

The sidebar, spanning 1 of 3

The sidebar, spanning 1 of 3

The sidebar, spanning 1 of 3

The sidebar, spanning 1 of 3

The sidebar, spanning 1 of 3

The sidebar

The sidebar, spanning 1 of 3

The sidebar, spanning 1 of 3

The sidebar, spanning 1 of 3

The sidebar, spanning 1 of 3

The sidebar, spanning 1 of 3

The sidebar, spanning 1 of 3

The sidebar, spanning 1 of 3


"Yes, there is coffee here."
I love artisan coffee.