devopsy.kinsta.cloud

Author: Chris Tozzi

  • 5 DevOps Terms That We All Use, Yet No One Can Define

    5 DevOps Terms That We All Use, Yet No One Can Define

    I’m all for DevOps. Sometimes, however, I have a hard time talking about DevOps. The reason is because many of the key terms related to DevOps lack clear and precise definitions.

    Let me explain …

    DevOps is such a big deal that it has bred its very own lexicon. Search Google for “DevOps terms,” and you’ll find a slew of “dictionaries” and “glossaries” dedicated to defining the various terms that go hand in hand with DevOps.

    Yet despite these resources, some deep ambiguities remain regarding the actual meaning of various terms that you hear frequently in DevOps-centric conversations. Let me walk through some of the biggest.

    Continuous

    DevOps is all about continuous this and continuous that. Continuous integration. Continuous delivery. Continuous deployment.

    To me, the problem with the word “continuous” in this context is that it lacks an exact meaning. No one is integrating, delivering or deploying software in a literally continuous fashion. That would mean having zero delays between different releases, which is not the case. Even organizations that do CI/CD really well manage deliveries and deployments of only once per day or so.

    Maybe instead of “continuous,” we should just say something like “fast.” Because that’s what “continuous” really means in most cases.

    CI/CD

    Speaking of CI/CD, that’s another term that is ripe with ambiguity. It’s clear enough what “CI” stands for (continuous integration). But does the “CD” stand for “continuous delivery,” “continuous deployment” or both? Or does it not matter?

    Moreover, does a your application delivery process qualify as a CI/CD pipeline simply by including a continuous integration server (to do the CI) and some kind of automated deployment tool (to cover the CD side of things)? Or does a CI/CD pipeline also necessarily include build and test automation? I think most people would say the latter, but the term itself does not imply that.

    Microservices

    Microservices are all the rage in the era of DevOps. Depending on how you define a microservice, however, they have been all the rage for decades, long before anyone was talking about DevOps.

    The idea of distributing applications into multiple services is not new. That’s what SOA was all about in the 2000s. Going back further, there were microkernels, a concept popular in the 1980s. In microkernel architectures, the operating system kernel runs as a set of distinct services, rather than as a monolith.

    The question, then, is what makes a microservice, or a microservices architecture, different from other types of distributed, service-based architectures. Maybe it’s the size of the service, but there’s no official definition of what distinguishes a microservice from a non-microservice.

    Agile

    It is often said that DevOps builds upon the principles of agile software development. Those principles were defined, at a high level, in the early 2000s and spelled out in the “Manifesto for Agile Software Development.”

    It’s clear enough what agile means, but I’ve long struggled to piece together the exact relationship between agile and DevOps. Is DevOps “agile applied beyond the software team,” as one DevOps company puts it? Or are agile and DevOps distinct practices that just happen to have similar goals?

    It’s hard to say, because there is little consensus about what exactly “agile” means in the context of DevOps.

    DevOps

    Last but not least is “DevOps” itself. Different people have defined DevOps in very different ways. AWS says it is “the combination of cultural philosophies, practices, and tools.” Other definitions focus on philosophy, and leave tools and specific practices mostly out of the picture.

    Blurring the definition of DevOps further is the fact that virtually every tech company in the world calls itself a DevOps company today, with little concern for how, specifically, its products or services meet that nomenclature.

    What does DevOps really mean? I don’t think we’ll ever have a singular answer to that question.

    Conclusion

    In fact, I don’t think there will ever be clear definitions for any of the terms I’ve listed above. I’m not suggesting there should be.

    But I do think it would be helpful to the DevOps community as a whole to recognize the ambiguity in many of these terms. We use these words as if everyone knows what they mean, but the reality is that that is often not the case. If you want to use terms like “continuous” or “agile,” do so, but remember to clarify what those terms mean to you, because you can’t assume that they mean the same thing to others.

    — Chris Tozzi

  • How Important Is Open Source for DevOps, Really?

    How Important Is Open Source for DevOps, Really?

    Depending on your perspective, you might believe that DevOps and open source go hand in hand. Or you may think that, quite to the contrary, the two have little to do with each other. There are good arguments to be made for both interpretations.

    Let’s explore these two ways of thinking about the relationship between DevOps and open source.

    Match Made in Heaven?

    In certain respects, the two share a great deal of core philosophical overlap. Both movements emphasize collaboration and rapid innovation.

    That is part of the reason why many major DevOps tools are open source. Examples include Kubernetes, Docker, Git and Jenkins, to name just a few.

    Indeed, it’s hard to imagine any modern DevOps team or CI/CD pipeline that doesn’t rely to a significant extent on open source tools.

    The Tension between DevOps and Open Source

    On the other hand, it’s an undeniable fact that many other tools and resources that are commonly used by DevOps professionals are decidedly not open source. There are plenty of closed-source CI servers and release automation platforms, for example. (There are also many tools in this category that are built on an open source codebase but require commercial licenses and proprietary extensions for real-world use.)

    There is also the public cloud, without which it’s hard to imagine anyone doing DevOps today. Most public cloud services are very proprietary in nature. Not only can you not inspect the source code behind services such as Azure Functions or EC2, but users also have no control over how those services operate. And porting a workload from one cloud to another can be a big challenge.

    In these respects, DevOps is far removed from open source.

    How They Really Intersect

    What to make, then, of the relationship between DevOps and open source? What does it mean that they share important cultural affinities on the one hand, yet DevOps teams hardly shy away from closed-source tools and resources?

    The most obvious conclusion, I think, is that DevOps teams are committed to openness, but they balance that priority with an equal commitment to getting results. In cases where production-quality open source tools exist, such as Kubernetes, most DevOps engineers will eagerly adopt them in place of closed-source alternatives.

    In some cases, however, closed-source solutions are superior. And sometimes proprietary solutions are the only type of solution available, as in the case of the cloud. There is no open source alternative to AWS, unless you build your own cloud, but that requires having infrastructure.

    Some DevOps teams may wish that they could achieve the results they need using only open source tools. But they can’t, and that’s why the relationship between the two can seem contradictory and inconsistent at times.

    — Chris Tozzi

  • What Comes after DevOps? Two Possibilities

    What Comes after DevOps? Two Possibilities

    People have been talking about the “post-DevOps” world since at least 2014. But have we actually arrived in the post-DevOps era? If so, what comes after DevOps? Let’s explore those questions.

    The DevOps concept is more than a decade old. DevOps has seen widespread adoption across companies large and small. “DevOps engineer” is now a common job title for tech folks.

    At a minimum, these developments mean that DevOps is now very mature and mainstream. They may even signal the end of DevOps, depending on your point of view.

    Even though DevOps remains a useful concept, the fact that DevOps is now so mature means it is no longer as novel and dynamic as it once was.

    That begs the question: What comes after DevOps? I think there are two distinct possibilities.

    A Reaction Against DevOps

    One possibility is that we’ll see a backlash against DevOps, and an attempt to replace DevOps processes with alternatives that are designed to do the opposite.

    Indeed, there has already been a fair amount of outspoken criticism of DevOps for years. It has mostly remained under the surface.

    But in an era when almost everyone is doing DevOps, it seems reasonable to expect that some organizations will find it doesn’t solve their problems after all. Those organizations most likely will return to earlier ways of doing things.

    In this scenario, DevOps is unlikely to disappear entirely. But we probably would end up in a hybrid world where software delivery teams mix DevOps principles, tools and practices with those from earlier eras.

    DevOps-ifying the Whole Organization

    The other main possibility for the post-DevOps world is that we’ll see DevOps extended into more and more parts of the business that are not directly related to the two core areas of DevOps practice, development and operations.

    This trend has already been playing out to a certain extent for years. Concepts such as DevSecOps (which extends DevOps into the security realm) and DevQAOps (which integrates Quality Assurance with continuous delivery) have been around for at least several years.

    Still, there is room for DevOps concepts to establish deeper roots in areas outside of dev and ops. Most organizations could benefit from doing more DevSecOps, for example. And as I’ve written in the past, even PR, legal and other departments could be integrated more tightly into the software delivery process.

    To date, few organizations have sought total DevOps-ification by applying DevOps principles to all business units. But this could be the great innovation of the post-DevOps world. If this scenario plays out, DevOps won’t go away; rather, organizations will double- or triple-down on their investment in DevOps.

    — Chris Tozzi

  • For DevOps, (Organizational) Size Matters

    For DevOps, (Organizational) Size Matters

    When it comes to DevOps, size matters. The number of people in your organization, as well as the size of its infrastructure, play a huge role in shaping how and why you adopt DevOps.

    The importance of company size may come as a surprise. Few conversations about DevOps mention the role of organizational size in building a strategy.

    That may be in due, in part, to the fact that DevOps engineers tend to be obsessed with the idea of scalability. A healthy DevOps process is one that can support an application with a million users just as effectively as it supports an application with a hundred users.

    In theory, your strategy should be similarly scalable. But in reality, this is unlikely to be the case. The way that a company with a dozen employees does DevOps is going to look quite different from the way a Fortune 500 company does.

    Small Companies

    In a sense, DevOps is easiest to achieve at very small organizations. In fact, it is almost inevitable in companies of this size.

    That’s because, when you have a very small IT staff, your engineers will end up playing multiple roles because that is the only way that all IT tasks can be completed successfully. People you hire as developers will have to help support and test the apps they write because otherwise, those processes might not happen.

    What this means is that at small companies, it tends to be something that happens organically, not deliberately. IT teams at such organizations don’t need to plan a DevOps strategy; they just need to let it come into being of its own accord.

    Large Organizations

    You might expect the opposite to be true within large organizations. But in many cases, it’s not. Large companies may also find themselves building their strategies organically.

    The reason is that, at large enterprises, the IT organization tends to be broken down into many small teams, each working on different apps and processes. Because these individual teams are small, their members also tend to embrace DevOps practices by performing multiple IT roles, whether deliberately or not.

    True, large companies often benefit from planning and implementing a companywide strategy. Encouraging DevOps best practices companywide can help to improve collaboration between different teams within the organization. It can also improve the ability of security or QA teams, which may otherwise operate in silos, to interact with other groups.

    But by and large, if you are an enterprise whose IT staff are broken into a number of small teams, you will likely find that DevOps happens more or less on its own.

    Medium-Sized Organizations

    It’s medium-sized organizations that tend to have the hardest time doing DevOps effectively. That’s because these organizations are large enough to have a sizeable IT organization, but too small to break that organization down into multiple project teams.

    As a result, medium-sized organizations erect the most rigid silos around their IT teams. They might have a single team of developers who focus on building a few applications, and a single IT Ops team whose job is to support those applications. But these two teams may not interact much.

    For this reason, a deliberate DevOps strategy is most important for organizations that are of a medium size. Their silos need to be broken down actively.

    Conclusion

    The bottom line: When it comes to adopting and improving DevOps, take some time to evaluate how the size of your organization impacts it. Is your company sized and organized in such a way that it will more or less happen on its own, or do you need to take deliberate steps to implement it? Answering this question is crucial for achieving DevOps in the most seamless way possible.

    — Chris Tozzi

  • Blockchain: A Threat to DevOps—and How Engineers Can Respond

    Blockchain: A Threat to DevOps—and How Engineers Can Respond

    Blockchain is one of the hottest topics in the IT world today—and that creates a challenge for DevOps professionals. Here’s why, and what DevOps engineers can do to remain relevant.

    Blockchain, Fat Protocols and a New Generation of Applications

    To understand why blockchain threatens to decrease the role played by DevOps engineers in software platforms, you have to understand the difference between blockchain-based applications and traditional applications.

    That difference was summed up most famously in an article by Joel Monegro about “fat protocols.” Monegro convincingly argued that prior to the introduction of blockchain technology, most software stacks were composed of “thin protocols” and “fat applications.”

    What he meant was that in most traditional web applications, the majority of the value and functionality lies in the application itself, rather than in the protocols on which it runs.

    In other words, if you write a PHP application, most of the time that you invest and the value you create center around the application code. The protocols that allow the application to work, such as HTTP, are relatively simple and uninteresting.

    In blockchain-based applications, by contrast, the magic happens chiefly at the level of the protocol. The main job of these applications is simply to access that protocol. As a result, the applications themselves are relatively unimportant.

    How It Changes DevOps

    What this means for DevOps is that, if blockchain becomes as central to the software platforms of the future as its proponents hope, application code will become much less important than it is today.

    By extension, the people who write and manage that code—DevOps engineers—will have less of a role to play in software deployment.

    If you take a look at how most existing blockchain platforms operate, it’s easy enough to see how this trend plays out. The amount of effort required to write and maintain a basic “smart contract” application that runs on the Ethereum blockchain, for example, is pretty minimal. You don’t exactly have to be a DevOps genius to churn out some if-this-then-that code that interacts with Ethereum.

    The same is true of an application that writes data to the Bitcoin blockchain to record a real estate transaction, for instance, or one that timestamps a document to a blockchain to create a record of the document’s existence.

    In these use cases—as with almost all use cases associated with the blockchain—the role played by DevOps engineers is relatively small, because there is not much code to write or manage to deliver the platform’s core functionality.

    Blockchain-Proofing DevOps

    Yet, if the blockchain revolution does come to pass, it won’t necessarily be bad news for DevOps experts.

    Even though the core application code required to interact is minimal, crafting platforms that are secure and provide a solid user experience takes more work. This is where DevOps engineers can help.

    One of the most glaring problems with many existing blockchain platforms is that their interfaces tend to be difficult to use. Related software security problems are also well-known.

    In addition, some platforms have performance and scalability problems. Bitcoin advocates like to talk about how digital currency will make transactions much smoother, but the reality is that it can take hours to confirm a Bitcoin transaction. That’s a big problem if you want to buy and sell things with Bitcoin.

    Arguably, these issues originate in part from the fact that many of the people currently designing blockchain platforms are good at recognizing how decentralized, distributed databases can drive innovation, but less adept at writing, maintaining and scaling software and the databases that power it. They are not, in other words, DevOps people.

    By helping to build out blockchain applications so that they are actually usable, secure, efficient and scalable, DevOps professionals can ensure themselves a role to play in the platforms of the future. At the same time, they’ll help the technology transition from its current state of hype into something that can be used to solve everyday problems.

    — Chris Tozzi

  • Making Software Maintenance Cool Again with DevOps

    Making Software Maintenance Cool Again with DevOps

    What makes DevOps so important? Part of the answer lies in how DevOps encourages more appreciation for and investment in software maintenance.

    Traditionally, the IT industry has been like the construction industry. People who design new things (architects or software developers) are at the top of the value hierarchy, whereas the folks who build and maintain them (construction workers and IT Ops admins) are not held in such high esteem.

    This isn’t to say people hate admins, of course (or construction workers, for that matter). What I mean is that the work of building and maintaining tends to be seen as less creative and exciting—and ultimately less important—than the work of designing new things.

    This is why software developers in the pre-DevOps world got most of the glory. They created new code that did exciting things.

    Meanwhile, admins on the IT Ops team were stuck deploying and maintaining that code—and occasionally cleaning up messes created by developers who wrote bad code. Admins were also the first folks to take the blame when something went wrong.

    This isn’t to say that developers cause all the problems, of course. Some mistakes can be attributed to admins. Others are the result simply of poor communication between developers and admins.

    Still, in general development work—which involves creating new features and innovations—was what was celebrated. Maintenance work performed by IT Ops was less glorious.

    DevOps and Software Maintenance

    One of the most important—yet also most underappreciated—results of the DevOps movement is that it has made software maintenance cool again.

    In addition, DevOps provides more organizational support for maintaining software, while also facilitating the type of communication between developers and admins that leads to better maintenance.

    DevOps does this through principles such as the “you build it, you own it” mantra, which stipulates that whoever writes code is also responsible for deploying and maintaining it.

    Even if your organization doesn’t adopt that particular DevOps practice, it probably still seeks greater collaboration between developers and IT Ops. As a result, when something breaks in production or needs to be upgraded to maintain reliability, developers are involved, too.

    Celebrating Software Maintenance in DevOps

    Despite the emphasis that DevOps has brought to software maintenance in practice, you still don’t hear a lot of talk about maintenance work in the DevOps world.

    In essence, coding is still seen by many people as the coolest type or work that is done in the DevOps world. What DevOps has done is break down the silos separating those who code from those who maintain. It hasn’t necessarily made maintenance itself the object of more excitement.

    It may be time for that to change. Forward-thinking organizations should recognize that software maintenance—which includes tasks such as applying updates, monitoring applications and scaling host infrastructure—is just as crucial for a seamless application experience as the applications themselves. This should become an explicit part of the DevOps conversation.

    — Chris Tozzi

  • How Blockchain Tech Can Make DevOps Better

    How Blockchain Tech Can Make DevOps Better

    DevOps and blockchain are among the hottest topics in today’s technology world. However, you rarely hear the two discussed in tandem. Going forward, that may change. Here’s why.

    On the surface, the two may not seem to have much to offer each other. DevOps is a set of cultural principles and practices designed to improve software delivery. Blockchain is a way of storing data in a decentralized fashion.

    Bitcoin, a digital currency whose transaction records are stored using a blockchain, is the most well-known example, but the world is much bigger than Bitcoin.

    So, besides using DevOps practices to create blockchain-based applications, how can they be used together?

    DevOps on the Blockchain

    The answer centers on making software delivery chains more transparent and reliable via blockchain technology.

    What if, instead of relying on tools such as continuous integration servers and automated test suites to determine that code is moving down the pipeline successfully, you instead recorded that data on the blockchain?

    This would make software delivery more transparent, which would in turn improve software quality and reliability. Application delivery status and information about software problems could be viewed instantly by anyone over the blockchain, providing a much greater deal of visibility into the continuous delivery process.

    In addition, smart contracts could be used to regulate how code moves down the pipeline. They could also ensure that software deliveries meet user expectations.

    Rather than relying on tools within the pipeline to catch problems such as a continuous integration error, information could be independently and automatically verified via smart contracts on the blockchain. If a problem occurs, the smart contract could require that it be fixed before it moves down the pipeline and grows into a bigger problem.

    SLAs and Smart Contracts

    At the same time, software functionality could be guaranteed using smart contracts. Currently, DevOps teams use service level agreements (SLAs) to promise their application users a certain degree of functionality and reliability in an application.

    SLAs are not a great solution. They are inefficient to negotiate and costly to dispute. If an application fails to meet SLA terms, it’s on the user to report the problem and demand a solution.

    If service agreements were instead recorded on the blockchain and enforced via smart contracts, users would have a guarantee that an application’s failure to provide the guaranteed functionality would be detected automatically. It could also result in an instant solution, such as the refund by the smart contract of a contractually determined amount of money.

    Traditional SLAs, and all of the inefficient legal and contractual trappings that surround them, would become a thing of the past.

    Conclusion

    For now, no one is actually applying it to improve DevOps and continuous delivery. Like most blockchain-enabled innovations, this remains a theory, not a reality.

    Yet, its potential to improve the work of DevOps teams, and the experiences of their users, is clear. Blockchain may not be a part of the DevOps conversation today, but it is poised to become a part in the future.

    — Chris Tozzi

  • Self-Healing Service Management and the Future of DevOps

    Self-Healing Service Management and the Future of DevOps

    How can DevOps teams take continuous delivery to the next step? Part of the answer lies in self healing, which could optimize performance management and monitoring and underpin the software delivery pipelines of the future.

    Self healing means the ability of systems or environments to detect and resolve problems automatically. It eliminates the need for manual human intervention, upon which most systems today still rely to fix issues.

    Self healing is better than depending on humans for several reasons:

    • Automated solutions are less likely to miss issues by mistake, or to make errors when resolving them.
    • Self-healing technology is better positioned to fix problems faster than humans because it can react instantly based on rules or machine learning. It doesn’t have to stop and think about the issue before taking action.
    • A self-healing environment can scale without limit. This is a key advantage over manually managed environments, whose scalability is limited in some respects by the availability of human admins.

    Self Healing and Continuous Delivery

    DevOps teams already take advantage of many other kinds of automated tools to help achieve continuous delivery.

    They use continuous integration servers to automate tests. They adopt release automation tools to streamline deployment. They implement orchestrators and scripted infrastructure to provision environments automatically.

    Yet, when it comes to performance management and monitoring, the typical organization is a far way off from achieving a fully automated process. Even the best application performance management (APM) tools of today are primarily capable only of detecting problems and displaying information about them. They depend on humans to interpret and react to that information.

    That dependency is a major obstacle for achieving fully continuous delivery. You can’t release code quickly if your process for finding and solving problems related to the code is mostly manual.

    By making better use of self-healing technology, DevOps teams can speed continuous delivery in the following ways:

    • Developers and admins can spend less time on monitoring and more time completing other tasks that can’t be automated.
    • Ideally, teams will be freer to switch between development environments and frameworks without having to establish a new monitoring workflow. Self-healing tools will adapt to whichever environment they have to work with.
    • Because problems can be found and fixed faster, infrastructure utilization can increase. The need for a buffer between average usage and overload can become smaller because automated healing solutions will be able to fix problems before they lead to failure.
    • Teams can establish better continuous feedback loops because, by removing the human element from performance and monitoring, incidents can be reported instantly, consistently and in a way that makes the data easily accessible to everyone on the team.

    To be clear, the technology for self healing does not yet fully exist. Developers over the past several years have made great strides in automating configuration, service discovery and environment provisioning, But perhaps it’s time to make them a more prominent focus. They’ll enable the DevOps innovations of the future.

    — Chris Tozzi

  • 5 Ways DevOps Can Help Improve IT Security

    5 Ways DevOps Can Help Improve IT Security

    You already know DevOps can make software delivery faster and more efficient. But did you know it can help to keep software more secure, too? Here’s how.

    DevOps refers to a set of practices and cultural priorities related to the way software is designed, produced and deployed. It emphasizes collaboration between developers (the people who write code), IT Ops (the folks who manage software in production) and everyone in between—such as software testers and designers.

    When done properly, DevOps greatly reduces the time it takes to bring software from idea to implementation to end user delivery. It also adds efficiency to the software delivery process in many ways. It allows different team members to work in parallel, for example. It also ensures that coding problems are found early in the delivery pipeline, when fixing them requires much less time and effort than it does once a bug has been pushed into production.

    DevOps and Security

    But making software delivery faster and less costly isn’t the only thing DevOps does. DevOps also helps make software more secure.

    It does this in several ways. Consider the following:

    • Visibility. DevOps encourages constant communication between all members of the IT organization. That maximizes each team member’s visibility into the software being developed. In so doing, it places as many eyeballs as possible on the code, at all stages of delivery—which maximizes opportunities for your staff to find security flaws before code is released into production.
    • Automation. In the DevOps world, software delivery tasks are automated as much as possible. With automation comes consistency and predictability—and a much lower chance that human error during a manual process could introduce a security vulnerability.
    • Fast updates. DevOps enables a much faster pace of software delivery. That means that security bugs (and bugs of all kinds, for that matter) can be squashed very quickly by rolling out a fix.
    • Tool-agnosticism. With DevOps, you can use whichever tools or programming frameworks you like. You’re not bound to particular platforms or vendors. That’s important from a security perspective because it empowers you to adopt the tools that are most secure for your needs—not the ones you’re locked into because you have an outdated, inflexible software release process.
    • Agile technology. While DevOps doesn’t require you to use any specific type of tool, DevOps teams tend to favor next-generation architectures and technologies, like microservices and containers. These help to make apps more secure by reducing attack surfaces and enabling quicker reaction. If you deploy your app using containerized microservices, it becomes harder for attackers to compromise your entire app, because an attack against one microservice doesn’t give them control of the other ones.

    DevOps isn’t a silver bullet when it comes to cybersecurity, of course. Keeping your systems and data secure requires careful planning on a number of fronts and implementing a variety of tools.

    But DevOps—especially a highly automated, DevOps-based release process—should be one important weapon in your cybersecurity arsenal.

    — Chris Tozzi

  • Everything Ops: Are DevOps Principles Being Applied Too Broadly?

    Everything Ops: Are DevOps Principles Being Applied Too Broadly?

    From big data to storage to security, the DevOps concept is being applied to every field of IT operations under the sun today. This “Everything Ops” movement reflects the popularity of DevOps—but is it also diluting DevOps’s significance?

    DevOps itself focuses on software delivery. It’s about designing, building, testing, deploying and managing software applications.

    If you follow the DevOps conversation, however, you know that DevOps principles are now being extended to lots of niches that don’t have much or anything to do with software delivery chains. Consider these examples:

    • DataOps: DevOps principles for data analysts.
    • ChatOps: The idea that chat tools should be integrated into workflows.
    • SecOps (or rugged DevOps, or DevSecOps, or whatever else you want to call it): DevOps practices for security teams.
    • Storage Ops: The insertion of DevOps practices into storage.

    The list could go on. Taken together, these many flavors of DevOps reflect what I like to a call an “Everything Ops” tendency. Fans of DevOps want DevOps to take over the entire world of IT.

    Benefits and Drawbacks of ‘Everything Ops’

    If you believe that DevOps represents a better way to deliver software, then the Everything Ops movement is a positive thing. It’s a way to help people who work in areas of IT other than software delivery to innovate as well by taking cues from their DevOps colleagues.

    But there is also a danger that Everything Ops can be applied too broadly. You can’t fit every single thing in the IT universe into the DevOps mold. For example, CloudOps (the DevOps-related way of managing cloud infrastructure, not the company of the same name) just doesn’t make a lot of sense. It’s basically just a reiteration of the ideas that are already at the core of cloud computing: Scalability, agility and location-agnosticism.

    Concepts like ChatOps can also be problematic because they refer to a specific way of using a particular type of technology, whereas DevOps is about cultural practices. ChatOps is a fundamentally different sort of thing from DevOps.

    Conclusion

    In short, by overextending the DevOps conceptual framework, you run the risk of diluting the importance of DevOps itself—and of losing your focus on software delivery, which is the area that DevOps benefits most.

    This is not to say that we shouldn’t extend DevOps to other fields. We certainly should. But we should be careful when doing so. Don’t try to make DevOps eat the entire IT world, because that just doesn’t make sense.

    — Chris Tozzi