DevOps by any other name still gets things done

My version of “A rose by any other name would smell as sweet” is not nearly as eloquent as Shakespeare’s, but the sentiment is the same. Juliet argues in Romeo and Juliet that the name of a thing such as a rose is irrelevant—it’s still a rose no matter what you call it. The same thing is true when it comes to DevOps.

The term DevOps has achieved industry buzzword status. Most people—at least most people in IT—are familiar with the term even if they don’t have any idea what DevOps is. Even among those who think they know what DevOps is, there may not be consensus on how to define or implement the concept. It is understandable that some people don’t have a clue what DevOps really is.

The Wikipedia entry for DevOps is a great illustration of the issue. Wikipedia is a crowd-sourced encyclopedia, and as such it is comprised of a variety of contributions. The first few paragraphs of the DevOps Wikipedia entry actually offer up different attempts at a definition. The various explanations don’t necessarily conflict directly with one another, but they also don’t agree completely and reading the Wikipedia entry will leave most people just as confused about what DevOps is or isn’t as they were before they started.

It’s a “software development method that stresses communication, collaboration and integration between software developers and information technology (IT) operations professionals.”

The goal of DevOps is “to maximize the predictability, efficiency, security and maintainability of operational processes. This objective is very often supported by automation.”

It “targets product delivery, quality testing, feature development and maintenance releases in order to improve reliability and security and faster development and deployment cycles.”

It “aids in software application release management for a company by standardizing development environments.”

All of these are true, and yet none of them is necessarily THE definition of DevOps. The simple reality is that it doesn’t really matter.

DevOps is not a single thing per se. It is a culture, and how that culture is embraced or implemented van vary from one organization to the next without altering the fact that both are employing DevOps. DevOps is not a product or tool–it’s a culture that has evolved organically to meet the needs of a more rapid pace of IT. Many organizations are utilizing DevOps processes or tools, and have no idea what DevOps is.

If your organization has developers who manage operations, or IT ops staff who do development, or developers and IT operations staff who work closely together to get things done, you might be doing DevOps.

If your organization uses scripts or other tools to automate the provisioning and/or configuration of servers, virtual servers, or entire virtualized environments, you might be doing DevOps.

If your organization rapidly develops new iterations of an application, or continuously rolls out new features and tools, you might be doing DevOps.

If your organization continuously monitors for suspicious activity or potential malicious attacks, you might be doing DevOps.

If your organization makes extensive use of the cloud in order to be more agile, and be able to scale quickly to meet demand, you might be doing DevOps.

If your organization lacks rigid structure between departments, and functions more like a startup where everybody does everything, and just does what it takes to get things done, you might be doing DevOps.

If your organization automates simple tasks and functions with technology rather than wasting valuable man-hours doing everything manually, you might be doing DevOps.

It doesn’t matter if you understand what DevOps is. It doesn’t matter if you call it DevOps within your organization. All that matters is that you take the elements that make sense for you, and adopt them in order to function more effectively and efficiently, and remain competitive.

About the author  ⁄ Tony Bradley

Tony Bradley is a respected authority on technology. He writes for a variety of online and print media outlets. He has authored or co-authored a number of books, including Unified Communications for Dummies, Essential Computer Security, and PCI Compliance. He has been a CISSP (Certified Information Systems Security Professional) for over 10 years, and he has been recognized by Microsoft as an MVP (Most Valuable Professional) in Windows and Windows security for 8 consecutive years. Before founding Bradley Strategy Group, Tony Bradley was Chief Marketing Officer for Zecurion—a leading data loss prevention company. Prior to that, Bradley was Director of Security at Evangelyze, and was previously an IT administrator and information security consultant working with companies like General Motors, American Airlines, Marathon Oil, and PepsiCo / Frito Lay. Mr. Bradley is a frequent guest of the IMI-TechTalk radio show, and has made appearances on a variety of other radio and TV shows. He is frequently quoted, and has presented at a wide range of events.

One Comment

Leave a Comment

Directory powered by Business Directory Plugin