DEVOPSdigest

Container technology, such as Docker and CoreOS, have become an increasingly popular step in DevOps journeys. Containers are lightweight and portable, making them easier on organizations' resources. Containers can benefit cloud environments in a variety of ways, but that does not mean they are perfect for every situation. Software teams must manage a container's life cycle, including provisioning, deployment, scaling (up and down), networking, load balancing and more. The maintenance and implementation of container technology can be tedious and, therefore, there are situations where containers simply are not a good idea.

I asked top industry experts — DevOps Institute Ambassadors— to share their thoughts on when you may not want to use containers. Here's what landed at the top of the list:

Anshul Lalit

head of technology and transformation, Kongsberg Digital

"Containers are perfect for deploying an application with many dependencies that the end-user does not need to touch. However, containers might not be the best option if the application is very lightweight, and it's not essential for users to quickly update the application with each new version. For example, I would recommend for a monolith lift-and-shift to use a simple VM to avoid disruption.

In addition, it is vital to understand the limitations and differences between using a container and using another technology stack. Some use cases where you may avoid containers are:

If you need to use a special driver, capability or incompatible software with the standard container kernel.

If you need to change the kernel configuration, use a custom kernel, add other software or run commands that interfere with a container's standard configuration.

If you need to work with files that are incompatible with a container. For example, if you need to access a file system or a database not available in a container.

Also, as a general guideline, I highly recommend The Twelve-Factor App methodology for building modern software-as-a-service (SaaS) apps. It just makes your product life easier, predictable and covers all bases."

Supratip Banerjee

solutions architect, Principal Global Services

"If security is a priority, maybe Docker is not the best solution.

The most significant security benefit of Docker is that it divides the software into smaller pieces. If the security of one component is jeopardized, others are unaffected. While separated processes in containers offer greater security, all containers have access to the same host operating system. You face the risk of operating Docker containers with insufficient isolation. Any malicious malware has the ability to gain access to your computer's memory.

It is common practice to operate a large number of containers in a single environment. Unless you limit the resource container capabilities, this is how you make your app vulnerable to resource abuse attacks. Each container should handle one specific area of concern for optimal efficiency and isolation.

Another issue is that Docker's default setup does not namespace users. Namespaces allow software resources to use other resources only if they are in the same namespace."

Parveen Arora

co-founder and director, VVnT SeQuor

"If you're doing a project(s) related to "lift and shift" of your applications, you may be better off with a simple VM deployment to experience the least amount of disruption. However, if you're creating a new application from scratch, you're probably better off starting with containers."

Vishnu Vasudevan

head of product engineering and development, Opsera

"If you're running a monolithic application, people assume that switching from monolithic to container-based microservices is like flipping a switch, but that's not the case. Understanding the application needs to happen first and deciding to make it containerized is only viable if your team has the right skills for converting a monolithic application into a containerized application. If you do not have the skills within the application team running the monolith, they are likely going to fail. Whoever is building the application needs to know best practices for container orchestration. They need to analyze and recommend whether or not this application fits in the wheelhouse of containerization. Do not try to move everything to containers because it's the popular thing to do or your competitors are doing it. It has to be solely based on the merit of the application, not based on the merit of the person pushing to move to containers."

Join DevOps Institute for SKILup Day: Container Orchestration, for how-to sessions to expand your container knowledge.