DevOps is not a complicated idea. It’s just people working together instead of separately in silos.
Put it in context of your own family’s household. Each member of the family has his or her own specialty. Usually, someone is the primary breadwinner and someone is the primary caregiver. But in a well-functioning household, people share the load and responsibility for making sure things happen and goals are accomplished. People know each other’s jobs and oftentimes perform them. They are on the same page.
The same goes with DevOps, as former Google and eBay DevOps director Randy Shoup found when he first landed in a shop that practiced the methodology early in his career. A great interview with Shoup leads this installment of Decoding DevOps.
Randy Shoup: ‘Fewer and fewer places’ where you can avoid DevOps
In the above-mentioned interview with SiliconRepublic’s John Kennedy, Shoup says DevOps is becoming more the rule than the exception:
“There are fewer and fewer places where the objections ‘I can’t do DevOps’ will fly. We are seeing large enterprises doing these continuous deliveries in organizational and cultural practices. We are seeing hardware companies do this stuff and several auto companies like Tesla and GM are great at this.
“There are an amazing amount of companies where you wouldn’t’ have thought it was possible to do these practices that are moving seriously into DevOps.”
Taking DevOps to the next level
Over at Infoworld, David Linthicum offers up a look at infrastructure as code (IaC), which he says is taking the principles of DevOps to a new area by configuring cloud-based infrastructure via applications, using APIs.
He writes that there are three reasons for the IaC approach:
- Flexibility: The ability to allocate storage, memry and processor instances as needed or dictated by needs, not according to limitations of the platform.
- Cost savings: Use only the resources you need, thus saving money with each application.
- Resources savings: Simple. You don’t need as much human or technology capital as control reverts to developers.
“The larger question: Is passing control of the infrastructure to developers a good thing? You bet. With the rise of DevOps and its tight coupling of developers and operations, the ability for developers to dynamically configure their deployment platforms via APIs is a better way to manage many applications and many platform instances.”
DevOps: Automating you into more interesting work
Over at InfoWorld, Eric Knorr interviewed Bruno Connelly’s transformation of LinkedIn. The piece is worth your time.
Connelly has led site reliability for 5 1/2 years — the period during which LinkedIn cemented its position as the leading site for social connectivity in business. LinkedIn grew from 80 million to nearly 400 million users during his tenure.
As Knorr notes, LinkedIn was creaking under the load of increasing traffic when Connelly started there. There were only “six or seven” on the team, Connelly says.
“I was hired … specifically to scale the product, to take us from one data center to multiple data centers, but also to lead the cultural transition of the operations team.”
Knorr asked Connelly whether the widespread implementation of self-service automation was a sticking point with engineers who feared being automated out of work. The response from Connelly gets to major point of cultural resistance to DevOps and why it’s a myth:
“My personal opinion is that is absolutely the right goal. We should be automating ourselves out of a job. In my experience, though, that never happens — it’s an unreachable goal. That’s point one … point two is there’s a lot of other stuff that SREs do, especially what we call embedded SREs. They are part of product teams; they are involved with the design of new applications and infrastructure from the ground up so they are contributing to the actual design. ‘Hey, there should be a cache here, this should fail this way …'”
That’s a great point, and one we’ve made here previously: Done right, DevOps automates engineers out of boring work and into more interesting, creative problem-solving.