Originally posted on our Google+ page. Go ahead, circle us.
First off let me say one thing, I'm no expert on DevOps and to tell you the truth I've read a lot of articles on this subject and I haven't seen an expert out there. The one thing I do know is every article on this subject needs to start with the author stating his or her technical background so you get a better perspective of the article’s point of view. What I think you would find is that 90% of the authors who are supportive of DevOps have a development focused background. This isn't to say that that operation folks don't support DevOps, but much less then development teams.
For the last 12 years, I held positions from phone support for Dell Computers to Business Analyst for a multimillion dollar government software project. My industry certifications cover system administration as well as software development process and procedures and I've even dabbled in ITIL. Currently, I develop ZenPacks for Zenoss as a Senior Solutions Developer which puts me in the unique role of working directly on customer requirements and interfacing with development.
DevOps is Four-Fold
So what is this DevOps anyway? When I first started on this topic I wasn't sure if it referred to a new process, a new role or some other kind of movement. What I found was it could refer to all three. First, the DevOps process is one that focuses on cross organizational integration and communication. All processes should include the development, QA, and operations teams on discussions of development, testing and deployment activities. This focus on communication is targeting the walls put up between departments that result in confusion and misinterpretation of the project intentions and the never-ending finger pointing.
Second, the DevOps role is an organizational person that focuses on bridging the communication between departments inside an organization. This role is focused on navigating the organizational and political challenges that hamper all software projects such as who has ownership of what.
Third, the DevOps movement is one that believes all we have to do is talk with each other and all our software deployment issues will evaporate into thin air.
Lastly, as DevOps Borat says...
Operations vs. Devemopment
On the Operations side, they are focused on providing highly available secure services to its customers. To provide this, they drive to keep the environment as static as possible. Service disruptions mainly happen when changes are introduced into an environment. To lessen the impact of changes, most operation teams have very strict policies when deploying code. This team is responsible for 24/7 operations and don't have the luxury of shutting down for holidays or weekends.
And on the other hand, the Development side is focused on providing stable and feature rich software. The development team is one of the revenue generating teams inside a company, even if it's an in-house development team. They make it possible for the company to operate. They are the blacksmiths that turn raw steel into tools for the rest of the company to use or sell.
Cloud Impact
The roll-out of Cloud computing will have the greatest impact on solving these deployment issues. The uptime challenge that faces our operations team will become less of an issue as the cloud becomes more resilient. With the availability zone layer moving into the development arena they can now build applications that take advantage of redundancy. The ease of building and deploying cloud images will allow developers to test against a near real-production environment. This should lessen the "It works on my machine" problem that we so often face.
Communication is DevOps
The idea that the biggest problem is lack of communication is naive and deceptive to our teams. We have to understand that software development is complex and problems will happen. Code will be wrong and servers will be misconfigured. This isn't to say that it can't be better, but it is a reality that must be accepted and planned for. We have moved to a society that cannot tolerate any failure of any kind.
In the end we all need to work together to succeed. The adoption of DevOps methodologies is important. Greater communication between our teams can only make us better. But I have to ask, isn't this obvious? Do we need to have it outlined as DevOps? My question is that if communication wasn't happening between organizations, how does DevOps make that happen? The challenge is to get the teams working together on the same goal and that is in most cases is revenue generation. It's a balancing act that good managers and good employees will succeed in and bad ones won't.
Don't find fault, find a remedy! ~ Henry Ford
