By Mike Johnson, Performance Business Leader
Organizations looking to boost quality and productivity and take advantage of the latest tools in software development are increasingly looking to DevOps as a way of transforming their software development. Led by high volume software as a service (SaaS), media and e-commerce properties like Netflix, Facebook and Amazon, roughly 30% of all software companies have either fully embraced DevOps or have integrated it into a majority of their development teams. Most companies are adopting more cautiously, however, with more than a third of organizations either just beginning the DevOps journey or contemplating first steps in the near future. Change can be difficult, and organizations that have just adopted Agile or are still following traditional software paradigms may feel they are not ready for another process and technology transformation. Most organizations succeed at migrating to DevOps by making gradual, but meaningful changes in their existing development methods. Each of the major practices of DevOps can be adopted on its own, or as a milestone in the journey to becoming a DevOps organization.
One transformation that all organizations can make right away is to begin thinking in terms of services. Since the 70s, software engineering has been defined by features, with a heavy emphasis on how individual user requirements fit into an integrated whole, and without much thought about reuse, rework, maintenance or future compatibility. Waterfall and spiral development methodologies institutionalized this approach, giving rise to feature-rich applications and systems, but with a high cost of maintainability over the long term. Agile’s emphasis on short, well defined releases reduced feature development time, but didn’t fundamentally change the paradigm. DevOps goes further, encouraging teams to treat systems as a collection of independent, well-defined and loosely-coupled services, which can be used not only in the current release but across the organization. Because each DevOps team often maintains its service even in the fielded system, cost is significantly reduced, and quality significantly improved. Even without major architectural overhauls, teams can begin adopting a service approach without difficulty. Virtualization and containerization services like Docker make it easy to deploy DevOps services using traditional development languages and tools.
With some careful thought and tailoring, most organizations can easily adopt DevOps continuous delivery paradigm. Agile teams are already accustomed to delivering software in short sprints, and even formal process teams often have ‘nightly build’ or ‘integration test’ instances of their products. In many cases, developers and teams are already working asynchronously on individual features or components, and almost all organizations have some kind of process for patches and maintenance upgrades. Continuous delivery, in which individual features are delivered ‘just-in-time’ is the next logical step in this progression. Continuous delivery does require discipline to maintain overall system health and quality. A high degree of automated regression testing, as well as an automated deployment process, can aid in its adoption.
Whether or not continuous delivery makes sense for an organization, all teams should be taking advantage of the productivity and quality gains afforded by virtualization and automated testing. Virtualization gives developers a consistent, stable configuration that mirrors the production environment, minimizing the impact of platform and configuration issues at delivery. Systems developed virtually can also be tested at scale by using many virtual machine instances that duplicate configurations, patch levels, user environments and system loads. The scalability afforded by a virtual test platform may also allow full unit and regression testing of a feature prior to its release into the development or production environment. When a feature ‘checks out,’ it is even possible to deploy it to the live system using fully automated processes.
The DevOps process works best with some organizational changes; these can be the most difficult, and the most rewarding milestones in the DevOps journey. Most DevOps services are supported by the same team from design and development to operation and maintenance in the production environment. Some organizations, such as Amazon, enforce a ‘two pizza team’ rule, in which every feature team is small enough to be fed by two pizzas! This approach differs from a traditional organization that maintains architects, engineers, IT and field service personnel in separate stovepipes. Some cross-training may be required to ensure that team members fully understand the intricacies at each stage of a system’s lifecycle. Nonetheless, developing a full set of design, development, quality and maintenance skills across all roles in an organization leads to more efficient development practices and higher quality code in the long run.
Many in the software industry are inclined to think of DevOps as the next step ‘beyond agile,’ and a recent McKinsey report highlights some of the reasons why. For organizations concerned with speed to market and user responsiveness, DevOps enables reduced cycle times compared with Agile, cutting software delivery time in half in many cases. But mere numbers don’t tell the whole story. That’s because while most of Agile’s advantages have been seen inside of an organization’s engineering and production teams, DevOps can provide transformation to the wider organization, including IT, customer support and even sales and marketing.
To learn more about how Amazon made the journey from older software paradigms to DevOps, check out this video.
