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:
- 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.
- 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.
- 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.
- 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 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.
- 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.
- 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.
- 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.
- 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.
- 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: