Category: IT

Review: Devops in Practice

September 15, 2014 / / 0 Comments

I read Devops In Practice by O’Reilly. It’s more like a booklet, but I am not sure how they categorize it. Either way, it’s not a bad read. It’s authored by Paul Reed and talks about devops experiences at a couple of companies; namely Nordstrom and Texas.gov.

This is a topic for a different (and much longer post), but devops in general tends to lack specific guidelines and I think that hinders adoption at larger companies.  In enterprise space, people often like to have formal methodologies (ITIL, Agile/Scrum come to mind), even though following the process without understanding the underlying philosophy isn’t going to get you very far. But I digress.

What I liked about Devops in Practice is that it highlights the cultural challenges of a devops transformation. In my mind that’s the first and foremost component that’s often circumvented by “let’s create a devops/tools team” approach.

The first company talked about in the book is Nordstrom. It seems like they had all the usual suspects in place. Separate dev and ops, monolithic apps (arguable if that’s incompatible with devops), lots one-off scripts and so on. They started figuring out that as they needed to deliver faster, “throw it over the wall” mentality wasn’t cutting it anymore.

The solution or rather the path to a solution revolved around embedding people into teams, optimizing for speed-to-value and figuring out their value stream. They also discovered that you need to “optimize the whole“, which is a lean concept that also applies to ops/devops/infrastructure.

At the end it briefly talks about wrapping services into APIs and the organic spread of their model. The second part is a bit more brief, but touches on a concept of integrating security practices with a devops model at Texas.gov.

All in all, it’s a good high level summary of approaches taken at two different organizations. The details are very sparse and I would have liked to see more about what failed and why in their earlier approaches (outside of one example given). It would have also been great to read more about the techniques they used to propagate the culture. However, it’s a good introduction and could be a valuable example/reference to use if you’re trying to sell the mythical devops in your own organization.

 

Go Language

September 24, 2013 / / 0 Comments

It’s a relatively new language that came out of Google a few years ago. I’ve been playing around with it and trying to learn some of the basics. There some things that are very attractive about Go, not the least of which are the ability to get out of dependency hell and being able to distribute a single binary. Concurrency features are interesting as well.

Recently I came across a post from one of the Go authors and why he sees more people coming to go from Ruby & Python rather than C++, which is at least true for myself and it rings very true. No one ever wants to feel like things are being taken away from them. Not to pile on C++, especially since my experience with it is limited to a few intro courses in college (which were pretty bad and probably scared me away from it), but a few years ago, Linus also had a few choice words (as usual) about C++ as well.

Rich Hickey’s talk titled “Simple Made Easy” also has some relevance to this concept and I can’t help but think of this Exupery quote:

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away

 

 

Do Things that Don’t Scale

July 15, 2013 / / 0 Comments

I was reading the latest Paul Graham essay: “Do Things That Don’t Scale” and it got me thinking about devops, infrastructure automation and why “tools” teams fail. I am sure I am suffering through a bit of a confirmation bias here, but this article can easily be applied to a team or a culture within a company. If you see yourself as a startup, you have to think who are going to be the users/customers/stakeholders of your product and what you need to do to delight them. That’s a path to success.

The quote that jumped out to me the most was this:

If you can find someone with a problem that needs solving and you can solve it manually, go ahead and do that for as long as you can, and then gradually automate the bottlenecks. It would be a little frightening to be solving users’ problems in a way that wasn’t yet automatic, but less frightening than the far more common case of having something automatic that doesn’t yet solve anyone’s problems.

I think that ties right back into the devops philosophy of people over process over tools and why a simple “automate all the things” approach is sometimes not enough.