DevOps: There’s a new sheriff in Cloudville September 9, 2010
Posted by Rob H in Clouds, Hiring.Tags: Architecture, cloud, DevOps, RAIN
trackback
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!
[...] Z. Management: Insource vs. Outsource. Don’t over think this vector, but remember I not talking about off shoring! If you are directly paying people to manage your cloud then you’ve insourced management. If the host provides services, process or automation that reduces hiring requirements then you’re outsourcing it IT. It’s critical to realize that you can’t employee fractional people. There are fundamental cloud skillsets and tools that must be provided to operate a cloud (including, not limited to DevOps). [...]
[...] For cloud deployments, this means building operational knowledge in stages. Technology is simply evolving too quickly and best practices too slowly for anyone to wait for a packaged solution to solve all their cloud infrastructure problems. We tried this and it does not work: clouds are a mixture hardware, software and operations. More accurately, clouds are an operational model supported by hardware and software. Currently, 80% of cloud deployment effort is operations (or “DevOps“). [...]
[...] model” or “cloud ops” to Dell internal and external customers. CloudOps is really just DevOps but packaged more broadly to help explain how hardware, software, and operations interact. The [...]
[...] the app paradigm from robust scale up hardware to robust scale out software. Also significant, DevOps innovations have made deployments repeatable and [...]
Rob,
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 Willis
VP Solutions
DTO Solutions
a.k.a @botchagalupe
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.
ohn
[...] cloud deployments. Along the way, we realized Crowbar’s true potential lay in embracing DevOps as an operational model for maintaining clouds. That meant building up cloud deployments in layers [...]