DevOps is a term used to refer to a set of practices that emphasize the collaboration and communication of both software developers and IT professionals while automating the process of software delivery and infrastructure changes.
You might read this definition everywhere and every time whenever you search for DevOps, but actually it is much more than just communication between development team and operation team. To understand DevOps, we have to travel back in time where ancient software development was started. Where Tao was born, and there was no one but only programmers.
At that time, programmers were like the president of applications. In order to create a good application, they had to fully understand requirement and problems they need to solve. They have to prepare maintainable and deliverable code. There were no rules and no type of assignments at that time, only one profile existed, “PROGRAMMER”. But then, the evolution of software development started. As Tao teaches us,
The Tao gave birth to machine language. Machine language gave birth to the assembler.
The assembler gave birth to the compiler. Now there are ten thousand languages.
Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.
Evolution brings so many greedy things with it, It asked for more features, more speed, more users, more business, more everything else. Being modest and humble, it is very hard to survive where a client is asking for more and more in half amount of time. But this was war, IT had to survive, so more and more people join. Programmers became developers and engineers, Developers parted as front-end developer and back-end developer. Engineers became a network engineer, Architect, Operation engineer and so on. And soon they all forget they came from the same father, “PROGRAMMER”.
As time passes they reduce their interaction with each other, they hardly spoke to each other. They started forgetting their purpose of existence, “To solve client problems.”, Instead of this client started feeling the pain to work with the organization because they lose harmony between all teams. It has to be resolved.
There comes waterfall, it was a brilliant idea. Waterfall encourage a group of developers/operators to communicate when they had to. It was hope for software development, life was easy now. Let’s see complete software step by step and complete it at once.
But waterfall model missed one very important thing, “Frequent Changes”. Also in waterfall risk of failure is bigger and higher. 60% of software were failing(zdnet, cnet), it was like there is nothing to be done about it.
It does not allow a client to change anything after the requirement is finalized. So Agile development came in. Agile manifesto is based on following principals.
- Customer satisfaction by early and continues delivery of valuable software
- Adapt changes in requirements
- Software is delivered frequently (weeks other than months)
- Daily co-operations between business people and developers
- Face to face conversation
- Sustainable development able to maintain a constant pace
- Continues attention to technical excellence and good design
- Simplicity — the art of maximizing the amount of work is not done is essential
- Self-organizing team
- Regular adoption of changing circumstances
Agile manifesto was the first big step in bringing peace to the Galaxy and restoring balance to the Force. For the first time in a very long time, connecting all stakeholders in software development process was based on the cultural and “human” way, as much as on procedural and mechanized manner. People started to talk to each other, meet on a regular basis, and exchange ideas and comments all the time. They realized that they have much more in common that they thought even clients can become part of the tea.
There were still a few hurdles to overcome, but the future seemed brighter than ever. Being agile means being open and willing to adapt to constant changes. However, with all too many changes, it is difficult to stay focused on the ultimate goal and delivery. And that is how Lean Software Development came to life.
The principal of LEAN is,
- Eliminate waste
- Build Quality in
- Create knowledge (Amplify learning)
- Defer commitment (Decide as late as possible)
- Deliver as fast as possible
- Empower the team (Respect people)
- Optimize the whole
Added on top of Agile, Lean principles supported the mentality and the focus on doing the right things, while being flexible during the whole process. Once Agile and Lean were adopted by software development teams, it took just one more step to apply the whole set of principles to IT as a Whole – which finally brought us to DevOps!
Here comes DevOps — Three-phase model
Optimizing software development process, including agile and lean principles, was mostly focused on these. The old age software development process includes teams like front developers, backend developers, business analyst, product owner, testers and so on. Once an application is production-ready it was sent over to operation team including network engineers, release engineers, DBA Architect and etc. Removing the great wall between Dev and Ops is a main driving force of DevOps.
DevOps is a culture, mindset, and it is part of IT as the Whole. There are no tools that will make your IT a DevOps organization, and no level of automation will empower your teams to deliver maximum value to your clients.
DevOps is usually referred as method in three phase,
- Phase One: Performance of the system as whole is main focal point and it is emphasized over performance of any individual element of the system
- Phase two: Make sure that there is a constant feedback loop sent upstream, and not ignored
- Phase three: Nurture experiments, constant improvement, and fail fast
Phase One — Getting up for performance
Understanding the importance of the whole system, and prioritizing work items properly is the first thing an IT organization has to learn when adopting DevOps principles. No one in the IT value stream is allowed to create a bottleneck and reduce the flow of work.
DevOps principles do not care what team you belong to if you are a System Architect, DBA, QA, or network administrator. The same rules apply to everyone, and everyone is expected to follow two simple principles:
- Keep the system flow uninterrupted
- Increase and optimize workflow at all times
Phase Two — Gear up
Uninterrupted system flow is one-directional, and it is expected to go from development to operations. In an ideal world, this means that software is created quickly with high quality, deployed to production, and delivering value to clients.
- feedback loop
- Include development team in support team meeting or include network engineer in development team sprint planning
Phase Three — Speed up
DevOps Phase three is all about taking risks and learning from failure, continually experimenting, and accepting that repetition and practice is the prerequisite to mastery. Continuous training and repetition lead to mastery because it makes complex moves become a routine.
DevOps Third Way/Fast Lane include allocating time for continuous experimenting on a daily basis, constantly rewarding the team for taking risks and introducing faults into the system to increase resilience.
In order to assure that your organization will not implode when implementing these kinds of measures, you must create frequent feedback loops between all teams, while making sure that all bottlenecks are clear and system flow is uninterrupted.
- There is no wall between development team and operations team. Both are part of the same process
- Work that is sent over from one team to another is always verified and top quality
- There is no “piling” of work, and all bottlenecks are handled
- Development team is not using Operations time for its activities because deployment and maintenance are part of the same time box
- Development team does not deliver the code for deployment at 5 PM on Fridays, leaving operations to clean up their work over the weekend
- Development environments are standardized, and operations can easily reproduce and scale them into production
- Development team can deliver new versions as they find appropriate and operations can easily deploy them into production
- There are clear communication lines between all teams
- All team members have time to experiment and work on improvement of the system
- Defects are introduced (or simulated) and handled in the system on a regular basis. Lessons learned from each experiment are documented and shared with all relevant people. Incident handling is a routine and mostly handled in a known way
Using modern DevOps Tools like Chef, Docker, Ansible, Packer, Troposphere, Consul, Jenkins, SonarQube, AWS, etc. does not mean that you are applying DevOps principles. DevOps is a way of thinking. We are all part of the same process, we share the same time and deliver value together. Every person that takes part in the software delivery process can speed up or slow down the entire system. A bug created during development can bring down the system, as well as the wrong firewall configuration.
All of the people are part of DevOps, and once your organization understands that, tools and technology stack that will help you manage it will magically show up.
Why do DevOps?
DevOps Benefits The competitive advantage this capability creates is...