While DevOps provides organizations with an opportunity to transform and make their IT services more efficient, it remains to be seen how far DevOps will be successful in empowering digital transformation. Getting the right balance in development and operations will be critical in this process.
Software developers usually prefer fast and frequent deployments so that risk is minimized. Moreover, deploying software frequently and in small upgrades helps them in fixing bugs and releasing new features.
On the other hand, the IT operations teams that take care of management, monitoring, and operation of an application want stability to ensure smooth operational activity. Development teams are often at loggerheads when it comes to fixing system errors and they cannot replicate the tasks of IT systems and database specialists who keep systems online and serve the business. Needless to say, any hiccup or lack of coordination between the two teams often results in conflict and mismanagement of the product lifecycle process.
The next-generation software development methodology known as DevOps aims to bridge this gap between the developers and operations teams, while driving improved collaboration and transparency among them. DevOps is the amalgamation of the principles of development and operations and works toward structuring and refining the application development process. It identifies and verifies product ideas and then implements them. This results in removal of the bottlenecks and wasteful activities in the development cycle, making the process more agile and responsive to the end-user’s needs. This entire movement is driven by recent developments in the fields of cloud computing and virtual infrastructure.
The Benefits
An agile environment, such as one powered by DevOps, ensures that both the development and operations teams gain continuous feedback and collaborate closely with each other on all aspects of the development so that the application and the infrastructure are not treated as disparate entities. Broadly, agile software development aims at involvement from both the teams to ensure that the desired business functionality required by the end-users is met in time, with minimum bottlenecks. Alongside, the prized aspects of operations such as stability, scalability, and reliability are also satisfied.
In a DevOps environment, as the development and operations teams are both responsible for supporting the entire development process, their combined efforts benefit from enhanced expertise, skills, and background. Additionally, failures in code are reduced because errors are detected and corrected faster, and the production process becomes more efficient to empower the overall development process. In effect, the development team has the flexibility to be more creative and innovative in their work, delivering high-value solutions speedily and reducing the overall time to market for the product.
With teams answerable to each other for every aspect of the development process, the relationship results in improved collaboration and competition for continuous quality improvement to meet the customers’ expectations, rather than just focusing on technical errors. Another positive aspect is that DevOps ensures transparency in the development cycle; for example, with DevOps-ready applications, developers can view the software log files even after the code is released into production. As a result, the bugs get fixed faster, and there is a lesser probability of those errors being repeated in future releases, making development faster and more agile. An added advantage is that it gives developers an insight into the issues that occur in production, improving their knowledge in the way they design effective solutions.
How Does DevOps Work?
DevOps is basically concerned with the proactive participation of its various stakeholders, along with the automated operations of processes such as testing, integrated configuration management, integrated change management, continuous integration, and application monitoring. There are various DevOps software tools available in the market that can automate the whole process.
Typical DevOps software converts infrastructure into code, automates how to effectively manage the IT infrastructure, and ensures better testability of the infrastructure and makes it more flexible and repeatable. The software relies on instructions and automates infrastructure tasks such as configuring web servers and databases. Depending on the end product required, one can customize DevOps software by bringing both development and operational capabilities together to enable faster delivery of functionality.
Is It All Good?
A fundamental requirement for proper DevOps implementation requires the operations (Ops) team to continuously engage with the development team throughout the entire lifecycle of solution development.
The Ops team should take more responsibility in the software development lifecycle, getting involved in every stage and providing necessary inputs to the development team to enable them to build and validate the product in accordance with the required specifications. Ops should participate right from the planning stage so they are able to comprehend the business vision, the timeframe, and the product development cycle. Ops should also contribute to determine the solution's technical and schedule feasibility.
Adopting a DevOps-friendly environment can be difficult for many companies due to the fact that proper DevOps implementation depends not just on software tools, but also on organizational changes and seamless coordination between two diverse teams.
Software development teams are often focused on creating innovative product lines and services and working on new releases of a solution that already exists in production. A probable disadvantage arises when the development teams spend more time ensuring a proper DevOps-ready environment. In addition to working on the new product development, they will have to address serious production issues that are escalated to them. Working on behalf of the operations teams to fix production emergencies will distract the developers from working on new functionalities, in turn hampering the innovation process. This might also result in the risk of losing the knowledge and expertise of the development team that is required to maintain and evolve the solution over time.
How to Make It Work
Enterprises can maintain a sustainment team that comprises two or three developers so that when the solution is up for testing by operations, the developers of the sustainment team can take the responsibility of running, fixing errors, and supporting the production process. This way, a core team of developers can concentrate on creating innovative services and products while leaving the troubleshooting issues to the sustainment team.
In case of severe defects when the sustainment team of two or three developers fails, an effort to ensure DevOps success is to maintain a testing period. During this testing period, the whole development team works on fixing critical defects for a predetermined period, such as a month, after the software gets released to production. Testing periods can also be implemented in outsourcing situations where the stakeholders typically want to ensure that they are receiving a considerate level of quality.
A befitting DevOps strategy lies in following agile developer-led operations. The production support strategy by development is definitely a step ahead in the right direction.
User Comments
I like the sustainment team idea. It is best if team members rotate through that team/role.
Also, a general commnent on devops automation: We should not conclude that automation = "more reliable and more repeatable". That is only the case if the automation tools/code are themselves reliable. It is regrettably the case today that many of the automation tools are flaky and incomplete. Even worse, automation code/scripts tend to be very fragile and have very poor software engineering characteristics (low cohesion, high coupling), resulting in a maintenance challenge. E.g., one change in one place might require you to make many changes in other places. That is a prescription for problems. My advice: keep it simple; don't create complex deployment scripts. Keep them flat and document the scripts well.