DevOps Concerns

DZone 's Guide to

DevOps Concerns

Teams need to focus on organizational change first, the complexity of the tools, and the difficulty of finding people with the right skill set.

· DevOps Zone ·
Free Resource

To understand the current and future state of DevOps, we spoke to 40 IT executives from 37 organizations. We asked them, "Do you have any concerns regarding the current state of DevOps?" Here’s what they said:

Organization Change

  • Don’t over-engineer. Ideal DevOps situation is a company building with as little friction as possible in the best fashion. Copy the culture not what’s been deployed. 
  • As I mentioned earlier, a lot of tools are being spun as DevOps, but if those tools don’t focus on building the culture—on bringing people closer together—and on increasing value creation, then they’re not really doing DevOps. 
  • We still have too many organizations not focused on systems thinking. People are hyper-focused on automation when they don’t have a great culture. Automation helps companies fail faster. Be value-stream minded. Plan backward. Most bottlenecks are at the very end. Plan backward to get to the bottleneck more quickly. Focus on reliability versus resilience. 
  • Not sure. See where it goes in a year or two. Getting too far away from culture drivers and getting too lost in the technology. Success is breaking down silos between dev and operations. 
  • I think there are many concerns and challenges with the current state of DevOps.  The hype and expectations are high.  Implementing and scaling DevOps in large enterprises is difficult.  It’s a transformational experience, not a project.  Many companies will jump on the DevOps bandwagon without understanding the primary business objectives, and they will also not be willing to make the cultural changes necessary to create an organization that is focused on continuous improvement.  They will meet failure with regression and revert back to the old way of doing business which will put their business at a disadvantage.


  • There are so many tools in the DevOps space that all claim to solve DevOps challenges. It is becoming a very crowded space and many vendors are claiming to have the silver bullet to solve DevOps. My concern is for companies that are just starting to test the DevOps waters. It can be very confusing and overwhelming, given the broad array of choices and methodologies. 
  • One concern I have is that as we continue to use more layers of abstraction on top of the underlying computer system to simplify building automated and complex distributed systems, that the next generation of engineers may lack the fundamental system knowledge necessary to truly understand what their applications are doing. I see things potentially headed this way with the emphasis on fully abstracting compute through concepts like Functions as a Service, which, while a powerful tool, could potentially lead to engineers who are unaware of the realities happening behind the scenes. A person is only capable of holding so many layers of abstraction in their mind at once and still working at that top layer. Building a robust, high-performance, scalable, and secure system relies on fundamental systems understanding. It creates a catch-22 for the next generation of DevOps engineers.


  • Not enough practitioners, more expensive to hire, not taught in school. As more people adopt it becomes a more expensive labor proposition. It affects what a developer is.
  • How do we move this faster especially on the people side? This is a giant transition for the industry and a different way of getting the software to the market. Significant skillset needs. How do we get people to evolve their skillsets?
  • It seems like there are fewer and fewer people in the field capable of doing the job. This may have to do with the fact that people don’t want to be ‘on call’.


  • People are still not buying into full testing with a repeatable baseline. Still a few cutting corners. Do it right the first time or you’ll have to do it again. If you get failures that’s good data, you can fix it before too late. Data tells you whether it’s good or bad. Don’t have fear of getting a bad result. Security tends to be overlooked. Multi and hybrid-cloud need to be paying more attention to security.
  • It's still early in maturity. Part of the problem is people promising silver bullets. Gartner hype cycle – multi-year journey, organizational change, here’s the value you can realize. Set reasonable expectation. Don’t leave a bad taste in people’s mouth. It’s a three to seven-year process, not six months. It took 12 years to go to VMware, how long do you think it will take to move to microservices? 
  • The level of maturity is growing but some things are still unknown with regards to tooling and deployment environments. The notion is that people who have done DevOps to-date were very forward thinking. The next batch will do DevOps because its fashionable or trendy but they don’t do it well – they will be less successful. 
  • DevOps leads people to just think dev and ops. DevSecOps is really agile with a customer feedback loop. Every company and vendor talks about DevOps in a different way. We need greater clarity and simplicity. We're getting better but we still have different interpretations.
  • What do you do with legacy systems? How do you adapt and make sure they do not slow you down? Each organization has to deal with their legacy systems and software.
  • Need an exit plan for the technology we cannot get spare parts for in two years. Different architectures, processes, teams you need coordinated releases and deployments. Need to coordinate to release a new mobile app. Freak out shows in many ways. IT delayed set up of Chef prototype environment for two years. Need to be smart and transparent.
  • DevOps will evolve as businesses adapt and discover its greatest benefits based on their own needs. One area that we see DevOps helping tremendously is in reducing technical debt. Many development teams find themselves having to update a horribly outdated project or struggling to keep applications up to date and clean. Often, engineering finds itself at odds with business stakeholders or trying to squeeze major refactors into feature development. Paying down tech debt is never a bad thing if it helps a company grow. Companies with minimal technical debt are nimble and more competitive. DevOps is an important triage step towards paying down that tech debt. 
  • Converting (or creating a new one) the application to DevOps is only part of the challenge. One of my major issues in DevOps is databases. Databases are stateful and cannot be treated the same way as stateless applications. We cannot spin down and spin up and scale down and scale up databases easily as data has gravity and requires special caring and feeding from the team. This makes it hard for them to be adopted in a DevOps environment.
  • We have embraced a culture of diversity and team-driven innovation, which has led to great success with our products. Many of these achievements can be attributed to the fact that we enable different teams to leverage different tools in building their applications. However, this heterogeneity also brings two challenges: 1) Different levels of SDLC maturity - While some teams are pushing the envelope and using the most up-to-date DevOps solutions, there are still teams across the organization that need more help to modernize their developer workflow. 2) Change is hard - Long-standing organizational structures, culture and dynamics, as well as code pride, are often barriers to cross-team collaboration and InnerSourcing. Another challenge we have is how to set up best practices for newer DevOps tools within the organization. For example, the way Docker images are typically reused across the industry represents a risk, because it’s often hard to reproduce the sequence of steps needed to build an image. This is especially true if you’re using up-to-date versions of the depended-upon images. As people are updating their workflow to leverage tools like Docker, we need to develop a better Continuous Integration/Continuous Development (CI/CD) practice for Docker images - one that will likely require some form of mechanism to keep track of coherent sets of versions across images that are already tested.
  • Yes, as DevOps adoption increases, there is always an over reliance on tools. This tool will fix the problem! Or, that tool didn’t work, and we need to use this tool. Teams must always remember that tools are not culture. I’d hate to see DevOps viewed as a set of practices that may or may not work for a company. DevOps, when implemented well, works every time
  • 1) As with any other technology, things will evolve with time and more research. To mention one concern in particular, it seems that DevOps is typically limited to the developers and operations teams. By integrating DevOps solutions with third-party software, the DevOps scope could be extended to include other teams in the IT department. 2) DevOps should also be able to support more complex applications to better facilitate technological adaptation. Many organizations have large, complex application ecosystems, a lot of which fall outside the scope of DevOps. Support for such complex applications will allow businesses to overcome the barriers of traditional application life cycle management and adopt DevOps more willingly. Also, with increased awareness, more IT Ops teams will see the business value in DevOps and consider implementing DevOps for delivering maximum efficiency. Compared to how quickly enterprises adapt to DevOps changes, having SMBs get completely on board with DevOps seems like a challenge.

Here's who shared their insights with us:

automation, ci/cd, devops, enterprise devops

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}