| Product Marketing | Technical Marketing |
|---|---|
| @supadhyaya | @csaavedra1 |
Modern applications are developed with rapid iteration and run at highly dynamic scale. In an organization with a mature DevOps culture code can be deployed to production hundreds of times per day. Applications can then run under highly dynamic loads from a few users to millions. Modern infrastructure needs to be elastic. Capacity that can be dynamically provisioned and de-provisioned is able to keep pace with load maintaining optimal performance and minimal cost. With the demands made on today's infrastructure it's becoming increasingly crucial manage infrastructure automation with a robust and cohesive methodology.
GitOps == IaC + MRs + CI/CD
GitOps is an operational framework that takes DevOps best practices used for application development such as version control, collaboration, compliance, and CI/CD, and applies them to infrastructure automation.
GitOps involves managing your IT infrastructure using practices well-known in software development such as version control, code review, and CI/CD pipelines. For example, infrastructure teams that practice GitOps use configuration files stored as code. Similar to how application source code generates the same application binaries every time it's built, GitOps configuration generates the same infrastructure environment every time it is deployed.
As with any emerging technology term, "GitOps" isn't strictly defined the same way by everyone across the industry. GitOps emerged in the cloud native community and some definitions restrict GitOps to say "Kubernetes is required to be doing GitOps." GitLab takes a broader approach. We've seen GitLab users and customers applying GitOps principals to all types of infrastructure automation including VMs and containers, as well as Kubernetes clusters.
While many tools and methodologies promise faster deployment and seamless management between code and infrastructure, GitOps differs by focusing on a developer-centric experience. Infrastructure management through GitOps happens in the same version control system as the application development, enabling teams to collaborate more in a central location while benefiting from all the built-in features of Git.
GitOps is a prescriptive workflow for using Infrastructure as Code. GitOps with GitLab helps you manage physical, virtual and cloud native infrastructures (including Kubernetes and serverless technologies) using tight integration with industry-leading infrastructure automation tools like Terraform, AWS Cloud Formation, Ansible, Chef, Puppet, and the like.
As with any emerging technologies, there are different approaches to GitOps, each with their own pros and cons.
Push or Agentless GitOps In this approach, your CI/CD tool pushes the changes to your environment. This approach is consistent with the approach used for application deployment. Pro
Pull or Agent Bsed GitOps In this approach, an agent is installed in your cluster to pull changes whenever there is a drift from the desired configuration. Pro
Infrastructure as Code requires understanding of the platform and the desired state of the application environment. Users of Infrastructure as Code have a good understanding of both Git as a SCM tool as well as the platform they are expected to provision and manage. Below are a few power users Infrastructure as Code:
Sam, the SRE Sam works embedded into a service team with feature developers. They works on keeping the service up, deploying it, and managing the infrastructure needs of that service. They collaborate with the Platform team to systamatize best practices.
Devon, the DevOps Engineer Devon is often the Ops interface for the development team. He provides support for infrastructure, environments and integrations. Devon is fairly conversant with code and would prefer administering infrastructure via code rather than a multitude of different tools and context switches.
Priyanka, the Platform Operator Infrastructure management is one of the main responsibilities of the platform team. Priyanka is responsible for providing, maintaining, and operating a shared platform - either traditional or modern cloud platform - which the development teams utilize to ship and operate software more quickly.
Sydney, the System Administrator Sydney defines, maintains and scales the infrastructure and configuration for the application teams. She often receives repetitive requests on the same task. Sydney's primary motivation is to automate repetitive tasks to minimize errors and save time as well as define the infrastructure and configuration in a way that changes are tracked and to stop infrastructure changes becoming the wild west.
Buyers of Infrastructure as Code are usually leaders who lead infrastructure / automation initiatives. Typical buyer personas are:
List key analyst coverage of this usecase
Below are the market requirements for GitOps
Other features - Quickly create new branches of a project - Add new files/assets - Collaborate on proposed changes (review comments, suggest changes, WebIDE, suggestion approvals, conflict resolution, merge, diffing, hand-offs) - Workflow automation - Wiki snippets - Version-controlled snippets - Automatically update or close related issue(s) when a merge request is merged - Configurable issue closing pattern - Display merge request status for builds in CI system - Terraform plan output - Visibility into security scans and build stats
A collection of short demonstrations that show GitLab's GitOps capabilities.
| Market Requirements | How GitLab Delivers | GitLab Stage/Category | Demos |
|---|---|---|---|
| Foster Collaboration | Discussions, user tagging, general comments, inline comments, inline suggestions, unresolved thread tracking, issue creation from comment, suggestion management, CODEOWNERS, approvals | Discussions, CODEOWNERS, MR approvals |  Foster Collaboration with GitOps |
| Compliance and Auditing | Compliance testing and audit controls are built into GitLab's CI/CD pipelines. | Compliance at GitLab Manage Stage: Audit Events, Audit Logs, Audit Reports, Compliance Management, Release Evidence, Chain of Custody, Granular user roles and permissions, segregation of duties Secure Stage: License Compliance, Dependency Scanning CODEOWNERS, MR approvals, |
|
| Version controlled environments | Using GitLab version control to store XaC (Infrastructure, policy, configuration etc) helps maintain track of changes. In addition, auto rollback in case of failure helps roll back to the previous successful deployment | Environment Rollback, GitLab Agent for Kubernetes | |
| Test Automation | Include usability, performance testing as a part of the pipeline and roll back to a successful deployment in case of issues | Release versioning, support advanced deployment strategies such as canary, incremental roll out, blue green deployments, Feature Flags, Review Apps, Performance testing & validation | |
| Pipeline configuration Management | GitLab Pipeline Authoring allows users to create pipelines with minimal configuration, if required, and also create and visualize complex pipelines through Directed Acyclic Graphs. This helps infrastructure engineers minimize manual work and create repeatable processes to maximize productivity | Pipeline configuration, Types of Pipeline congigurations, Directed Acyclic Graphs |
| Differentiator | Value | Proof Point |
|---|---|---|
| Choice of Agent-based and Agentless approach | Customers have a choice to pick the right approach for their environments. With an Agentless approach, users can have GitLab manage and orchestrate GitOps processes for K8s and non-K8s platforms without having to install and maintain agents at every destination infrastructure component leading to the consumption of less resources, and cost savings. With an Agent-based approach, users, with secured infrastructure components that sit behind a firewall, can leverage the GitLab Agent to keep their secured infrastructure up-to-date mitigating the risk of security breaches and unexpected downtimes. | TBD |
| On-premise & cloud - physical, virtual, cloud native infrastructures | GitLab meets customers where they are. Most competitors support GitOps for cloud native infrastructure only, GitLab supports GitOps for your on-prem or cloud deployments - whether it is physical servers, virtual servers or cloud native infrastructures. You don't need to purchase and maintain different GitOps solutions for your different kinds of infrastructure leading to cost savings and a consistent user experience for doing GitOps across your organization. | TBD |
| Single application to foster collaboration across Infrastructure, Development and Operations team | GitLab is a single application with most of the necessary ingredients for GitOps - version control, CI/CD and container registry & out-of-the-box integration for configuration management, orchestration & infrastructure provisioning. Most competitive solutions require 5-6 integrations to achieve the same. Consolidating into GitLab for all your GitOps leads to cost savings and its consistent user experience and integrated capabilities can help increase productivity and higher environment stability and reliability. | TBD |
The message house for the use case provides a structure to describe and discuss the value and differentiators for the use case.
Current messaging can be found in the market viewpoint section for this page and on the topic page which answers What is GitOps? along with some additional notes here:
"Infrastructure Platform" is a great phrase to use in connection with GitOps and GitLab. We need to be careful with its use so we don't portray ourselves as something we aren't. In the past we've been called out for claiming to have capabilities similar to Chef, Ansible, and Terraform, when we don't house the capabilities within GitLab, but instead seek to integrate with those tools. If we keep it clear that we provide infra platform capabilities via integrations then we have some strong messaging that connects with I&O buyers. See an example use on the topic page
| Objection | Response |
|---|---|
| Our environment is too complex for GitOps | Large changes are always complex. But you can consider doing this iteratively - starting from your simplest test environment. GitLab also has a strong professional services team that can help you get started with your GitOps journey. |
| GitOps gives more access to developers to fiddle with the deployments, and infrastructure teams are not comfortable with that | GitOps empowers developers to work collaboratively with Infrastructure teams. GitOps with GitLab includes enough controls through merge request approvals, audit reports, compliance dashboards - that your infrastructure teams can use to ensure they are able to monitor what goes into production. |
| (Infra / DevOps Engineer) I'm going to loose control over my work and environment | GitOps empowers developers to work collaboratively with Infrastructure teams. GitOps with GitLab includes enough controls through merge request approvals, audit reports, compliance dashboards - that your infrastructure teams can use to ensure they are able to monitor what goes into production. |
| I don't use Kubernetes, so GitOps is not relevant for me | GitOps with GitLab will meet you where you are - we support deployments to physical, virtual and cloud native environments - whether on-premise or on cloud. |
| I am not comfortable with a push-based / agentless approach that expects me to open up my firewall or give cluster access to GitLab CI/CD. | We recently announced a GitLab Agent for Kubernetes that would allow secure communication between the Kubernetes cluster and GitLab CI/CD using an agent-based approach. This would not require customers to open up their firewall or give cluster access to GitLab CI/CD. We support both options currently - and you can choose the approach that best suits your specific needs. |
ArgoCD is an Open Source Solution for GitOps deployments for Kubernetes. It was started by Intuit and is now a CNCF incubation project. It is part of the Argo Project family of products.
ArgoCD is competes directly with the GitLab Agent for Kubernetes.
ArgoCD works together with GitLab. It can supplement the build and secure steps run in GitLab CI/CD.
| Differentiator | How competitor does it | How GitLab does it differently |
|---|---|---|
| Multiple products to achieve GitOps | ArgoCD focuses exclusively on the deployment part. There are other Argo projects for feature flags and advanced deployments strategy support. | GitLab provides all the required tooling integrated in a single platform |
| Multiple deployment targets | Focused on cloud native deployments only | Can deploy to On-premise & cloud, physical, virtual, cloud native infrastructures |
| Push & Pull based deployment Automation | ArgoCD watches for new images and updates services in the K8S cluster according to policies chosen by the customer. Does not support push based deployment. | The GitLab Agent for Kubernetes watches for new K8S manifests and updates the K8S cluster accordingly. |
| Use GitOps principles to install and manage self | ArgoCD can bootstrap itself | The GitLab Agent can set up to manage itself |
| Synchronize state when deployment is rolled back | As a rollback is a new git commit or revert, this happens by design | As a rollback is a new git commit or revert, this happens by design when using the GitLab Agent |
Flux is an Open Source Solution for continuous and progressive delivery for Kubernetes. Flux was started at Weaveworks and is now a CNCF incubation project. It is part of the WeaveWorks Cloud solution for GitOps.
The WeaveWorks Cloud solution also works together with GitLab - with GitLab SCM and CI working with Flux CD to create a GitOps solution.
| Differentiator | How competitor does it | How GitLab does it differently |
|---|---|---|
| Multiple products to achieve GitOps | The Weaveworks toolchain is GitHub for version control, CircleCI for CI , Quay.io for container registry, Weave Flux for CD in addition to other tools for configuration management, infrastructure provisioning and container orchestration Source. Customers can choose any other Git, CI, container registry of their choice as well | Customers have at least 3 fewer tools to manage. Version control, CI/CD and container registry is offered by GitLab while we integrate with other tools for configuration management, infrastructure provisioning and container orchestration similar to Weaveworks. |
| Multiple deployment targets | Focused on cloud native deployments only | Can deploy to On-premise & cloud, physical, virtual, cloud native infrastructures |
| Push & Pull based deployment Automation | Flux watches for new images and updates services in the K8S cluster according to policies chosen by the customer. Does not support push based deployment. | The GitLab Agent for Kubernetes watches for new K8S manifests and updates the K8S cluster accordingly. Available on self managed and on invite only for SaaS. Currently - push based deployment is supported without agent. Roadmap includes push based deployment support as well using the agent. |
| Use GitOps principles to install and manage self | Flux v2 can create a git repo, manage flux manifests and updates using GitOps principles | TBD? |
| Synchronize state when deployment is rolled back | TBD? | TBD? |
For a list of analysts with a current understanding of GitLab's capabilities for this use case, please reach out to Analyst Relations via Slack (#analyst-relations) or by submitting an issue and selecting the "AR-Analyst-Validation" template.
This table shows the recommended use cases to adopt, links to product documentation, the respective subscription tier for the use case, and product analytics metrics.
| Feature / Use Case | Free | Premium | Ultimate | Product Analytics | Notes |
|---|---|---|---|---|---|
| Try the GitLab Agent for Kubernetes | ✓ | ✓ | ✓ | counts.kubernetes_agents_with_token |
|
| Migrate from custom CI solution | ✓ | ✓ | ✓ | redis_hll_counters.kubernetes_agent.agent_users_using_ci_tunnel_monthly |
|
| Use push based deployments | ⤬ | ✓ | ✓ | redis_hll_counters.kubernetes_agent.agent_users_using_ci_tunnel_monthly |
|
| Advanced permissions management for CI connection | ⤬ | ✓ | ✓ | redis_hll_counters.kubernetes_agent.agent_users_using_ci_tunnel_monthly |
|
| Use pull-based deployments | ✓ | ✓ | ✓ | WIP |
"Very efficient tool for managing releases and versions. We have a development and deployment process, and at all stages [GitLab] is involved. In addition to storing development code, we also store all packaging and deploy scripts in git"
- Full-stack Developer, Gartner Peer Insights Review
"Finally, the most amazing thing about GitLab is how well integrated the GitLab ecosystem is. It covers almost every step of development nicely, from the VCS, to CI, and deployment."
- Software Engineer, Gartner Peer Insights Review
"GitLab is the most preferred service in the world and its user community is very wide. We can authorize project or branch based user authorization on GitLab. In addition, continuous deployment integrations can be done very quickly. In addition, you can create merge requests within the constraints you want and easily manage them. It is very easy to prevent conflicts. A service that must be used for software development teams."
- Software Development Lead, Gartner Peer Insights Review
GitLab is not a replacement for existing Infrastructure Automation tools, but rather complements them to provide a comprehensive solution. As per the JetBrains DevOps Ecosystem 2019 survey, Terraform is the most popular infrastructure provisioning tool used by customers. Terraform is cloud-agnostic and helps manage complex infrastructures for distributed applications. GitLab will focus on Terraform support as the first step towards building a comprehensive GitOps solution.
Inventory of key pages in the buyer's Journey
| Awareness learning about the problem |
Consideration looking for solution ideas |
Decision is this the right solution |
|---|---|---|
| topic page? | solution page | proof points |
| landing pages? | ?comparisons? | comparisons |
| -etc? | - product page x - product page y - product page z |