DevOps in 5 Minutes
This article introduces you to DevOps, explains the traditional software development model, its pitfalls, and benefits from adopting DevOps culture and practices.
Now, let’s see how Industry described DevOps:
Wikipedia
DevOps is a set of practices that combines software development (Dev) and IT operations (Ops). It aims to shorten the systems development life cycle and provide continuous delivery with high software quality. DevOps is complementary with Agile software development.
Wikipedia describes DevOps practices' benefits in quick delivery with high-quality results. Besides, DevOps complements rather than substitutes for agile development, and they work together.
aws.amazon.com
DevOps is the combination of cultural philosophies, practices, and tools that increases an organization’s ability to deliver applications and services at high velocity: evolving and improving products at a faster pace than organizations using traditional software development and infrastructure management processes.
Amazon defines DevOps as a culture, practices, and tools that help faster delivery than traditional development methodologies like a waterfall.
cloud.google.com
The organizational and cultural movement that aims to increase software delivery velocity, improve service reliability, and build shared ownership among software stakeholders. — cloud.google.com
Google explains DevOps is a cultural shift that enhances the delivery velocity and fosters shared ownership among stakeholders such as developers, QA teams, and operations.
What is DevOps?
DevOps is a methodology for developing and operating software applications that encompass a cultural change, a set of construct and delivery processes, a collection of methods and tools, and enhanced collaboration among cross-functional teams. In a nutshell, DevOps is a culture, people, a set of practices, processes, and tools.
Traditional Software Development.
Traditionally the development team would implement the application following the business requirements and then hand it over to the operations (Ops) team. Ops teams are responsible for deploying and administering these applications in production systems. Additionally, these applications are monitored via conventional methods. For example
- Using Linux commands to monitor the process health
- Investigating the production issues by analyzing log files manually.
Waterfall methodology
Traditional software development practiced Waterfall methodology. Multiple isolated steps are proposed for software development according to this methodology. These phases progress sequentially, that is, one after the other. This approach primarily entails a massive amount of manual work, which results in considerable time spent. Manual tasks that are prone to errors lead to application downtime and sluggishness.
Clash of Priorities
The development teams prioritized rapid development over long-term stability(speed over stability). Their primary focus is on enhancing the application’s capabilities and functionality rather than on its stability. Ops Teams, on the other hand, valued stability over speed. They concentrated on the applications’ stability and reliability. Thus, they are resistant to change, whether it is a new capability or enhancement until they are convinced of its stability.
This reason for different priorities is that development teams have no idea of Ops teams’ challenges and operational problems. There is no visibility of changes and new capabilities for the next release for the operational teams. Additionally, they are unaware of the pressures placed on the developing teams to meet release and time-to-market deadlines. There are always differing preferences between these teams, result in conflicts.
Adhering to conventional development methodologies such as the waterfall model, lack of automation, and conflicting interests leads to delayed application releases, unstable applications, low customer engagement, unsatisfied clients, and reduced client acquisition rate. Customers prefer a modern, reliable and stable application.
As a result, a “culture of blame” will be created in the organization. Development teams criticize the Operations team while the Operations team also faults the development teams. As a result, business partners start to lose confidence in their information technology (IT) teams.
DevOps Culture
One of the key mantras of DevOps is “You built it. You run it.” DevOps encourages a culture of collaboration and shared responsibility.
Culture of collaboration — Development teams and Operational teams work together from inception until the end instead of a formal handoff from development to operation before the deployment.
Shared responsibility removes the fear of failure and the culture of blaming. Innovation does not occur when failure is not an option. DevOps encourages us to embrace failure and learn from mistakes and keep improving.
Feedback is another fundamental cultural change brought by DevOps. Development teams get their input in the fastest manner possible: production issues, code quality, or broken functionality.
Embedded Quality — Bringing quality into the development process makes the application continuously tested for functionality, quality, and operational concerns like security, performance. This method smoothens the process of deploying the application into production.
Autonomous teams — Another vital facet of DevOps is the use of autonomous teams. An autonomous team will use tools that automate processes, such as continuous integration. The push of new code triggers the development and deployment of a new feature in a test environment, and the issue tracking software is automatically updated.
DevOps Practices
A successful DevOps implementation embraces the concept of continuous improvement and automation. A vast majority of practices concentrate on one or more development phases. These practices are shown in the diagram.
