DevOps Does Not Necessitate a Change in Language
DevOps is more than a set of tools and scripts used to make software operations easier within a software engineering group. DevOps is also a set of principles based on the belief that when an organization improves its deployment frequency, it will find success with a faster time to market, a lower failure rate on new releases, a shorter time between reporting bugs and deploying fixes in production, and a heightened ability to respond to production operations issues. Increased deployment frequency leads to increased profitability due to these successes. As we explore in a recent Executive Update, when an organization begins an internal DevOps initiative, it will find that it needs architectural changes for its desires to come to fruition.
Organizations do need to simplify architecture by moving away from monolithic systems to a more service-oriented architecture (SOA). An organization has a monolithic architecture when different functional areas of their software, such as Web interfaces, data storage, data processing, and error handling and logging, are not separate components. From a DevOps perspective, these monolithic components must be deployed together in an interdependent way, breaking the principle of increased deployment frequency. While not a simple process, moving to an SOA will pay dividends by allowing an organization to deploy independent components separately and quickly.
Organizations commonly take a large amount of time at the beginning of a software development project to architect the entire solution, making system design and software engineering decisions before the first new feature has been written. This methodology is referred to as "big design up front" (BDUF) and is not in line with Agile or DevOps principles. Ultimately, all architectural and development decisions should be guided by the simple principles of Agile, leaving no room for BDUF, which can suffocate even the most enthusiastic DevOps initiatives under the pressures of having to answer questions about the future needs of a software system with only imperfect levels of information.
An organization may understand the need for DevOps principles in order to move itself forward quickly in the market or with higher quality. But as the organization begins the process of planning its DevOps initiative, the organization may look back on its previous architectural choices and think that those choices have led it down a path that makes DevOps too hard to implement. I am reminded of a friend who I have consulted for a number of times in the past. He had just become the CTO for a company struggling with its technical operations. We talked at length about possibilities that would quickly get this company's operations back on track.
"But Tim," my friend finally stopped me, "we're in a .NET environment." This struck me hard. This organization had the skills, the time and budget, and, most importantly, the desire to make great changes. Yet it felt that a decision it made nearly a decade earlier in both language and framework, using Microsoft's .NET framework, had stopped it from being able to really progress toward success with DevOps. After working with this organization for a short period of time, we saw an increase in deployment frequency from annually to weekly, all while still using the .NET framework. There was no language or framework change necessary.
However, experience has shown that every language and framework has the tools necessary to implement DevOps within an organization. DevOps will cause architectural change within a development environment. But the language in which the development happens should not be the first concern when trying to move the needle on a DevOps initiative. In fact, completely changing a language, and therefore not using the organization's knowledge around its current language and having to retrain or rehire engineers, is counterproductive and will lead to frustration and a lack of success. An organization may use .NET, Java, C, or any other language and still be ready to implement faster, higher-quality, and more automated software operations.
[For more from the author on this topic, see "DevOps Principles Lead to Architectural Changes."]
More: Articles Like This
- Mitigating Business Risk: Unlock Software Potential
- Using Contextual Software Analysis to Mitigate Business Risk
- Discovering the Right Questions in Big Data: The Colored de Bruijn Graph Approach
- Case Study: Linking Business Workflows and Agile User Stories in an SOA
- How Does Culture Drive Organizational Agility Success?