Over a million developers have joined DZone.

Container Issues

DZone 's Guide to

Container Issues

The most common issue affecting the orchestration and deployment of containers is lack of knowledge and experience.

· Cloud Zone ·
Free Resource

To gather insights on the current and future state of containers, we talked to executives from 26 companies. We asked, "What are the most common issues you see affecting the orchestration and deployment of containers?" Here's what they told us:


  • There’s a significant training gap. A lot of people need to learn containers. Docker initiative, orchestration need to understand more of what’s involved – best practices, DevOps skills, distributed applications, security with applications and infrastructure. 
  • Getting started. Attend meet-ups live, online courses, use CNCF. There are a lot of tools. Learn from the community. People made leap running on smaller systems and PCs are now looking at how to scale. Emergence of K8 services. 
  • There’s a learning curve with many instructions on how to use Docker and K8. A lot of help exists. People find examples of K8 implementations but fail when they move to production because they have not used all of the features and have a lack of proper configuration for deployment. Extend K8 to provide best practices out of the box. FUD – perception that containers are not secure. We provide a secure isolated environment by removing sharing. 
  • People don’t know what containers are. Oil and gas and offshore are still using VMware, IT, EXSI. It requires a lot of education on the benefits of moving to containers. Also, utilities struggle with management logging. You still need a dev team with container experience. K8 architected as a modular set. It takes new developers of solution architecture to design a system of managing container. Need to define personnel needs, timelines, and technology for container management in the cloud. 
  • There’s currently a shortage of experienced Kubernetes, Docker, and other tool engineers and DevOps people. These teams need to create proper process and workflow to deploy, update, and monitor applications in a fully distributed micro-service environment. They need be able to audit, then lock down the container platform in a dynamic environment without introducing new security holes. Finding the right security tools to monitor, track, troubleshooting, protect and automate security into the process is not easy today.
  • Lack of experience, people don't know what containers are or don't know the advantages of using them.
  • Companies start with K8 and KOps but soon realize it is not scalable or supportable, it lacks high availability and the ability to monitor. A lot of people make a big bet on containers and realize it’s a long-term journey from VMs to containers. They think it will take a quarter and it will take three years – even longer in larger companies. Ticketmaster wanted to put all of their apps in containers but found that it did not make financial sense to do so and are only putting 20% of their newest and most active apps into containers keeping the rest on VMs.
  • Education and expectations – it’s a new world. You need to reframe the problem. Containers are not a panacea for bad code and a lack of an agile or DevOps methodology. Need to understand how processes and tools change. 
  • The biggest issue seems to be the learning curve and figuring out how to set up Continuous Delivery for teams, applications and environments. This is something we're trying to address with Jenkins.


  • Requiring every workload to run in a container but running legacy with no way to update and port to a new environment. Partner to change dependency management and build process so you can put in the container. Need to automate tooling around the application. 
  • At this time, many of the orchestration and containerization tools are still in a developing state. This is exciting since it offers lots of new features and new development but also means tools can be in a rougher state than we would like or be lacking in features we deem requirements.


  • Networking and persistent storage. There are so many networking options available in Docker alone, let alone third-party network add-ins like those from WeaveWorks. How can a user possibly know which is the best network driver to use (overlay, bridge, macvlan, ipvlan, transparent, host) for their needs, and which will provide acceptable performance? Overlay driver is great at “just making networking work” but it does so at considerable performance degradation (10% of native). Same rings true with Storage drivers, Bind, Named Volume, or 3rd party storage vendor plugins supporting Block, CIFS, NFS, S3, which to use and where?
  • Organizations’ inability to keep stateful data when it’s being moved across multiple sites.
  • How rapidly it’s evolving. Spotlight on K8. Docker and Rocket can be difficult to keep up with tools. Even in proxy space understand what’s there.
  • When you need different containers to interact, they can get a bit fiddly.
  • Scalability issues need to be figured out. Going from a 1000 node cluster for a 5000 node K8 cluster requires better monitoring tools to help DevOps be more productive. 2) Networking. Microservices are only useful when they are networked together. Settling on how a developer has a network topology. Separating traffic on different networks with niche solutions. More solutions will come along. Next frontier is software-defined networking with K8.
  • Focus more on the orchestration of the environment so images are secure. As you orchestrate and deploy ensure the entire system is secure and remains secure throughout the process.
  • It can be challenging to see the value and it depends on how you define value. Do you want to use your infrastructure better? What are you putting in the container? If it’s microservices, you’ll realize the dream. If it’s WebSphere with a 5GB file you’re probably not getting as much value as if you re-architected and redeployed. Microservices and containers are almost used concurrently but there are cases where you do not need to re-architect your app. How is my application architecture helping or hindering driving value out of containers? More density out of deployment architecture. May have to adapt if I want to do loosely coupled architecture – it can take months to years, it’s a larger, longer project.
  • Very developer driven. Need to partner with DevOps to roll out but that can cause friction if the culture is not addressed. Containers cannot be siloed. Bring developer and DevOps together sooner in the application development process where containers will be used.
  • People don’t know how much they have out there and whether they have a missed configuration. We give visibility into the things you don’t know.
  • The most common issue is a containerized service that has states, is not stateless, and thus cannot be clustered; we cannot run more than one container for that containerized service. This limits the infrastructure automation options and adds additional layers of planning when expanding an environment due to increasing loads.
  • Containers often lead to compartmentalized thinking, causing people to lose sight of the bigger picture: customer experience on the application. This is a key shift in the mentality that needs to happen for the overall success of containerized applications. You need to step back and look at what customers are looking at, not just at the infrastructure. Understand the correlation between application performance and system performance is key to being strategic with how you manage containers.

Here’s who we spoke to:

containers ,cloud ,containerization ,interview ,container orchestartion

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}