The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
| Stage | Enablement |
| Maturity | Complete |
| Content Last Reviewed | 2022-02-02 |
Thanks for visiting this category strategy page for the Cloud Native Installation. This page belongs to the Distribution group of the Enablement stage and is maintained by Dilan Orrino (E-Mail).
Your ideas and feedback are important to us and play a major part in shaping the product direction. The best way to provide feedback on scheduled improvements is by commenting on issues in the deliverable issues board. To create a new feature request, create an issue in the Charts project.
We are always looking for opportunities to interview GitLab users and learn more about your experiences using the cloud-native install to deploy a self-managed instance of GitLab. If you would like to share your experience and provide feedback through a video call, please email Dilan.
The cloud-native installation is used for deploying GitLab as a Kubernetes application. In this deployment method, GitLab is broken down into a cloud-native application structure comprised of GitLab services and resources that are distributed across a set of containers.
The GitLab Helm charts are used to deploy and manage the containers in Kubernetes. Additionally, the GitLab Operator has been developed to further improve the experience of managing the cloud-native deployment of GitLab. The Operator provides greater control over upgrades and makes it possible to perform rolling upgrades.
Cloud-native applications offer a number of benefits over the more traditional monolithic applications. Perhaps the greatest benefit is the ability to automatically scale individual services within the application to meet usage demand. We have seen significant growth in organizations adopting Kubernetes and increased interest in deploying GitLab in Kubernetes.
GitLab is committed to staying ahead of the curve in new developments for deploying applications and managing the underlying infrastructure that they run on. We already have a strong cloud-native offering, but we know we can make it even better. Our goal is to offer a full-featured, cloud-native version of GitLab that can be reliably used at any scale, even beyond our 50,000-user reference architecture.
Similar to the Omnibus category, the Cloud Native Installation is for organizations or teams that prefer to run their own instance of GitLab rather than use the hosted gitlab.com offering. This install method is specifically for teams wanting to run GitLab in Kubernetes.
It is also for GitLab's own admin team that is responsible for managing gitlab.com. We are transitioning from using Omnibus to manage gitlab.com, to using the GitLab Helm charts and running parts of gitlab.com in Kubernetes. This allows us to more easily scale what is the world's largest instance of GitLab.
The user personas most likely to be working with the Cloud Native Installation are:
System Administrators and DevOps Engineers
System Administrators and DevOps Engineers are responsible for providing development teams with a fast and reliable development environment that responds well to spikes in usage. They may also be encouraged or mandated by their organization to move critical applications to cloud-native deployments as part of a modernization strategy. The level of Kubernetes experience tends to vary. We find that some teams have a lot of experience and are interested in advanced features that allow them to optimize their instance. Other teams are relatively new to Kubernetes and need the deployment experience to be easy and clear, with step-by-step guidance to get up and running.
Software Developer
On small development teams, it might be the role of the software developer to spin up their own instances of GitLab in Kubernetes. They want to be able to manage the instance with minimal effort so they can focus on their primary job of developing software. They use GitLab for their daily work and need it to respond well to spikes in usage with minimal impact on speed.
On large development teams that are running a large-scale deployment of GitLab, the developer needs clarity on what changed in the instance because there are more people involved in the management of the instance and they need to understand changes to the configuration. They may want more control over how GitLab is deployed so that it can meet their custom needs.
Some organizations want more control over the environment in which GitLab is deployed, and the way that it is configured and managed. To achieve this, they choose to deploy their own instance of GitLab rather than using gitlab.com. While this does provide more control, it also increases the burden in the following ways:
They take on the expense of providing and maintaining the hardware required to deploy GitLab, or pay somebody else to do that by running GitLab in a public cloud, for example. In large-scale, highly available deployments, this can require a large number of servers as outlined in the GitLab reference architectures.
They take on the responsibility of ensuring that the end users of GitLab are able to accomplish their tasks quickly, without disruptions caused by latency or downtime.
They become responsible for updating GitLab regularly so that end users have access to the latest features and improvements.
As organizations realize the benefits of deploying applications on Kubernetes there has been a surge in demand for being able to run applications in Kubernetes. In addition, some large organizations are mandating that applications be moved to Kubernetes as part of their corporate cloud strategy. In the 2019 Continuous Intelligence Report, Sumo Logic reported that 20% of AWS customers are using Kubernetes to orchestrate the deployment of their applications in AWS. This is from a survey of 2,000 companies and shows a 6% increase compared to 2018.
Kubernetes is still relatively new. Even though many companies are making the move to Kubernetes, there is still a shortage of knowledge and experience with deploying on Kubernetes, and teams are learning as they go. To add to this problem, GitLab is a large and complex application and deploying it on Kubernetes requires some amount of prior experience with Kubernetes.
Organizations want more flexibility about where they deploy. They don't want to be locked in to a single cloud provider because the underlying technology requires it.
Depending on the organization, some instances of GitLab may experience spikes in usage. The instance needs to scale quickly to handle these loads.
GitLab is a large and complex application. If you are new to Kubernetes, GitLab may not be a good first application to start with. However, we are continuing to focus on ways of simplifying GitLab cloud-native deployments so that users with minimal Kubernetes experience can easily use this deployment method.
Our goal is for cloud-native deployments to be similar in simplicity and configuration as our Omnibus package, and surpass our Omnibus package in day 2 automation. In 2023, we hope to be able to recommend our cloud-native installation on par with our Omnibus package for simple deployments and where it is cost effective, or recommend a hybrid architecture over a pure Omnibus installation due to the benefits cloud-native can offer. In 2023 we would also like to change to the Operator as the preferred installation method for Cloud Native GitLab. The Operator offers significant benefits to cloud-native installations and we would like to only need to maintain one method of cloud-native deployment. This will not change the general support of cloud-native distributions, and only amplify.
GitLab has developed reference architectures for different scales of deployments. These reference architectures provide recommendations for architectures supporting anywhere from 2,000 to 50,000 users. These were originally created for Omnibus-based deployments. We will be going through the same testing and validation to make specific recommendations for Helm-based deployments so that we can provide more guidance to our Helm users. Full cloud-native reference architectures summarizes well areas where we still need to work on, so that GitLab is fully production ready in Kubernetes at any reference architecture, without requiring a hybrid deployment for even the most complex configurations. This also highlights our intention to support the needs of the GitLab Environment Toolkit (GET) and collaborate to increase GET product features, such as bringing production ready environments to another cloud provider, GCP. It is important for us to support GET because GET will be the best and easiest way to deploy multi-node production instances of GitLab, and operate them with very high service levels. GET will include everything needed for deployment and operation of major cloud providers, and all required and optional dependencies, provisioned with Terraform and configured with Ansible. Check out the GET documentation to learn more.
The cloud-native documentation today is comprehensive, but could be improved by making it even clearer and more thorough by restructuring the information architecture to ensure it's easy find what you need. Improvements to the documentation will also provide more advanced users with needed resources to customize and optimize their cloud-native deployments. Epic
As we continue to mature the GitLab Operator, the operator will become the main method of deploying GitLab as a Kubernetes application versus the current method of utilizing the Helm chart. The Operator will move away from its dependency on Helm in the future and become the source of truth for Cloud-native deployments, with an option to deploy with a lightweight Helm chart. This is how many operators work.
The cloud-native installation will be benefitting from overall efficiency work the team is planning to work on in the next 3 milestones (15.9-15.11). We have identified these contributor experience issues and build efficiency issues.
Improving our contributor experience is very impactful for the Distribution team because we typically work on a large number of reviews and are asked to contribute to and complete a wide range of work items from customers and internal teams at GitLab. By improving our contributor experience we can reduce the amount of time we spend on reviews. Contributor experience might also mean another team at GitLab is completely enabled to do work, where in the past they may have been required to request assistance from Distribution team members.
In our efficiency work we hope to reduce the amount of maintence we need to do regularly, as well as, reduce the time it takes to build tests and implement features. Our efficiency work is focused on reducing the effort to maintain two distinct code bases, for Omnibus and Cloud-native GitLab. This will ideally reduce the time it takes to implement any issue, maintenance work or feature work.
This category is currently at the Complete maturity level. Our next maturity target is Lovable (see our definitions of maturity levels. We are aiming to reach the Lovable level by Q4 of 2022.