Lately there’s a flurry of interest (and hiring demand) for DevOps gurus. It’s obvious to me that there’s as much agreement between the ethical use of ground unicorn horn as there is about the job description of a DevOps tech.
I look at the world very simply:
- Developers = generate revenue
- Ops = control expenses
- DevOps = write code, setup infrastructure, ??? IDK!
Before I risk my supply of ethically obtained unicorn powder by defining DevOps, I want to explore why DevOps is suddenly hot. With cloud driving horizontal scale applications (see RAIN posts), there’s been a sea change in the type of expertise needed to manage an application.
Stereotypically, Ops teams get code over the transom from Dev teams. They have the job of turning the code into a smoothly running application. That requires rigid controls and safe guards. Traditionally, Ops could manage most of the scale and security aspects of an application with traditional scale-up, reliability, and network security practices. These practices naturally created some IT expense and policy rigidity; however, that’s what it takes to keep the lights on with 5 nines (or 5 nyets if you’re an IT customer).
Stereotypically, Dev teams live a carpe diem struggle to turn their latest code into deployed product with the least delay. They have the job of capturing mercurial customer value by changing applications rapidly. Traditionally, they have assumed that problems like scale, reliability, and security could be added after the fact or fixed as they are discovered. These practices naturally created a need to constantly evolve.
In the go-go cloud world, Dev teams are by-passing Ops by getting infrastructure directly from an IaaS provider. Meanwhile, IaaS does not provide Ops the tools, access, and controls that they have traditionally relied on for control and management. Consequently, Dev teams have found themselves having to stage, manage and deploy applications with little expertise in operations. Further, Ops teams have found themselves handed running cloud applications that they have to secure, scale and maintain applications without the tools they have historically relied on.
DevOps has emerged as the way to fill that gap. The DevOps hero is comfortable flying blind on an outsourced virtualized cloud, dealing with Ops issues to tighten controls and talking shop with Dev to make needed changes to architecture. It’s a very difficult job because of the scope of skills and the utter lack of proven best practices.
So what is a day in the life of a DevOp? Here’s my list:
- Design and deploy scale out architecture
- Identify and solve performance bottlenecks
- Interact with developers to leverage cloud services
- Interact with operations to integrate with enterprise services
- Audit and secure applications
- Manage application footprint based on scale
- Automate actions on managed infrastructure
This job is so difficult that I think the market cannot supply the needed experts. That deficit is becoming a forcing function where the cloud industry is being driven to adopt technologies and architectures that reduce the dependence for DevOps skills. Now, that’s the topic for a future post!
Pingback: Cloud Business Vectors « Rob Hirschfeld's Blog
Pingback: Substituting Action for Knowledge – adopting “ready, fire, aim” as a strategy (and when to run like hell) « Rob Hirschfeld's Blog
Pingback: OpenStack is ready, but are you? Get some operational cloud mojo and get started! #OpenStack #CloudOps « Rob Hirschfeld's Blog
Pingback: Bad Premise: Cloud Outages are *not* driving IT back to premises « Rob Hirschfeld's Blog
Great post. I think the main #devops point is that it’s not a third new group. It’s just two groups working together in a collaborative way. Also, the notion that “Ops” is const control is anti #devops. The new “infra” companies realize that “Ops” is a strategic weapon and is as musch about cost control as a fully automated assembly line see ( http://ow.ly/66Hr3 ). Also, I totally agree that the market is having a hard time finding both dev and ops who understand the true secret sauce behind #devops.
John – thanks! good point – DevOps *should* be a mixing place, not a third thing. In some ways the idea that it is a different thing comes from the different DevOps assumptions. Unfortunately, Changed assumptions can create a lot of friction!
That is why I always like to talk about “Culture” first when talking about #devops. Not attacking that problem first could leave you with a dev/ops/other situation and now you’ve made it even worse.
Pingback: Crowbar modularized: latest changes that make clouds even easier to create, update, and maintain « Rob Hirschfeld's Blog