My company is starting to be more and more involved in using some of the tools that make up the DevOps stack. Part of this work involves using tools like Docker natively in combination with hardware solutions such as Nimble Storage to provide a solution to customers that integrates well with their adoption of agile principles and workflows. Other engagements will be designed to actually educate our customers on the benefits and disciplines of an Agile Workflow and to help them achieve better synergy between the development and operations teams.
To that end, I’m going to be writing a series of posts on different components that make up DevOps from the tool perspective as we get more and more exposure to them. A website called The Agile Admin has done a great job in defining just what DevOps is and what it means. Below is a snippet from their website that pretty much covers it very well.
DevOps is a new term emerging from the collision of two major related trends. The first was also called “agile system administration” or “agile operations”; it sprang from applying newer Agile and Lean approaches to operations work. The second is a much expanded understanding of the value of collaboration between development and operations staff throughout all stages of the development lifecycle when creating and operating a service, and how important operations has become in our increasingly service-oriented world
Having been in the IT industry for over a quarter century, I’ve seen the division between Development and Operations very clearly defined. They are very distinct pillars of job functions which fall into categories like Storage, Server Ops, Networking, Development/Coding and such. These pillars have very distinct borders that are enforced by things like policies, request forms, response SLA’s and standardized methods of deployment. It isn’t too uncommon for projects to enter the planning, architecture and implementation phases and take a terrible amount of time to complete. More concerning is the concept that each pillar which is responsible for it’s part has very little knowledge or understanding of other pillar’s functions. This dramatically reduces the effectiveness of the whole project because it eliminates many touch points that could potentially identify a critical flaw in the final product. It also eliminates the majority of perspectives of the team as a whole that almost always brings value when considered throughout the process.
This is somewhat of a learning process for me, but it’s based on observations and involvement in different aspects of the operations side of things. I’ve seen the trend towards a more DevOps type model being enforced by the pure nature of new converged and hyperconverged systems. What used to be strictly an operational function such as provisioning a LUN and presenting it to servers, is now being offered to the developer side of the house (think self provisioning). While this has the effect of moving what used to be an operational function over to the developer making their job much easier and quick, it is by no means true DevOps.
I urge spirited conversation on this topic below- there are many contrasting perspectives regarding DevOps and Agile Workflow that I’m interested in hearing about.