Depending on when, how, and from whom you’ve heard of DevOps, its origin and meaning as well as the reasons for its implementation are going to be different. The reason is fairly straightforward: unlike Agile, which was born in February of 2001 when the signatories got together and drafted and signed into existence the Agile Manifesto, DevOps—like most new concepts—has no hard and fast birthdate. As a result, what it is and how you do it have largely been left up to the many, many individuals trying to make it work.
There is, however, one central point: There was, is, or has been a problem within corporate information technology departments between Development and Operations and, as a result, something is happening to address that problem. That thing is called “DevOps”.
This DevOps (r)evolution became manifest in March of 2011 when Gartner published a slide that had a simple predictive statement in it:
“By 2015, DevOps will evolve from a niche strategy employed by large cloud providers into a mainstream strategy employed by 20% of Global 2000 organizations.” (The Rise of a New IT Operations Support Model, Gartner, 2011)
We’re still in the beginning of 2016 as I write this, but I’d say the prediction has come true for the most part.
So let’s talk about what DevOps is, at least from my perspective.
What is DevOps?
First, I agree with Gartner: DevOps is a “strategy”. It isn’t a separate department that lives between Development and Operations and acts like some kind of interpretive interface. Where we may have a difference of opinion, however, is in DevOps’ scope.
DevOps isn’t just an IT operations support model. It’s a culture, a movement, a practice, and a concept that emphasizes collaboration and communication and encourages us to look at the business activities we perform differently. Specifically, DevOps requires us to not only take a critical eye to our own behavior and adapt to the reality that we see as a result, but also to change the tools we use to increase the speed of change and provide better information earlier so that business decisions happen when the opportunity arises—not years, months, weeks, or even days later. DevOps is not limited to IT; it is part of an overarching enterprise Agile Transformation.
The principles of Agile, which first focused on software development specifically and then evolved into systems development practices and principles, have expanded further to incorporate R&D and manufacturing. While Agile and Lean thinking and principles ultimately gave rise to DevOps (as well as Continuous Delivery, which overlaps with but is different from DevOps), DevOps extends beyond just software development. Where Agile seeks to remove the friction between end-users and developers, DevOps focuses on the removal of the causes of friction in general. While Agile strongly advocates a preference for personal interactions over processes and tools, it does not obviate the necessity of these processes and tools. An effective DevOps implementation is entirely dependent on the selection of tools, practices, and ideas that enrich Agility. While this may appear to be a point of contention, or even a collision, in reality DevOps values personal interaction so much that tools are used to enrich these interactions. If and when that doesn’t work out, DevOps principles advocate removing the tool or process in favor of others. Having a DevOps mindset means ruthlessly identifying what the source of any friction is and doing whatever is necessary to remove it. If your personal interactions are impeded because your teams are distributed—as are most teams in the world—DevOps encourages you to find whatever tool will remove that friction (e.g., bring the team together and/or use tools and practices that improve communication).
DevOps is About Tooling for Business Success
DevOps is about tooling for business success, and that’s why there are so many articles about the plethora of tools that will address business needs all along the delivery chain. Wikipedia gives a list of general tool categories (to wit: Code, Build, Test, Package, Release, Configure, Monitor) and New Relic even has a glossary of “Tools for DevOps”. Though this “periodic table of DevOps tools” by Xebia Labs really takes the cake, at least design wise.
Keep in mind: it’s not tools for tools’ sake, but tools for the business’ sake. So I want to share the only thing you really need to know about DevOps and tooling (whether you’re in IT or not), and it’s actually pretty simple:
- Your operational success is directly related to how well you define your business goals and choose the tools that will let you achieve those goals. Specifically, your business goals should guide you as to which tool to use, and not vice versa.
- Abstract the platform/infrastructure to implement based on the service or product you want to deploy. You should be able to change out platform size/components as needed to scale up or down without additional development. As Uncle Bob Martin put it, “Make sure the business rules don’t depend on the database.”
- Use dashboards in your business logic to dynamically track and, as needed, adjust performance and capacity. Your key performance indicators should indicate how well your platform/infrastructure is delivering against your business goals. For example, if your performance is shown to run high frequently/constantly, you may want to consider scaling up, but if you never exceed 20% of your max capacity, then you are paying too much for capacity you don’t need, so scaling down would make sense. (This is a common problem: Lots of companies implement the very expensive, overkill Oracle when the more cost-effective SQL will do just fine. This is akin to buying a Maserati only to drive it like a VW Beetle.) You can also set alarms that draw attention to ineffective or inefficient use of resources and even recommend improvements.
- When in doubt, err on the side of giving end users more, not less, administrative control. Design administrative functions into the application or service to limit unnecessary super administrator intervention in. A simple rule to live by: if you have to restart the app to implement changes, then the associated admin rights should be assigned to the super-admin. If an app restart isn’t necessary, then put the admin power in the user’s hands so they can make as many customizations as possible as quickly as possible.
- If you let your business needs and logic guide you as you build the platform/infrastructure, you should be able to quickly and flexibly release the services, products and/or applications that your operational users need.
- If you ensure 1a) above, then your platforms should be consistent in behavior, elastic in scale, and available on demand.
- If you ensure 1b) above, then operational capacity and/or performance will be visible and can dynamically alert you to when you need to make changes to improve performance and/or decrease unnecessary expense.
- If you ensure 1c) above, procurement and provisioning plans will be designed to provide what is needed when it’s needed, minimizing platform warehousing or backlogs.
If you put the two fundamental ideas together, you end up with a simple guiding statement:
What you put in (1) is what you get out (2).
If you’re attempting an enterprise-wide Agile Transformation but you’re only working on the development side of the equation, you’re probably experiencing a lot of problems. A DevOps approach to your Agile transformation engages everyone in achieving your objectives at the same time, but more importantly it addresses one of the primary drivers of an Agile transformation: the realization of value. In Agile development, the delivery team ends each iteration or sprint with a demo. This engages the users early and often and allows for quick adjustments. However, the realization of business value only occurs once what was demonstrated is available to be used. DevOps closes the gap between demo and reality such that at the end of each iteration or sprint, the “demo” is released to production and in the target end user’s hands.