--- layout: markdown_page title: "Category Strategy - Cloud Native Installation" --- - TOC {:toc} ## Cloud Native Installation | --- | --- | | Stage | [Enablement](/direction/enablement/) | | Maturity | [Viable](/direction/maturity/) | | Content Last Reviewed | `2020-03-06` | ### Introduction and how you can help Thanks for visiting this category strategy page for the Cloud Native Installation. This page belongs to the [Distribution](/handbook/product/categories/#distribution-group) group of the Enablement stage and is maintained by Larissa Lane ([E-Mail](mailto:)). 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](https://gitlab.com/groups/gitlab-org/-/boards/1282058?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Deliverable&label_name[]=group%3A%3Adistribution). To create a new feature request, create an issue in the [Charts project](https://gitlab.com/gitlab-org/charts/gitlab). 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](mailto:). ### Overview 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](https://docs.gitlab.com/charts/installation/operator.html) 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. #### Target Audience Similar to [the Omnibus category](https://about.gitlab.com/direction/distribution/omnibus), 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. #### Challenges to address * 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](https://docs.gitlab.com/ee/administration/high_availability/#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. ### Where we are Headed 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](https://gitlab.com/groups/gitlab-org/-/epics/1316) 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](https://gitlab.com/gitlab-org/gitlab/issues/10526) 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](https://docs.gitlab.com/ee/administration/high_availability/#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. #### What's Next & Why * [Add support for Praefect](https://gitlab.com/groups/gitlab-org/-/epics/2728) so that our Helm users can implement high availability for Gitaly. Gitaly HA is a highly requested feature that we are excited to support. * Finish work on Helm 3 support. The GitLab Helm chart now works with Helm 3, but there are some new capabilities that were added with Helm 3. We will be adding support for those new features, as outlined in [the epic](https://gitlab.com/groups/gitlab-org/charts/-/epics/8). * Add support for [IAM roles](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/1832) and [KMS encryption keys](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/1843). These two capabilities are requests from our Helm users deploying on AWS and will greatly enhance the security configuration of GitLab for AWS customers. * [Address the requirements for moving Cloud Native GitLab to the next maturity level](https://gitlab.com/groups/gitlab-org/-/epics/2260). #### What is Not Planned Right Now 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. #### Maturity Plan This category is currently at the Viable maturity level. Our next maturity target is Complete (see our [definitions of maturity levels](https://about.gitlab.com/handbook/product/categories/maturity/#legend)). We are aiming to reach the Complete level by Q3 of 2020, after which we will push on towards the Lovable maturity level. - [Move the cloud native install from Viable to Complete](https://gitlab.com/groups/gitlab-org/-/epics/2260) - [What would make the cloud native installation lovable?](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/1658) ### Competitive Landscape * GitHub began moving their application to Kubernetes in 2016 to be able to scale more easily as traffic increased. It doesn't appear that the self-managed version of Github, GitHub Enterprise, has a version that can be deployed on Kubernetes. * Atlassian does have a Docker image for BitBucket Server but there doesn't seem to be an officially supported Helm chart to manage deploying on Kubernetes.