Concerns With the Current State of DevOps

To gather insights on the current and future state of how DevOps is scaling in the enterprise, we asked IT executives from 32 different companies to share their thoughts. We asked them, "Do you have any concerns regarding the current state of DevOps?" Here's what they told us:

Complexity

• My biggest concern is the ability for traditional enterprise IT organizations to adopt and execute using DevOps.  These organizations often struggle with enterprise IT best practices like ITIL, high uptime, asset tracking, and cost control.  Now we are expecting them to rapidly pivot to DevOps; most of whom will not be able to do so. This could lead to business units hiring developers themselves, shifting app development to public clouds, and bypassing enterprise IT.  While it may provide the speed the business units demand, it brings with it a host of other issues like security, cost control, and vendor lock-in.  These are similar technology issues that enterprise IT organizations were originally put in place to deal with. Therefore, unless enterprise IT organizations can rapidly pivot to DevOps, companies will be re-introducing technology problems inadvertently. 
• DevOps is still hard. Even when you get by people’s unwillingness to change, they have to collaborate, use different tools, and security testing and QA need to be incorporated earlier. Organizations are being told you need to look at containers, cloud, serverless architecture in the cloud. That’s hard.
• Operating lean cross-functional DevOps teams is a complicated challenge to maintain over the long term. It requires continual leadership support and vigilance to ensure active learning by individuals at levels necessary to persist the full coverage of skills and competencies within the team. If an organization fails to maintain the full complement of skills needed "in team" you must go into immediate DevOps team rebuild mode and have the support structures available to provide skills backfill across teams when required. Ensuring excellent employee retention through high levels of ownership and purpose helps but cannot prevent these cycles.
• More microservices, greater complexity, great chances of outages popping up. You need a way that scales. Response and prevention are becoming more important. Moving from reactive to proactive. Site Reliability Engineering is more proactive.
• I believe the current state of DevOps is somewhat fragmented. There are way too many overlapping tools and services that essentially accomplish the same tasks. The message tends to get lost in all the noise and it makes it harder to truly surface the best tools and services in any particular area of DevOps.
• It takes time to go through conversion and adoption. DevOps is doing well. It’s difficult to affect widespread change in how people code. 
• My biggest concern is in seeing the struggle that companies go through to transition to DevOps. This often leads to disappointment and frustration that an organization is actually WORSE OFF after they begin their transformation. This stems from a reliance on “automation” as the secret sauce for transitioning to DevOps is a mistake, and the industry recommendations I often hear revolve around recommending that companies automate as a path to DevOps. The problem is, what do you automate? A more thoughtful approach, in the beginning, to better understand where the problems and bottlenecks actually reside, will provide a baseline of capability and a benchmark for improvement. 
• Most large organizations already have a DevOps practice in place. The question is: How can we evolve those capabilities for smaller organizations who don’t have the team? The biggest challenge is that most of these DevOps tooling is open source, and smaller organizations have the challenge to integrate this tooling into their environment, due to the complexity associated with it. 
• The amount of DevOps tools, design patterns and methodologies available today can be overwhelming for someone new to the industry. Fortunately, there’s help available in community content, engineering blogs of early adopters, and companies providing training and integrated DevOps products. 
• There are a lot of cool technologies in this space, but there's a lack of awareness and knowledge about what and how to use. Existing technologies like the Kubernetes platform are still not approachable by most people.

Security

• There needs to be a focus on security. Security elements need to be fully integrated and automated into the DevOps pipeline. Take a security-first stance developing a DevSecOps process.
• It’s too easy. The problem with folks not paying attention to data security best practices. It's too easy to develop and deploy easily taking a faulty solution and deploying to a lot of devices very quickly. If there’s a compromise, it gets out to a lot of devices.
• More teams need security professionals to deliver DevSecOps. 
• DevOps is often disconnected from Cloud Security.  DevOps needs to be tightly integrated with Cloud Security in order to ensure security isn’t an afterthought. 
• DevOps often gets lost in the origin of Dev and Ops, particularly IT Operations interfacing with software development. As the world is changing, software engineering is often taking over many of the traditional IT operations functions. Focusing on pure "DevOps" can lead to slowing down the transition of IT Operations from the legacy model of a siloed organization into a more distributed model. Additionally, as security continues to be a top concern of the boardroom, security has to become a top concern for technical teams. As a result, we are seeing more enterprises trying to adopt DevSecOps as a way to integrate security into their existing DevOps-style software engineering and delivery processes. Unfortunately, most existing monitoring, troubleshooting and security management solutions are not up to the task and teams are struggling to implement common toolsets and processes to effectively address security. 
• It’s concerning that DevSecOps is still often a separate discussion, a separate category, or (worse) not discussed at all. While a strong DevSecOps approach is not going to magically protect our organizations from all social engineering, network penetration, or myriad other security risks and should not be considered a replacement for broad organizational security practices, a DevOps practice that does not include security practices and involve security experts is a missed opportunity to automate and integrate security into our products, and (more importantly) an exposure to security risks in both the final product and the development toolchain itself.  It’s important that we begin to understand DevSecOps as a default practice of good DevOps and consider it essential to any strong DevOps practice.

Understanding

• The only concern is everyone has their own idea of what DevOps means. Some only think infrastructure or cloud while others think quality engineering, CI/CD, and business has their own idea. Ensure everyone understands and has a single definition of what DevOps. 
• We need to get beyond seeing CI/CD as a way to more quickly and more safely ship and remember that of the three key essentials (Flow, Feedback and Continuous Experimentation), two of them focus on learning and adapting/iterating based on real-world success and failure. 
• 1) The skill level of teams and being able to manage tools, deploy code, K8s is evolving, how to help the team build and stay on top of what’s current in the landscape. K8s as a platform is evolving rapidly. If you don’t it’s hard to support your dev team. Build and maintain the skill level of the team. 2) How the DevOps function is perceived. It's incumbent upon senior leaders to build your own flavor of what DevOps means. Define what the DevOps practice is and is not supposed to do. Different parts of the organization don’t have the same definition. It affects the level of expectations around the team and affects hiring as well. Have an agreed-upon definition. Without the right expectations, it’s very hard to achieve a goal. 
• Our biggest concern is the notion that DevOps is considered by many organizations and companies as a “cure” to any technical challenges in the larger software development community. An analogous situation that comes to our mind here is Agile methodology, which has turned into a curse word in some organizations as it didn’t magically fix their problems. In both cases, it is important to realize that methodologies provide ways to approach a challenge, provide guidelines, but in the end, the organization has to change how they approach the challenges, consider the DevOps approach in the early stages when designing, and start to implement their solutions. 
• DevOps has become a synonym for “good.” There’s a danger that DevOps is becoming so vague it becomes meaningless. We need to get to the point where we stop talking about DevOps and speak more concretely around what we’re doing. 
• DevOps is more of an approach than a role that pertains to the team. It requires focus and support from all the different teams, and even management, to make it truly efficient. Sadly, that is not the case in many organizations, as it is seen more as an afterthought. 
• It is both a blessing and a curse that DevOps has become an umbrella term for the broad idea of modernizing software deployment and delivery. Due to its popularity, I’ve noticed many people say they are on-board when it comes to implementing DevOps, but don’t fully understand what the transformation process entails. It’s critical to note that a DevOps initiative will be unsuccessful if teams are not willing to change. I have seen many business and technical leaders have a difficult time letting go of current processes and putting their trust into employees/co-workers. Willingness and deep inclination to change is a prerequisite to successful DevOps transformation.

Business

• We’re not seeing enough about the business of DevOps. What does it cost and how is it measured? There’s a need for business case justification. I am concerned that DevOps is becoming a silo. I cringe when I hear, “It’s DevOps over there.” It should not be “them versus us.” We’ve made progress with DevOps. It began with a vague definition. Every company is unique in their own needs, we’re codifying practices. Moving beyond CD and Infrastructure-as-Code with other things getting more prescriptive.
• Still, think a lot of DevOps initiatives are not delivering the business benefits. It's engineering-driven versus business-outcome focus. Any DevOps initiative is being driven by a business need. We call it value stream management; others may call it something else. 
• A lot of DevOps engineers seem to focus a lot on what tool to use instead of looking at the larger picture and strategize on the business problem that needs to be solved.

Other

• Believing the latest and greatest technology can solve all of the problems all of the time. Play with it, try it, but don’t force-fit.
• As DevOps continues to mature, it’s becoming increasingly important to identify metrics that have actual meaning. Doing DevOps just for the sake of DevOps is not efficient. Speed to deployment should remain a key measured metric. A metric that can’t accurately be measured is worthless. 
• I have concerns related to trying to solve everything. Having read “Accelerate” a couple of times over the last year, I think it’s important to focus on just a few of the important KPIs. It seems as though everyone is trying to sell you a solution that will turn you into a DevOps team and, in reality, you have to put in some of the work to transform into a team that uses the DevOps methodology.
• It’s truly an evolution and a journey for every organization. However, it’s one that I strongly believe will quickly create an ever-growing divide between the more nimble and innovative companies from the rest of the pack.
• Today’s DevOps methodologies focus more on keeping servers up and running than helping development teams build more scalable and resilient applications. Clouds like AWS require much more repetitive manual work than they should.
  

Here’s who shared their insights:

• Nancy Wang, CEO, Advancing Women In Product
• Mick Morrissey, Director of Engineering, Asavie
• Lyon Wong, Founder & COO, Blameless
• Patrick Reister, Senior Build Engineer and Ivan Szatmári, Head of Release Management, Bohemia Interactive Simulations (BISim)
• Rob Zuber, CTO, CircleCI
• Brian Dawson, Director of Product Marketing and Brian Nash, Director of Product Marketing, CloudBees
• Eric Robertson, V.P. Product Marketing Management & Strategy Execution, CollabNet VersionOne
• Jeff Williams, Co-founder & CTO, Contrast Security
• Mike Rose, VP Engineering, Cybera
• OJ Ngo, CTO, DH2i
• Chris DeRamus, Co-founder & CTO, DivvyCloud
• Tobi Knaup, Co-Founder & CTO, D2iQ
• Andi Grabner, DevOps Activist, Dynatrace
• Antony Edwards, COO, Eggplant
• Kris Lahiri, Co-Founder & VP Operations and Chief Security Officer, Egnyte
• Chris Michael, DevOps Engineer, FileCloud
• Tamas Cser, Founder & CEO, Functionize
• Justin Stone, Senior Director of Secure DevOps Platforms, Liberty Mutual
• Mark Levy, Director of Strategy, Software Delivery, Micro Focus
• Phaedra Divras, Chief Operating Officer, Mission
• Michael Morris, Senior Director of IT Cloud & DevOps Platforms, NetApp
• Tori Wieldt, Developer Advocate & Sr. Solutions Marketing Manager, New Relic
• Bob Davis, CMO, Plutora
• Veejay Jadhaw, CTO, Provenir
• Vishnu Nallani Chekravarthula, V.P. Head of Innovation, Qentelli
• Anurag Goel, Founder & CEO, Render
• Davy Hua, Director of DevOps, Security & ITOps, ShiftLeft
• Dave Karow, CD Evangelist, Split
• Ben Newton, Director of Product Marketing, Sumo Logic
• Adityashankar Kini, V.P. Engineering, Sysdig
• Neil Barton, CTO, WhereScape
• Dan Beauregard, DevOps Evangelist, Xebia Labs