In today's IT world, DevOps and containers are everywhere. These products and frameworks have done amazing things for certain admins and organizations, and you might feel pressure to implement them in your own workplace. But before you give in to pressure from vendors, management and the IT community, take a minute to consider whether DevOps and containers would really benefit your workplace.
DevOps is designed to help businesses deploy software quickly and more reliably, creating a close connection between software developers and IT operations teams. Containers provide a lightweight and flexible method for application deployment, especially compared with VMs.
However, not every organization must develop its own software, and containers introduce security risks not inherent to other forms of virtualization. It's important to consider the tradeoffs before adopting either technology.
Why DevOps?
Not everyone writes software, so not everyone requires DevOps. Many non-IT companies that provide services such as healthcare or manufacturing buy, lease or consume software from other vendors and have little or no need to modify it beyond some normal customizations.
The problem crops up because many vendors -- VMware for instance -- gear their newer tools toward a DevOps mindset. This affects the types of products vendors offer and what information you get when discussing whether to implement DevOps with your peers.
DevOps is both policy- and software-driven. Although you can ignore a policy framework to some degree, you still must contend with software, and it may be beneficial. Even if you don't create software, you might want to take advantage of the automation piece of DevOps. Automating common administrative tasks can save you time, money and energy.
Many tools designed for administrative automation are labeled as DevOps but often contain a range of admin automation abilities that non-DevOps data centers can take advantage of as well. If you buy one of these tools for your non-DevOps workplace, you might not be able to take full advantage of the product. Nevertheless, it's unlikely you'll find one that fits your system administration automation needs that doesn't have DevOps capabilities.
Containers vs. other deployment options
Many tools designed for administrative automation are labeled as DevOps but often contain a range of admin automation abilities that non-DevOps data centers can take advantage of as well.
Containers and Kubernetes are today's buzzwords when it comes to automating, deploying and scaling modern applications. Containers are software deployment frameworks that run directly over OSes, similar to a VM but without the associated overhead. Kubernetes is the most popular system used to manage containers. Even VMware -- the foremost VM and virtualization vendor -- has announced changes to its vSphere platform that incorporate native Kubernetes functionality.
Most seasoned IT pros can remember a similar buzz when the cloud first arrived. The same question applies to containers that applied to the cloud: Do you develop software?
If you don't, then you shouldn't feel an urgency to adopt containers. On the one hand, DevOps is a broadscale operations approach containing tools and practices from which you can pick and choose. Containers, on the other hand, represent a specific, dedicated software developers' technology. Bringing up a Docker cluster with Kubernetes simply doesn't serve a purpose without software code to run inside it.
Deciding whether to make the switch
Many common tools and platforms now have native container and Kubernetes support built in. If those features start to replace noncontainer features and improvements in the base products, this could become a problem for anyone who runs a data center without containers. Unfortunately, you can't control vendors' decisions in this regard, but you can influence them with your pocketbook and pressure them for the features and functionality your organization needs.
Not everyone uses containers and DevOps, and those who do might not rely on these technologies as much as they claim. However, since IT is constantly changing, it's important to remain flexible. If your vendor shifts toward containers or DevOps, you must be ready to move to a vendor that supports your requirements. Consider smaller vendors when making such a decision. The key is to find the functionality that you need even when it seems like everyone else is transitioning to DevOps and containers.
