3 DevOps Trends to Watch in 2020
At Redpoint, we live and breathe cloud infrastructure, DevOps, and developer tools. Over the past few years we’ve invested in ~20 such companies and deployed ~$350M in capital. We’re long-time believers in the DevOps and microservices movements, which aren’t slowing down. According to IDC, the DevOps software market achieved $5B in 2018 and is forecast to reach $15B in 2023, a 24% CAGR over the period.
Passionate about the category, I’m constantly trying to analyze and evaluate what’s coming next (past work here and here). My research seeks to unearth seminal insights to facilitate a conversation and to move the field forward. Below are our thoughts on three key 2020 DevOps trends: 1) modern technical project management; 2) alerting; and 3) Security-as-Code (SaC).
1. Modern Technical Project Management
Software continues to have a world-wide impact. There are now 23M software developers and 100M+ technical team members world-wide, according to Atlassian. Technical project management tools that were sufficient in the past are no longer good enough.
The technical project management market is at a tipping point. Not only is the category incredibly large at $35B, according to Atlassian, but it is dominated by Atlassian’s own product, Jira, that is ripe for disruption. While Jira is a market leader it is also a dated product. Created in 2002, Jira was originally built for an on-prem deployment. Our research suggests it is generally disliked because it’s difficult to use and maintain. User conversations suggest that Jira is often slow, worsening developer productivity. While we hear users call it “infinitely customizable,” this functionality is both a blessing and a curse. Generally, Jira requires a full-time administrator to manage.
Jira is still transitioning customers from its on-premise offering to a SaaS version, giving new solutions a window of opportunity to be evaluated. We’ve heard the cloud version is still slow and cumbersome.
Atlassian itself is known for its low-touch, capital-efficient, bottoms up sales motion. The company helped define this GTM motion. However, as developers become dissatisfied with Jira, they will continue to Bring Your Own Tool (BYOT), which may be a new vendor. Developers are more empowered than ever to choose the solutions they want to be productive and happy. With additional new workforce dynamics including remote work, freelance, networked organizations, and the millennial influx, there is a need for a modern solution that helps teams collaboratively build world class software.
Saliently, we hear teams stick with Atlassian because of its wide product suite. Atlassian notes that after six years of buying Jira, the average number of Atlassian products purchased is close to three. The company underscores that its large Jira customer base is an important durable growth lever. It won’t be easy for a new issue tracking solution to displace Jira, but there is an opportunity. In 2018, 65K of 138K (47%) of Atlassian customers were Jira-only.
Below we catalog ~20 project management companies and distinguish between technical project management and business project management. We include both categories because we often hear start-ups and SMBs using these solutions interchangeably. It is clear teams want something new exemplified by Clubhouse’s recent funding announcement, Asana’s confidential S-1 filing for a direct listing, and Monday.com’s recent valuation at $1.9B. There are additional early stage startups including Zepel, Linear, Cycle.app, Height, among others. We believe there’s an opportunity for an outstanding solution to emerge.
2. Alerting
We appreciate that complex infrastructure and legacy processes increase risk, which makes modern incident response solutions, both preventative (Gremlin) and post-incident (alerting), necessary (more work here). Businesses lose up to $500K of revenue for every minute of downtime, so an intelligent, efficient, and fast alerting system is critical for decreasing mean time to resolution.
Alerting solutions inform employees of issues and orchestrate teams to resolve immediate problems (on-call management/scheduling). Alerting mitigates business disruption to reduce downtime and improve SLA performance. It can also increase revenue and improve customer experience, boost people productivity and engagement, and improve cost efficiency.
The alerting category experienced lots of activity over the past few years. There has been consolidation. In 2018 Splunk acquired VictorOps for ~$120M and Atlassian acquired Opsgenie for $295M. One business went public. Last summer, PagerDuty raised $218M in its public offering. We wrote about PagerDuty’s IPO here.
The market is large. According to PagerDuty, its market opportunity is around $25B. The company calculated the TAM by multiplying its estimate of 85M potential users by its average revenue per user of ~$294 for the fiscal year ended January 31, 2019.
Despite the numerous offerings, we hear there is room for improvement. Users complain that PagerDuty’s UI is kludgy, and search can be challenging. Additionally, while some offerings claim to be “smart,” users gripe about alert fatigue and unintelligent call scheduling. A new solution will do a better job of correlating events to generate a single alert versus multiple.
Like technical project management solutions, alerting’s GTM motion is a land and expand model. Prospective users can easily use a free trial and then opt into the self-serve solution. While PagerDuty layered on high-velocity inside sales for SMB/mid-market customers with field sales for enterprise customers, BYOT still creates an opportunity for a new entrant. We’ve also heard prices have started increasing and may not match the value customers receive.
Alerting is a key piece of infrastructure for most engineering and DevOps teams. A new vendor will need to be highly resilient, appropriately priced, and 10X better to displace the incumbents.
3. Security-as-Code
Infrastructure-as-Code has been around for a few years and “is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools.” Defined another way, infrastructure as code means teams manage infrastructure using configuration files. Redpoint portfolio company HashiCorp embodies this practice.
Recently we’ve seen the application of infrastructure as code to security, Security-as-Code (SaC). According to O’Reilly, “Security-as-Code is about building security into DevOps tools and practices, making it an essential part of the tool chains and workflows.” It entails adding security checks, tests, and gateways to the software development process by tying into CI/CD. Security-as-Code integrates security into product development and involves developers in the process.
Adopting Security-as-Code means security is defined and codified for any cloud application at the beginning of a project and is kept in a source code repository. Now security is codified, versioned, and automated. Teams should be able to evaluate security policies for any application at any stage and environment. DevOps teams can confidently reuse and recycle security policies and assets between environments. Shifting from scripted policies to code increases the assurance in any security review and simplifies the process required by any auditor to verify the compliance posture.
Security-as-Code helps automate previously manual processes. Security teams can remove the human from many processes increasing productivity, speed to delivery, and improving consistent implementation of security controls and policies.
The exhibit below highlights how Security-as-Code is embedded in software production. Security testing is automatically triggered as soon as code check-in happens for both application and infrastructure changes. There should be application-level security through CI/CD integration of Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), vulnerability testing, pen testing, and bug bounties. Security policies also need to be automatically tested for violations.
Security-as-Code best practices include building standardized security patterns to allow easy reuse. Using standardized security templates written in code will result in out-of-the-box security. Individual teams no longer need to define the policies and automation. This best practice helps bake-in security beforehand rather bolting it on afterwards.
We are starting to see the emergence of open-source policy as code frameworks like Open Policy Agent (OPA) and Chef InSpec. Companies are building policy as code into their infrastructure management products, like HashiCorp’s Sentinel framework and Kubernetes Network Policies. While not as prominent as Infrastructure-as-Code, Security-as-Code will be transformative for organizations.
Over the next year we’ll be watching the evolution of 1) modern technical project management; 2) alerting; and 3) Security-as-Code (SaC). If you or someone you know is working on a cloud infrastructure, DevOps, or developer tools project or start-up it would be great to hear from you. What trends are you seeing? Comment below or email me at amyers@redpoint.com to let us know.
