Efficiency is doing the thing right. Effectiveness is doing the right thing. – PETER DRUCKER
It seems there is a new buzzword coined every week in the IT industry.
It may be fun asking average people on the street “What is DevOps” – “US Military operation?!” or “Some spy movie?” or “a Robot?”
However, when the term “DevOps” was introduced to IT people, they said, “we have been doing this for years – code merging, configuration management, release management, deployment using automated tools.”
What’s new in it? Is it a marketing gimmick of sorts? Is it a sledgehammer to kill a fly? Let’s park these questions for now. In this post we’re comparing DevOps methodology versus traditional Software Development Lifecycle (SDLC).
What to Explore
Traditional Software Development Life Cycle Challenges
Requirements to Production deployment of any business need or story (in Extreme programming) is an interesting journey with a lot of human intervention at different milestones.
Predicting where things may go wrong even when risks are identified and mitigated is challenging for any software project. The basic thinking is to code; once ready after system and integration testing is released to the Operations team for install.
Things can be fine and dandy if there is utmost synchronization between the Development team and Operations team but more often there are challenges:
- The operations team deploys it but with a possibility that whatever was working in Development, environment does not work in a Production environment. The response from the development team usually is, “It works just fine in development…” The reason for the failure is that these two environments are different or are not periodically synchronized.
- New development tools make coding faster but sometimes the operations team is not able to cope with frequent changes and releases.
- Production servers may need some tweaking or fine-tuning at the database or OS level. If there is a lack of skill or expertise then the deployment is at a risk.
- Developers usually do not have access to Production servers to check how the application is behaving so there is a need of feedback from end-users, which, is not often received by the Developers for obvious reasons.
In some instances, there are no clear instructions/details of the deployment. Ops team has to figure out some things based on their experience/skill – poor transition.
With traditional SDLC approaches, companies may regret the complexity to bridge the gap between Developers and the Operations team; production systems are at stake no matter what.
Such challenges have a greater impact on the cost, schedule, and reputation of the organization.
To help illustrate these complexities, Lori MacVittie talks about the butterfly effect to demonstrate effects of not addressing challenges in terms of time, money, and risk.
DevOps Provides a Solution to Traditional software development
These challenges seemed like they would continue to remain part of the development lifecycle until Patrick Debios decided to take these up.
This initiative formed the basis of DevOps – a term coined by combining Dev(elopers) and Op(erations)s.
is a philosophy to bring in cultural change aiming to deliver functionalities faster at a higher rate of quality. It is a way to bridge the gap between Developers and the Operations team for frequent deployments. It could be called “Near Real-Time” development or “Elastic” deployment cycle because you can automatically deploy as soon as a change is committed by the developers. Human intervention is minimized wherever possible. Automation throughout the development life cycle, continuous feedback, and process improvement is the key for adopting DevOps.
The following are some of the DevOps principles:
- Create production-like systems for development and testing environment
- Deployments need to iterative and frequent. Ensure a reliable and repeatable process
- Continuously monitor and validate operational quality characteristics
- Amplify feedback loop
Automation tools are helping companies adopt DevOps. These tools include Jenkins, GitHub, Chef, Puppet, SaltStack, New Relic, Nagios, Ganglia, Munin, Splunk, Rundeck, to name a few.
Coming back to our parked questions: DevOps – What’s new in it? Is it a marketing gimmick? Is it a sledgehammer to kill a fly?
Typically we have planned releases that are deployed through a toolset – some may be automated but you need to enter commands to invoke it. A tool by itself would not mean anything but the utilization of it and Integration of all automated tools right from check-in to deployment is offered by DevOps.
Frequent or continuous deployments (e.g. 10 per day) need discipline at all levels and commitment to make it happen. You may also be having war room meetings between developers and the operations team prior to deployment. What if the development and operations teams are geographically dispersed (i.e. thousands of miles away and there is the challenge of time difference to conduct phone meetings). The operations team's agenda is to keep the system down to a minimum time and in this process, some critical errors are not resolved in a timely manner or are ignored. DevOps once in place can take all these factors out and make the deployment journey as smooth as silk.
Using individual automated tools in a sporadic manner is trying to bring in efficiency (i.e. you are doing things right but DevOps brings in effectiveness ensuring you are doing the right things and cannot be sniffed at). Before you jump on the DevOps bandwagon there is a lot of thinking, planning, and work that goes into it. There are challenges right out of the gates – from choosing the right tool to change management, but the payoff, in the long run, may enable you to scale to heights.