Tagdevops

Review: Devops in Practice

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.

 

docker at devo.ps

Not a bad post on how these guys use docker.

http://devo.ps/blog/docker-dos-and-donts/

Devops at RedHat

Observations on the challenges that guys at Red Hat had when implementing devops in their organization. I like their focus on communication and on having an MVP for a single dev team as a proof-of-concept.

http://developerblog.redhat.com/2014/03/05/rh-devops-journey-harder/

Do Things that Don’t Scale

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.

 

 

 

Technology divide

A couple of articles surfaced in the last few days, which describe the tech operations of Obama and Romney campaigns. It’s hard to put a number on the advantage that Obama had on the tech side, but considering the relatively small margin of victory, it was probably not insignificant.

Narwal (Obama) - http://www.theatlantic.com/technology/archive/2012/11/when-the-nerds-go-marching-in/265325/?single_page=true

Orca (Romney) - http://arstechnica.com/information-technology/2012/11/which-consultants-built-romneys-project-orca-none-of-them/

 

I think this is a great example of the advantage that tech can bring to any business, politics or anything else. It’s often hard to quantify in hard numbers and can be especially difficult for people in positions that are further removed from technology, but it works. And not only they had a “devops guy”, I have no doubt they ran their IT aligned with devops principles. If it was good enough for Obama’s campaign, then it’s probably good enough for others as well.

 

 

 

© 2017 Mind End

Theme by Anders NorenUp ↑