Irrespective of what your IT strategy is, it can be safely guessed that every IT strategy aims at timely delivery of quality software, fixing issues quickly, improving user experience and optimal utilization of resources. Traditional models of software development have, to varying extents, failed to achieve these goals. Companies have struggled to find a balance between timely delivery of quality software and optimal utilization of resources. Now, the availability of software in the cloud means that users are able to access software through standard browsers. As a result, feedback and issues are flooding in, putting software companies under immense pressure to deliver fixes quickly. A major reason for such problems is disconnect between the development, QA and operations teams. The DevOps concept has been helping companies manage these problems through greater collaboration between teams and proactive management of issues. DevOps principles are being incorporated in the software development models of many companies.

What Is DevOps?

DevOps is a recent culture of software development that has been redefining how companies should develop and manage software in a changed business scenario. Now, many software applications are hosted in the cloud and made available to users through browsers. The users are also given avenues to publish their feedback or issues. As a result, companies receive a lot of feedback quickly. This situation is different from that in the traditional software development, when bugs or issues were reported through some specified channels and took a certain amount of time to reach the concerned team. Frequent reporting of bugs and issues puts immense pressure on the company to fix problems quickly. In traditional software development models, the development, QA and operations teams are disconnected from one another, which results in delayed response to issues. In a competitive environment, that could be a critical factor.

The term DevOps has been created by combining the words "development" and "operations" and the main idea is synergy between the developers and the operations team. In the DevOps culture, working in silos is not accepted. Developers, QAs and operations staff are encouraged to think of the total software deliverable and what they can do to release a quality piece of software. For example, the developer is encouraged to think of the possible scenarios after the code has been checked, such as code breaking scenarios, whether the use cases are real-life or hypothetical user experience issues. To get the answers to these questions, the developer needs to reach out to the QA and the operations teams. The teams also need to proactively plan for possible issues and their management.

To summarize, the main idea behind DevOps is to increase collaboration between the development and operations team, foresee and prevent issues, stop thinking in silos and think about contributing to the software quality overall. (To learn more about DevOps, see DevOps 101.)

DevOps Principles

The main three principles that drive the DevOps culture in various companies are described below.

Holistic Approach to Problem Solving

A holistic approach to problem solving means developers or the QAs need to view problems outside coding or test cases, if required. If a developer or a QA is required to solve a problem, the default approach should not necessarily be in their specialization. They need to explore other options too. For example, some problems can be solved by providing training. The idea is to find the best solutions and not ones that need coding.

No Silos

Silos occur when there is a paucity of effective communication, feedback sharing and review mechanisms. To break down silos, code needs to be reviewed by peers, knowledge needs to be shared so that the unavailability of any single employee does not become a showstopper, work needs to be documented and everyone must be enabled to deploy software.

Rapid and Continuous Feedback

Companies should want their internal employees to identify defects in the software before their customers do. To do this, the software should be frequently deployed and reviewed by employees from different teams and the feedback should be continuously incorporated. This makes things easier than when a pile of issues or bugs stack up and a crisis is triggered.

Case Study on DevOps

Amazon transformed itself from an online retailer to a pioneer in the cloud space with the release of Amazon Web Services (AWS), an on-demand IaaS that is now widely used. However, when Amazon stepped into the cloud services domain, the company did not know much about the topic. There were a lot of risks. So how did Amazon create such a huge success? (For more on AWS, see What Do Amazon Web Services Bring To The Cloud?)

The strategy of how Amazon became successful was supposed to be a secret, but one of its former employees, Steve Yegge, leaked an internal memo which provides important details of what Jeff Bezos wanted the employees to do to make AWS a success.

  • All teams must expose data, features and functionalities through web service interfaces.
  • Teams must communicate with one another through these web service interfaces. No other form of communication was allowed such as linking or sharing.
  • Teams are allowed to use any technology to use the web service interfaces – HTTP, CORBA, Pubsub, custom protocols – it doesn't matter which.
  • All web service interfaces must be designed so that the interfaces can be exposed to the outside world.

To summarize, engineers at Amazon were required to build web services through which they could share data, and that would be the only means of sharing data. Any team that needed some data from another team needed to find suitable web services through which they would place the request. If no suitable web service was found, they could escalate the matter. Teams building a web service also needed to secure the web services so that they could not be accessed without verification of user credentials.

So, where does DevOps come into this picture? As part of the AWS initiative, a huge number of web services were created, used and tested which involved a huge number of employees. Naturally, the entire gamut of activities resulted in the creation of a huge number of test cases, issues, bugs and use cases. Clearly, almost all teams got involved and played their roles – developers developed web services, different roles accessed the interfaces and reported issues, if any. Developers had to continuously collaborate with operations, QA and other roles to make sure that the web services reached the minimum level of quality.

Conclusion

For all the benefits DevOps brings, it is not easy to implement it across an organization. Since it is about culture, breaking the barriers and fostering a culture of fluid communication can take a lot of time. The change has to come from the top. Implementing the new system can face resistance in various forms. There is no single way of implementing DevOps across organizations given the unique nature of different work environments. Organizations should research which methods would work best for their circumstances.