DevOps the culture change
Atul Joshi
Experienced Technology Leader | Senior Architect @ Western Union | AWS Certified Solutions Architect
Over the years software was developed by the specialized teams, where individuals played specific roles. Developers, architects and managers focused on building an application. Testing teams had skills to test an application. Database and security experts helped in building some foundations and finally infrastructure/system administrators played important role of hosting and monitoring your application. This certainly worked but also created partitions, hierarchies and resulting bureaucracy. Something was missing – product ownership, speed to market, incremental changes and team commitment were the areas that went into the red. What was wrong? Well… single multi-skilled and empowered team could be the answer. This team must have the purpose and ownership of an application or a part of it.
Emergence of Agile methodology is all about empowering a team to deliver incremental, working application which is fully owned by the team. To support an application end-to-end, this team has to be multi skilled and also dependent on engineering practices to ensure quality of a system. This implies that processes must be complemented by set of engineering practices to build quality software. This doctrine is nothing but DevOps where agile teams have quality factor in mind with full set of ownership.
Agile methodology is increasingly popular due to various factors – fail early, incremental delivery, business representation, value and finally working software over the documentation; it is pretty natural for it to impact all aspects of development life-cycle. Take example of microservices pattern – to me this has become popular mainly because it enables small team to take ownership of independent piece of software; of-course various other technical advantages can’t be denied.
Effective Devops implies few basic considerations – 1. Multi skilled team handling development, implementation and monitoring 2. Automation over manual tasks 3. Effective collaboration of code and 4. Standard set of tools and continuous improvements. Some fundamental changes to the overall application development means 1. TDD is must! 2. Effective refactoring for existing code and 3. Modular units of functionality are extremely essentials.
Traditional organization’s development culture may not support all this aspect as this means increased initial development cost, skill-set reviews and flat hierarchies. But it is very essential to push these changes at its fullest rather than “doing few things”; which would never give you its real benefits.
Of-course there are many challenges to this shift towards the full DevOps adaption like business priorities, legacy systems, proprietary platforms and required skill-set refresh; but I am sure as more and more success stories emerge, as DevOps tool-sets become more powerful, we would see adaptation of this culture is only normal and natural to all development projects rather than some passing buzzword.
Entrepreneur, Technologist, Leader, Mentor, Student
7 年Well articulated!! Questions: Do all lines of business need DevOps? If so, do all products have rigid 'Time to Market' constraints? If so, do all products have releases every Sprint? Do we really need DevOps if the end user sees the changes only once or twice in a year? I'm of the view, we shouldn't cook the dish even before the customer orders. Most likely it will end up resting in the refrigerator. It's a wonderful technology only when there is a need.