DevOps Culture — Why it’s better than the traditional model
Previous posts on this topic:
DevOps culture is about collaboration between development and operations.
Under the traditional structure, dev and ops are separate entities with different and conflicting goals.
Development → Develop features and deliver to customer as quickly as possible.
Ops → Maintain stability of the system and minimize downtime.
To deliver and deploy a feature means to introduce a change to the system. And this change risks the stability of the system. Hence these goals are in opposition to each other.
In fact, many a times dev teams are evaluated by their speed of delivery of features while ops team are evaluated on the stability of the system. So these teams have great incentive to be in opposition to one another.
Note, speed and stability are both very important goals for a system.
With DevOps, Dev and Ops work together and the share the same goal of speed AND stability.
In a DevOps culture
- development and operations teams are on the same side of the game
- they have shared goals and usually also have shared measurements
These shared goals may be
- fast time-to-market (TTM): time taken from work done on development machine to work deployed to prod
- minimize prod failures
- immediate recovery from failures: failures WILL happen. The best case scenarios is a recovery before customers even notice, and there are devops tools which make this lofty goal a reality.
The above goals are equally important to both development and operations. Dev teams care about stability just much as they care about speed and ops teams care about speed just as much as they care about stability. In fact, sometimes the roles of the two teams may tend to overlap and blur.
DevOps culture says that dev and ops are much more powerful when they are together.
What is wrong with the traditional silo model?
- dev and ops teams are blackboxes to each other which leads to disowning responsibility and finger pointing in case of an issue. Ops: “The code doesn’t work”. Dev: “It works on my machine.”
- Long time to market because of absence of automation
- Lack of automation also causes inconsistent builds and deployments across people and platforms.
- It takes a longer time to identify and fix problem due to lack of transparency.
- Ops prioritize stability while developers want to ship code. So ops view devs as breaking stability while devs view ops as an obstacle to shipping.
What goes right in the devops model?
- dev and ops work together to develop a automated and robust way of shipping and deploying code quickly.
- this automation leads to consistency and reliability, and also a much lower cost of deploying.
- good rollback practices are part of devops so that in case of a failed deploy, the system should immediately recover.
