More teams across industries are evaluating and running proof of concept projects with new technologies. Many of these technologies directly impact the production environments of critical customer facing applications. Cloud native infrastructure like containers, Kubernetes, and serverless platforms enable rapid development and deployment of new applications. As these technologies have matured, large enterprises have begun shifting focus to Day-2 operations.
Day-2 operations is the pain that comes with continually improving not just your application, but the way in which you operate it in production environments. Day-2 operations include considerations that go far beyond the original speed of development problems a cloud-native tools help solve. To operationalize a given technology, enterprises need to understand how it will fit into their broader architecture. Leaders must consider both their technical and operational architecture. After all, all systems are made up of not only software but also people and processes.
Technology must solve all the requirements of a business, not just the technical ones. The installation, setup, and ongoing configuration adjustment of cloud-native infrastructure can no longer be a manual process. It must be repeatable and reliable. Teams need to establish plans for maintenance, upgrades, and most importantly future optimization. In large organizations, there's a need to provide education and process change to ensure teams are well equipped to provide the levels of availability and performance their business requires.
Many times new technology, open-source innovations, or the latest tools don't consider these Day-2 operations concerns. This is one of many reasons technology adoption lags in large enterprises, governments, or other risk-averse teams.
GitLab's product and company strategy lend themselves naturally to Day-2 support. GitLab's strength is in the enterprise, and our teams focus on enterprise-class as a key consideration while building GitLab.
In addition, several ways GitLab product principles directly benefit Day-2 operations tasks:
Here are some specific examples of how those principles translate into GitLab features.
GitLab's small primitives paired with convention over configuration are a powerful combination. They bring a best-of-both-worlds solution to DevOps:
A vital example of this would be our Auto DevOps offering. Auto DevOps allows a team to commit their code and have GitLab do the rest right out of the gate. GitLab automatically builds, tests, and checks for code quality. Then GitLab runs security checks including SAST, DAST, dependancy scanning, license compliance, and container scanning. Deployment is then automated through Helm and Tiller into the connected Kubernetes cluster. In this way, Auto DevOps allows developers to deploy code to a Kubernetes cluster without writing a single line of CI/CD configuration.
However, when team needs to "graduate" from the sensible defaults, Auto DevOps provides, you don't need to shift your CI/CD approach completely. For example, if your team wants to customize the Docker image created in the build process, simply adding a Dockerfile to the project. Auto DevOps recognizes that custom configuration and uses the Dockerfile for the build rather than buildpacks. Similarly, if the deploy to Kubernetes needs to be customized for production use there are a number of options. First, a simple change to the environment variables that Auto DevOps uses change impact how the deploy functions. Options like canary deploys, incremental rollouts, and staging environments are all customized in this way. Secondly, complete control over the Helm chart that GitLab uses is achievable through a custom Helm chart in the project.
As teams Day-2 operations needs require them to graduate even further, the final simple primitive of Auto DevOps allows for the ultimate in customization. The actual .gitlab-ci.yml file that GitLab uses to orchestrate all of Auto DevOps is exposed to the user, and teams can use that file as the basis for their entirely customized deployment. These building blocks allow organizations to gradually customize their CI, environments, and implementations over time.
GitLab's support for Day-2 doesn't just stop at Kubernetes. While Kubernetes may be a great solution for many teams, there are many workloads and organization that will continue to leverage different cloud and on-premise platforms for deployments for years to come. Many infrastructure providers focus on only one type of deployment or focus solely on Kubernetes as a hammer for every nail.
GitLab, however, takes a different agnostic approach to create a universal control plane for the entire DevOps lifecycle. By comparison to other control planes, GitLab:
All of these features allow users to adopt GitLab without worrying about GitLab driving them to one particular cloud vendor or compute platform.
GitLab understands and values the power of open source. Being based on open source, we are firm in our stewardship of our product as well as recognizing the best open source projects in their respective spaces.
GitLab Auto DevOps is another excellent example of this:
Many other features of Auto DevOps represent simple configuration-less wrappers of the best of breed open-source tools for those use cases. Where there aren't open-source tools, GitLab either creates open-source version or incorporated proprietary features.
Other examples include: