--- layout: markdown_page title: "Section Direction - Ops" --- - TOC {:toc} ![Ops Overview](/images/direction/ops/ops-overview.png) *[Source](https://docs.google.com/presentation/d/1606LcicYP-QKMjHHzTEvZSrx5qkW9LpHiKQUWlggdEk/edit#slide=id.g82767e51d3_1_0)* ## Ops Section Overview
### Composition The Ops Section comprises the [Verify](/direction/ops/#verify), [Package](/direction/ops/#package),[Release](/direction/ops/#release),[Configure](/direction/configure) and [Monitor](/direction/monitor) [stages of the DevOps lifecycle](/stages-devops-lifecycle/). [Market analysts (internal - i)](https://drive.google.com/file/d/1B2KCSj_PF8ZhZqx_8Q6zFU2vldMu94lT/view) often describe these stages as automated software quality (ASQ, partially analgous to Verify, Package and Release) IT automation and configuration management (ITACM, analogous to Configure) and IT operations management (ITOM, partially analogous to Monitor). In some contexts, "ops" refers to operators. Operators were the counterparts to Developers represented in the original coining of the term [DevOps](https://en.wikipedia.org/wiki/DevOps). That definition highlighted the rift between the two groups and a need for collaboration. At Gitlab, we use "ops" to mean operations - any component of the software delivery value stream after a developer commits code. Our [developer first perspective](/handbook/product/#developer-first) means our use of the word ops is focused on enabling developers to configure tools and perform operations tasks **first**. We have ambitious plans to [support operators in the future](#medium-term-1-2-years). ### Market The [total addressable market (TAM) for **DevOps tools** targeting these stages was $3.2B in 2018 and is expected to grow to $7.6B by 2022 (18.8% CAGR) (i)](https://docs.google.com/spreadsheets/d/1LO57cmXHDjE4QRf6NscRilpYA1mlXHeLFwM_tWlzcwI/edit?ts=5ddb7489#gid=947614257). This is a deep value pool and represents a significant portion of GitLab's expanding addressable market as organizations further adopt DevOps and developer focused ops tools account for a larger share of a market which traditionally targets Architects, System Admin and Operator personas. The [market is well established (i)](https://drive.google.com/file/d/1VvnJ5Q5PJzPKZ_oYBHGNuc6D7mtMmIZ_/view) but the participants are evolving rapidly. Existing leaders in single stages of the DevOps lifecycle are expanding towards a complete DevOps delivery platform via acquisition and product development. These existing leaders run the gamut from GitHub with their strong position in the Create stage, to Splunk with their strong position in Monitor. All are pivoting to pursue an single DevOps platform strategy. Expanded market players such as GitHub are taking market share from traditional participants like CloudBees in the Verify stage. In the Package stage, JFrog is expanding their leadership position in artifact repositories into other stages of the DevOps lifecycle. In the Release stage Spinnaker is new open-source, fast growing entrant enabling collaborative CI/CD workflows and taking market share from traditional Application Release Orchestration vendors. Splunk, New Relic and Datadog are dominating market share in the Monitor stage and fiercely competing to be a central devops platform. IBM (+RedHat), Hashicorp, Puppet and Chef splitting a large chunk of the fragmented market in the Configure stage. ### Current Position Despite many strong players, GitLab's market share in the Ops section is strong, especially in the Verify, Package, Release and Configure stages. For the configure and monitor stages, our unique perspective as a single and complete devops application positions us for growth. Our customers utilize many [Ops Section stages](https://app.periscopedata.com/app/gitlab/462967/Configure-Metrics) today. Primarily they: * Have adopted CI best practices and are defining their CI/CD pipelines as code * Are adopting our Release stage features, along with new technology platforms to realize the benefits of CD and progressive delivery * Use Auto DevOps as a starting point to design modern DevOps workflows * Utilize GitLab's core features in Create and Verify to manage Infrastructure as Code * Value our cluster integration with Kubernetes * Are interested in bringing Incident Management processes into GitLab to encourage collaboration within their team * Are interested in bringing monitoring of cloud native applications into GitLab Our current R&D investment in Ops Section stages is [large](/company/team/?department=ops-section). The maturity of each stage and category can be found in our [maturity page](/direction/maturity/). Our investment in the Ops section is is critical to both enabling next steps in enterprise users continued DevOps maturity journey, and as we continue to create the first complete DevOps tool. Doing so enables [early adopters](/handbook/product/#prioritize-current-adopters) to recognize the [benefit of a single application](/handbook/product/#single-application). We would appreciate your feedback on this direction page. Please take [our survey](https://forms.gle/ex9zZ4sKmE1FKiHr9), [email Kenny Johnston](mailto:kenny@gitlab.com) or [propose an MR](https://gitlab.com/gitlab-com/www-gitlab-com/edit/master/source/direction/ops/template.html.md.erb) to this page! ## Challenges GitLab is competing in a new market of [value stream delivery platforms (i - Gartner)](https://drive.google.com/file/d/1QAuhdt9xE761ItGJM3Jx6I6TdMAhHYrj/view). We were an early entrant in this market [before it was defined](handbook/product/single-application/) but there are many, and will be more fast followers. Key players include large established tech firms (Microsoft) as well as newly consolidated platforms from aquisition (JFrog, CollabNet VersionOne/XebiaLabs). Beyond the key players, there is also rapid innovation in new technologies making for a market where there is both proliferation of new technology, and consolidation of the winning technologies into comprehensive platform players. Ease of deployment for CI/CD and operational tools has aided this expansion. Developers and operations teams can easily instrument and utilize new technologies alongside their existing software development pipelines with less risk, and in quicker time frames than under previous models where it required diligent planning and months of installation and configuration. Competing tools are marketed as stand-alone point solutions while GitLab's capabilities will shine when customers use other stages of GitLab. This can create a narrow funnel for adoption with potential users coming only from the segment of the market already using, or willing to use, other stages of GitLab rather than broad-based market fit. Without developing more landing spots for new users of GitLab, this smaller adoption funnel will affect our rate of learning. Few companies have been able to successfully bridge between Developer and Operator personas. Building tools that satisfy both sets of jobs-to-be-done is difficult. Without deeply understanding new personas and tasks, market entrants end up with a checklist of modules that don't represent a cohesive and improved experience for users. In recent years we've seen the emergence of large [public cloud infrastructure providers](https://en.wikipedia.org/wiki/Cloud_computing#Public_cloud) moving from a focus on infrastructure services for operators towards developer tools. These providers could challenge current notions of [multi-cloud](https://en.wikipedia.org/wiki/Multicloud) by creating great, integrated experiences in their tools for developers to create, verify, and deploy applications to the providers' infrastructure. Outside of market challenges we have some internal ones as well. In general, we are not [dogfooding](/handbook/values/#dogfooding) the Release, Monitor and Configure stage features sufficiently. This has the effect of [slowing our rate of learning](/handbook/values/#dogfooding), and putting us in the position of not having immediate real-world validation of our product initiatives. ## Opportunities Given these challenges, here are some key opportunities we must take advantage of: * **Market Recognition:** The IT market has recognized the value of GitLab's core proposition, a [complete DevOps platform delivered as a single application](/handbook/product/single-application/). We know because single-function companies [are consolidating](https://azure.microsoft.com/en-us/blog/accelerating-devops-with-github-and-azure/), and analysts are [creating new categories](https://www.gartner.com/en/documents/3979558/the-future-of-devops-toolchains-will-involve-maximizing-) to describe that proposition. * **Increasing Developer buying power:** In the move to DevOps, [tools focused on enabling developers will garner increased share of wallet](http://videos.cowen.com/detail/videos/recent/video/6040056480001?autoStart=true). [71% of organizations (i)](https://docs.google.com/presentation/d/1tt6-XqnhCmsx8Jfy39hit8OgggeaFUUxxU7TnNsG4Qk/edit#slide=id.p4) will achieve full DevOps adoption on some projects within a year. [35% of DevOps implementations include Monitor stage capabilities, 30% include Configure stage ones (i)](https://docs.google.com/presentation/d/1tt6-XqnhCmsx8Jfy39hit8OgggeaFUUxxU7TnNsG4Qk/edit#slide=id.p14). This increasing buyer power is driven by the cultural and organizational changes (often called Digital Transformation Initiatives) needed for DevOps to deliver software faster. * **IT operations skills gap:** DevOps transformations are hampered by a [lack of IT operations skills (i)](https://docs.google.com/presentation/d/1tt6-XqnhCmsx8Jfy39hit8OgggeaFUUxxU7TnNsG4Qk/edit#slide=id.p19). Most organizations have taken to creating [infrastructure platform teams](https://hackernoon.com/how-to-build-a-platform-team-now-the-secrets-to-successful-engineering-8a9b6a4d2c8) to [minimize the amount of operations expertise required by DevOps team members (i)](https://drive.google.com/file/d/1GexcUo4FzmhmV30tnjn7x3hyk1plEK4-/view). * **Clear winner in Kubernetes:** Driven by software-defined infrastructure, cost management, and resiliency, organizations [are flocking to cloud-native application architectures (i)](https://drive.google.com/file/d/1ZAqTIiSfpHKyVFpgMnJoOBnyCQ-aF3ej/view). Kubernetes is the clear winner in container orchestration platforms. Kubernetes enables easy portability of code, and CI/CD platforms built on containers (like GitLab CI/CD) are leading the market. Kubernetes also provides a reliable, [multi-cloud abstration point](https://www.infoworld.com/article/3439824/kubernetes-is-bringing-multicloud-20.html) which can blunt the challenge from [public cloud providers](https://en.wikipedia.org/wiki/Cloud_computing#Public_cloud). [Gartner recommends (i)](https://drive.google.com/file/d/19MZsKTc8tvAAFQEWuxDGoTW1f_kCZ6GI/view) organizations choose vendors that support open-source software projects in the cloud-native ecosystem ([CNCF](https://www.cncf.io/)). Organizations are reporting [high ROI when moving to cloud-native development platforms](https://content.pivotal.io/blog/the-economics-of-cloud-native-go-much-deeper-than-sticker-price), and analyst firms predict [35% of applications will be cloud-native by 2022 (i)](https://drive.google.com/file/d/1em_oqA5ciPDmTxHGCHgwbv4t-38uJjt1/view). * **IaC and GitOps are strong first steps towards AIOps:** AIOps strives to provide self-learning, self-healing IT operations massively impacting IT operations professionals and their tools. However, it is [early in the hype cycle (i)](https://drive.google.com/file/d/1GexcUo4FzmhmV30tnjn7x3hyk1plEK4-/view) and being successful will depend on DevOps teams first defining their infrastructure, operations, and observability as code. IT Operations teams are first adopting automation and programmable infrastructure in order to keep up with developer velocity. Experience with developer tools like source control and CI/CD tooling are becoming requirements for operations teams. GitLab's roots in SCM and CI and the entire GitOps, Infrastructure as Code, and Observability as Code movements will help set us up for future AIOps success. * **Continuing commoditization of tooling:** Well funded technology companies (Google, Netflix, Lyft, Spotify etc.), meeting scaling challenges, have a history of releasing open source software that leap-frog vendor software. Examples include Kubernetes, Prometheus, and many of the foundational projects in CNCF. DevOps vendors has to continue to move up the value chain as previously specialized software gets comoditized. ## 3 Year Strategy GitLab's Ops strategy follows that of [GitLab's company strategy](/company/strategy/). Just like our company [mission](/company/strategy/#mission), we will enable **everyone to contribute** not just via application code, but via other digital artifacts that increasingly define the performance, reliability, and resilience of the world's software. We will pursue that mission and capitalize on the opportunities (developer buyer power, IT skills gaps, a move towards Kubernetes, and our roots in source-control and CI) listed above by utilizing [dual-flywheel](/company/strategy/#dual-flywheels) approach. This approach starts with attracting developers performing devops tooling and operations tasks to our Core (FOSS). As we build killer tools for them we will utilize their feedback to drive community and product improvements. This will in turn generate revenue for higher product tiers and additional investment for supporting the platform and ops teams which support modern development teams. We'll do this by enabling easy-to-discover workflows that support doing powerful, complex actions with a minimum of manual configuration. We want to take advantage of our single application so that, while each team may have their own views or dashboards in the product that support their day to day, the information about what is deployed where is available everywhere and to everyone, embedded naturally into the product where it's relevant. For example, a person thinking about upcoming releases may interact mostly with an environment-based overview that helps them see upcoming changes and alerts as they flow through environments, but that same information exists everywhere it is relevant: * Testers looking at an individual issue can see which environment(s) that issue has been deployed to * Developers reviewing a merge request have the Review App at their fingertips * Feature flags link back to the issues and merge requests that introduced them for context, and provide views into the metrics needed to decide whether the feature was a success * Developers can effect infrastructure changes with the same workflow as code changes * Upcoming releases have burndown charts right in the overview * Incident responders can immediately see details of the last deploy, recent code changes and errors, traces and logs needed to help them get their service back up quickly * Evidence collection for auditors happens automatically throughout the pipeline, with nothing special to set up The end result is that even complex delivery flows become part of everyone's primary way of working. There isn't a context shift (or even worse, a switch into a different tool) needed to start thinking about delivery or operations - that information is there, in context, from your first commit. The centerpiece of this strategy is our [Get Things Done Easily theme](/direction/ops/#get-things-done-easily). ### Market Predictions In three years the Ops market will: * Provide seamless progressive delivery capabilities as a critical tool for enabling lean product-focused development * Consolidate around Kubernetes as the de facto multi-cloud abstraction layer which application delivery teams interact with to deploy and maintain software * Be clearly segmented between infrastructure platform delivery professionals and DevOps application delivery professionals * Have adapted DevOps processes to also include infrastructure and observability into CI/CD pipelines providing more responsive, more secure, and higher quality production applications ### GitLab Goals As a result, in three years, the Ops stages in Gitlab will: * Be the market leader in CI/CD tooling, including making it easy to migrate to GitLab CI/CD from other tools * Build the first complete progressive delivery solution * Be considered a critical tool for cloud-native development teams, and the infrastructure platform delivery teams which support them * Enable strong collaboration between application and platform teams * Provide easy adoption of IaC deployment patterns so DevOps teams have more insight and responsiveness to their application's production capabilities * Be recognized for the flows that connect jobs-to-be-done across the product delivery process from commitment to customer * Provide a best-in-class monitoring solution for observability use cases which competes with market leaders ## Themes Our direction for Ops is to enable today's modern best practices in operations without the burden of specialized teams, multiple tools, and heavy workflows that are the largest barriers to adoption in these stages of the DevOps lifecycle. Our goal is to empower DevOps teams to own their code in production and have the tools to contribute not just to application feature development, but to the characteristics of their applications as experienced by their end-users. <%= partial("direction/ops/themes/1-cool_things") %> <%= partial("direction/ops/themes/2-progressive_delivery") %> <%= partial("direction/ops/themes/3-multi_platform") %> <%= partial("direction/ops/themes/4-integrated_solutions") %> <%= partial("direction/ops/themes/5-speedy_pipelines") %> <%= partial("direction/ops/themes/6-compliance_as_code") %> <%= partial("direction/ops/themes/7-ops-as-code") %> <%= partial("direction/ops/themes/8-smart-feedback-loop") %> <%= partial("direction/ops/themes/9-ops-for-all") %> <%= partial("direction/ops/themes/10-no-ops") %> ## Who is it for? GitLab identifies who our Monitor and Configure stage features are built for utilizing the following categorization. We list our view of who we will support when in priority order. * 🟩- Targeted with strong support * 🟨- Targeted but incomplete support * ⬜️- Not targeted but might find value ### Today To capitalize on the [opportunities](#opportunities) listed above, the Ops section has features that make it useful to the following personas today. 1. 🟩 Developer / DevOps Engineer 1. 🟩 Cloud-Native Applications 1. 🟨 Container Platform Teams 1. 🟨 DevOps teams [deploying to legacy infrastructure](/direction/configure/infrastructure_as_code/) 1. ⬜️ Ops Teams 1. ⬜️ Central IT / System Admins ### Medium Term (1-2 years) As we execute our [3-year strategy](#3-year-strategy), our medium term (1-2 year) goal is to provide a single application that enables collaboration between cloud native development and platform teams. 1. 🟩 Developer / DevOps Engineer 1. 🟩 Cloud-Native Applications 1. 🟩 Container Platform Teams 1. 🟩 DevOps teams [deploying to legacy infrastructure](/direction/configure/infrastructure_as_code/) 1. 🟨 Ops Teams 1. ⬜️ Central IT / System Admins ### Critical Jobs to Be Done GitLab will focus on the [jobs to be done](/handbook/engineering/ux/ux-resources/#jobs-to-be-done) (JTBD) found in the workflows identified in the Configure and [Monitor](/direction/monitor/#workflows) stages. The most critical are: * Deploying [initial cloud-native infrastructure and CI/CD process](/direction/configure/#auto-devops) * [Creating centralized cloud-native platforms](/direction/configure/kubernetes_management/) for development teams * Managing [infrastructure change](/direction/configure/infrastructure_as_code/) * [Triaging](/direction/monitor/workflows/triage/) application performance and availability degradations * [Resolving](/direction/monitor/workflows/resolve/) application incidents ## One Year Plans ### Ops Section Plan In the next 12 months the Monitor and Configure stages **must** focus on: * **Dogfooding** - To immediately increase our rate of learning. * **Triage** - To provide support for a our highest priority monitoring [Job-To-Be-Done](#critical-jobs-to-be-done). * **Logging** - To build out a complete tool for operational tasks, we will improve our logging capabilities based on common open-source standards. * **Dashboarding** - Visualization is critical to both the [instrumentation](https://gitlab.com/groups/gitlab-org/-/epics/1945) and [triage](https://gitlab.com/groups/gitlab-org/-/epics/1947) workflows in application operations. Rich, single application dashboarding will be critical to the success of GitLab's Ops features. * **Incident Management** - To complete the feedback loop for our customers and provide a complete DevOps view to leaders, we will meet our users where they are in their DevOps journey. * **IaC** - To [skate where the puck is headed](/handbook/product/#why-cycle-time-is-important) we will improve the experience of using GitLab to source control your infrastructure and observability configuration. In doing so, over the next 12 months we will choose **NOT** to: * Invest in Verify stage features like: * [Tracking accessibility results over time](https://gitlab.com/gitlab-org/gitlab/issues/36171). * [Directly connecting the IDE to the Visual Review App](https://gitlab.com/gitlab-org/gitlab/issues/119127). * [Automatic flaky test minimization](https://gitlab.com/gitlab-org/gitlab/issues/3583). * Invest in z/OS supprt for GitLab Runner. * Invest in some specific Package stage features like: * [Dependency Firewall](/direction/package/dependency_firewall), as we'll focus on making the [Dependency Proxy](/direction/package/dependency_proxy) functional and complete. * Package manager formats and features that are not NPM, Maven, C++, .NET, Linux, Ruby, Python, PHP. * Invest in specific Release stage features like: * [Service Now Integration](https://gitlab.com/gitlab-org/gitlab/issues/8373) to control rollbacks or other pipeline actions is not in the cards. * Pages improvements such as the one to [improve experience around GitLab Pages forking vs. templates ](https://gitlab.com/gitlab-org/gitlab/issues/197172) will not be delivered in the next twelve months. * [Mobile Publishing](https://gitlab.com/dashboard/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=group%3A%3Arelease%20management&label_name[]=mobile%20publishing) will likely also not be leveled up, along with other mobile-focused features such as [feature-flags](https://gitlab.com/gitlab-org/gitlab/issues/24984 or [review apps specifically for mobile](https://gitlab.com/gitlab-org/gitlab/issues/199108). * Invest heavily in ease of use and experience for individuals attaching Kubernetes clusters to projects. While there are use cases for project-level attachment, it is a higher priority to provide Infrastructure Platform teams with an enhanced cloud-native management experience. * Invest heavily in enhanced out-of-the-box configuration of monitoring including auto-anomaly detection and synthetic monitoring - We need to focus first on dogfooding and the nitty-gritty of the three pillars of observability before moving to more advanced monitoring capabilities. * Invest in app instrumentation across a number of legacy programming languages - We will pursue a modern first approach, meaning we will not focus on easy instrumentation of apps written in legacy programming languages. * Invest heavily in automated cluster cost-optimization and chaos engineering efforts - We will pursue those as our adoption by platform teams increases. ### Acquisition Plan GitLab considers acquisitions as a key part of our investment in expanding the breadth of GitLab. The Monitor and Configure stages have a [higher appetite for acquisition](/handbook/acquisitions/#acquisition-target-profile). Over the next year, GitLab is interested in acquisitions that fill gaps in our current set of new and minimal categories in the [Configure](/direction/maturity/#configure) and [Monitor](https://about.gitlab.com/direction/maturity/#monitor) stages. There are also some other unnamed categories which fulfill our [themes](#themes) above that we would consider acquisitions in. Those include: Top priorities: 1. Observability - Tools that immediately increase our capabilities in tracing and digital experience management are a top priority. GitLab is immediately focused on improving the out-of-the-box experience for instrumenting and setting up triage workflows of users' applications. 1. Smart Feedback Loop - Tools that enable the continuous improvement of applications via efficient feedback loops from production to the Plan stage, including product telemetry, user forums, suggestion mechanisms, and real-user monitoring. This is our second priority because it is a critical part of the DevOps process, and GitLab has limited to no capabilities or planned categories today. Additional options: * Operations as Code - Tools and software that improve the ability to define observability systems and repeatedly deploy them alongside application code. * Operations for All - Tools that help developers quickly understand complex infrastructure setups, including service catalogs, cluster cost optimization, and observability interfaces. * NoOps - New low-code, no-ops languages and application paradigms including no-backend languages such as [dark-lang](https://darklang.com/). ## Useful Resources Below are some additional resources to learn more about Ops: * [The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations](https://www.amazon.com/dp/1942788002/) ## Stages and Categories The Ops section is composed of five stages, each of which contains several categories. Each stage has an overall strategy statement below, aligned to the themes for Ops. Each category within each stage has a dedicated vision page plus optional documentation, marketing pages, and other materials linked below. <%= partial("direction/ops/strategies/verify") %> <%= partial("direction/ops/strategies/package") %> <%= partial("direction/ops/strategies/release") %> <%= partial("direction/ops/strategies/configure") %> <%= partial("direction/ops/strategies/monitor") %> ## What's Next It's important to call out that the below plan can change any moment and should not be taken as a hard commitment, though we do try to keep things generally stable. In general, we follow the same [prioritization guidelines](/handbook/product/product-management/process/#prioritization) as the product team at large. Issues will tend to flow from having no milestone, to being added to the backlog, to being added to this page and/or a specific milestone for delivery. <%= direction["all"]["all"] %>