“DevOps” has become one of the industry’s latest go-to buzzwords. DevOps is nothing new. It’s been popularized through a series of DevOpsDays conferences that started in 2009 in Belgium, and the term “DevOps” was in common use online by the spring of 2010.
How do you define DevOps? One complaint about DevOps is that it’s difficult to describe to others. I think part of the reason for that is that DevOps is a philosophical concept as well as a fundamental change in the way IT will be done as we move forward in the twenty-first century. DevOps is currently building a collection of best practices and procedures, which should come together with the philosophy as the concept matures over time.
So, let me take my best shot at describing DevOps, and why I think it will change the way of IT moving forward. DevOps combines development and operations engineers into a cross-disciplinary community dedicated to the complete lifecycle of the systems being developed and used, while evolving agile software development processes along the way to deliver this to scale.
Second-day operations utilize the same tools employed by the developers, as more of the daily support and operations of infrastructure are replaced by automated processes. DevOps is not something you just implement, but rather a journey along the IT way.
In my opinion, there are so many different implementations that a standard “run book” may never be written. What will be written instead is a dynamic operational playbook that will continue to evolve as lessons are learned in real life. Based on the Agile Manifesto, there are four aspects of Agile Development: Values, Principles, Methods, and Practices, all of which have evolved along the way to make up the current DevOps philosophy and concepts.
Advantages of DevOps as a philosophical stance include the breaking down of IT silo barriers and the return to the collaborative efficiency of different disciplines’ working directly together at each phase from inception to completion. I see a future in which coding is the common thread between teams, which are organized by areas of functionality. For example, the storage team would both handle storage management and present the storage automation to the overall collaboration of the various teams.
This won’t change overnight, but I do believe the sails have been deployed and this ship is tacking into the winds. Could small strike groups of different DevOps teams be responsible for the complete life cycles of different systems, or will we have larger teams to collaborate with? In my opinion, the smaller teams will be in the best position to be more agile, but no concept is set in stone. It will be interesting to see how DevOps shapes the future of IT.
As soon as the DevOps culture is established in an organization, there are a few changes observed right away. Unlike the previous manner now Developers create servers on their own, with the help of code. And do not need to ask the System administrators for the server to test code or database server to set up data, they can create it with the code now.
Independently developers can now deploy apps completely and do not need anyone else to set the servers up for deployment and when it comes to updating some version, they do it rapidly without waiting for someone to do it for them. This doesn’t depict that system administrators are idle now or got nothing to do, they are the reason behind all of it going on and managing all the servers. On the other side, operations can manage as many servers as needed.