| Stage | Enablement |
| Maturity | Viable |
| Content Last Reviewed | 2020-03-06 |
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 Larissa Lane (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 throgh a video call, please email Larissa.
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.
The Cloud Native Installation is a newer deployment method for GitLab and it has come a long way since it was first launched. Almost all of the major features that are available in Omnibus GitLab are now available in the Cloud Native Installation, but it still doesn't support all of the features that are available in Omnibus GitLab. The two major features that are still missing are GitLab Pages and support for CAC cards. Pages is going through a redesign that includes adding support for object storage. As soon as this work is complete, we will prioritize adding support for Pages in the GitLab Helm chart. Adding support for CAC card authentication is expected to be unblocked in the near future when an issue with TLS authentication is resolved.
Previously, there had been occasional lags between the implementation of features within Omnibus GitLab and when they arrived in the Helm charts. We want to change this. In 2020, we will move towards releasing new features in Omnibus and Helm simultaneously. We know this won't always be possible because we sometimes get blocked by implementation decisions that are not supportable in Helm. However, we want our Helm users to have the latest and greatest GitLab features as soon as we can make it happen and we will continue addressing issues that cause a delay in adding them to the Helm chart.
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.
The cloud-native documentation today is comprehensive, but it could be better. We will be focusing on making it even clearer, more thorough, and rethinking the information architecture to ensure you can easily find what you need. Epic: https://gitlab.com/groups/gitlab-org/charts/-/epics/9
GitLab is a large and complex application. If you are new to Kubernetes, it currently may not be the first application you want to start with. However, we will continue focusing on ways to simplify cloud-native deployments of GitLab so that users with minimal Kubernetes experience can easily use this deployment method. Improvements to the documentation mentioned above will provide more advanced users with the resources they need to customize and optimize their cloud-native deployments.
There is a lot planned for 2020, but there's more that we would like to do. For now, we will be relying on contributions from other teams and the community to improve support for running GitLab on container platforms such as OpenShift.
This category is currently at the Viable maturity level. Our next maturity target is Complete (see our definitions of maturity levels). We are aiming to reach the Complete level by Q3 of 2020, after which we will push on towards the Lovable maturity level.
