DevOps : The new big thing in software industry

DevOps is ‘the thing’ right now in software development. Every company and every engineer is interested in adopting to DevOps. While I have interacted with many who have clear understanding of DevOps, majority of those who never worked in such environment, often have misunderstood DevOps. In this post, I explain what really DevOps is.

Software Development model

This is what we all learned in college (Software Development process). Essentially, software development is broken into five clear stages. Requirement gathering, architecture design, software implementation, verification and maintenance. Each part takes long time, depending on complexity of software.

Traditional development environment

If you see product companies, each team sits in their own silo (building/floor/zone). Ops/IT team sits in one corner while developers sits in another corner. Development teams hand over their hardware and software requirement to Ops and the necessary development environment is created. Development environment is created by setting up necessary servers, tools and access is provided to these users so that they can work on designing new software. When developers feel that the software is ready, testing is started (regression, performance, burn, smoke etc). For testing, operations team sets up testing environment. Then comes performance testing environment and then the production environment. During all these phases there is not much interaction between development teams and operations teams.

Interaction with Infrastructure team happens when something need to be changed or if there is a problem that is causing development team’s work to stall. Environment is setup at each stage and if there is a large scale infrastructure change required, it usually takes time. Sometimes, a development team would have forecasted/requested for large scale infrastructure that they severely underutilize. Another development team in same office would have forecasted/requested for environment that is not enough for them. In such case, infra has wasted money on on set of infrastructure and the other development team is going to lose valuable time as they do not have infrastructure that is powerful enough. Making changes after infrastructure is setup can take lot of valuable time.

DevOps Is NOT

DevOps is not Agile and it is not a tool. DevOps is neither a service nor a philosophy. DevOps is not something that you can switch to in the morning and follow by evening. When implemented in an ineffective manner, it can do more damage than good. DevOps, when implemented in an environment that should has no use of it can cause havoc.

DevOps is

A combination of tools, applications, cultures, philosophies, practices. The end goal of DevOps is to unify software development and software operations teams. This is by removing the wall(s) between these two teams and by bringing in automation and monitoring at all stages of Software Development Life Cycle (SDLC).

DevOps is a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality.

Bass, Weber and Zhu

DevOps Tools

At each phase/level of software development lifecycle, a collection of tools is used. For Example, one company may use Eclipse IDE and Java for coding, GitHub for storing code in versioned form, Jenkins for running builds, Nuget for storing build artifacts etc, AppDynamics for application performance management, New Relic for performance monitoring, Docker for containerization, Puppet for SCM, Asana for project management. These applications are divided into different sets. These are called Toolchains.

DevOps Toolchains

Here is the list of tool-chains that are usually implemented in DevOps:

• Code — code development and review, source code management tools, code merging
• Build — continuous integration tools, build status
• Test — continuous testing tools that provide feedback on business risks
• Package — artifact repository, application pre-deployment staging
• Release — change management, release approvals, release automation
• Configure — infrastructure configuration and management, Infrastructure as Code tools
• Monitor — applications performance monitoring, end–user experience

How DevOps Team Works

DevOps work model requires ability to automate manual work, requires ability to manage complex environment at rapid pace to enable rapid and reliable deployment of software. You cannot implement DevOps effectively by building a wall between Dev and Ops teams. In companies that are using DevOps effectively, Dev team and Ops team work as a single team, share same workplace.

When DevOps team is working on project planning, Dev team gives clear understanding of how various environments should be (dev, build, test, regression, performance test). Ops team regularly takes inputs from Dev team to provide highly reliable, scalable, flexible environments to Dev teams. Ops engineers develop their own set(s) of tools using scripting languages and in some cases, traditional programming languages to automate creation/monitoring/management of these environment. As a result, Ops can make changes to environment at a speed that was not possible in traditional environment setup.

 It is “highly recommended” that all members of the team have good understanding of development and operations. Just because a person is under Ops team does not mean he/she should not bother about what development team is working on. Team members often acquire skills that are not limited to one area. One in Ops team can acquire development skills to effectively automate the process. One in Dev team can acquire skills that are required to setup an environment.

Jack of all trades and master of at least one is the kind of engineer that can fit well in new generation work culture.

I am going to stop here and in my next post, I will give a deep dive on some of these concepts. At the end of this series, you will have a clear understanding of this new craze.