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.
The resulting architectural discussions may lead to decisions to change the languages and frameworks the organization uses to be more in line with industry best practices. An organization may currently use languages as diverse as C, Java, or JavaScript and frameworks such as .NET, Rails, and AngularJS. The idea that an organization should change from a particular language, such as one of those named above or any of the myriad of others that may be currently in use, to find DevOps success is a slippery slope and is not necessary to implement the DevOps principle of increased deployment frequency. Any language will work well with the right principles and practices in place.
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.
We can argue that there are languages that are more conducive to certain aspects of a DevOps initiative within an organization. Chef, a common automation tool used by many to deploy and configure servers, uses Ruby as its scripting language of choice; these are considered optimal for DevOps. AngularJS, a front-end JavaScript framework, and Go, a server-side technology, both created and maintained by Google, follow a deeply rooted test-driven development (TDD) principle. TDD helps in the DevOps process by allowing engineers and operations professionals to quickly run tests and to know whether a product is ready for further testing or deployment.
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."]
