This handbook section defines the latest iteration of infrastructure standards for AWS and GCP across all departments and groups at GitLab. These standards were created by a cross-department collaboration in this Compute Sandbox Issue 3 (Budget and Cost Allocation) issue and Infrastructure Epic 257 (Provide cloud resources for non-production usage).
Each realm owner, department, or infrastructure community member can adopt these standards as they iterate their infrastructure.
#wg_infrastructure-standards Slack channel for architectural questions with the realm owners or #compute-sandbox for non-production infrastructure needs.For cloud infrastructure, we have created top-level AWS organizational units and GCP folders under the respective cloud provider master account that we refer to as "realms".
You can think of each realm as a domain or namespace that provides flexibility for department(s) and group(s) that use that realm to customize their infrastructure configuration and security policies as needed without affecting other departments or realms at GitLab.
Our realms are designed based on which department is the DRI (realm owner) and purposefully reducing the blast radius and security vulnerability based on the infrastructure resources that are deployed in each realm. You can find our pre-defined mapping of realms and department groups in the Department Group Collaboration Environments section below.
Are you looking to deploy a production or production-like service? All engineering or product related production infrastructure should be deployed and managed in the saas realm that is managed by the Engineering Infrastructure team with SRE on-call coverage. All business (non-engineering) production infrastructure should be deployed in the business-ops realm in the GCP project or AWS account specified by the security team.
What is defined as non-production?
Are you looking for an AWS account or GCP project to deploy resources in that you will share with your team? We have created a GCP project for each department group in the GitLab infrastructure community to allow each group to collaborate efficiently and provision the infrastructure that you need for shared purposes.
Are you an engineer looking for a sandbox or testing AWS account or GCP project? Please use the Compute Sandbox which gives you access to your own private AWS account or GCP project that grants you owner permissions and has centrally managed billing with the GitLab master account.
| Value | Human Friendy Name | Description |
|---|---|---|
saas |
GitLab SaaS | This is for GitLab.com SaaS that is managed by Engineering Infrastructure and Site Reliability Engineers. |
gitter |
Gitter SaaS | This is for Gitter hosted services. |
sandbox |
Compute Sandbox Cloud | This is for sandbox and ephemeral testing resources that provides an account/project for each user that are self-administered by each team member. |
Approximately ~750 of the ~1,300 GitLab team members are in departments that use cloud infrastructure for development, experiment, testing or non-production purposes. For documentation purposes, we refer to this as the GitLab infrastructure community.
For any groups that are not part of the GitLab infrastructure community, please reach out to Business Operations for assistance with having your infrastructure created in the business-ops realm.
You can find the full list departments, stages, and groups on the labels and tags handbook page. You can learn more about each department in the organization chart. You can learn more about the engineering stages and groups on the product categories handbook page.
| Realm | Usage | Departments/Groups |
|---|---|---|
business-opsBusiness Operations and IT Realm Docs |
This is for resources managed by the Business Operations and IT team, including all departments and groups that do not have their own realm. |
ga-accounting-xga-business-ops-xga-ceo-xga-finance-xga-legal-xga-people-xga-recruiting-xmktg-xsales-alliances-xsales-channel-xsales-commercial-xsales-ent-xsales-field-ops-xsales-practice-mgmt-x |
eng-devEngineering Development Realm Docs |
This is for additional services managed by Engineering Development (including `eng-ux` and `product` department resources) that don't belong in `saas`, `eng-infra`, or `sandbox` realms. |
eng-dev-manage-xeng-dev-plan-xeng-dev-create-xeng-dev-verify-xeng-dev-package-xeng-dev-release-xeng-dev-configure-xeng-dev-monitor-xeng-dev-secure-xeng-dev-protect-xeng-dev-growth-xeng-dev-enablement-xeng-quality-xeng-ux-xproduct-mgmt-x |
eng-infraEngineering Infrastructure Realm Docs |
This is for additional services managed by Engineering Infrastructure and Site Reliability Engineers that may not be specific to GitLab.com SaaS (Ex. tools, release and package management services, etc). |
eng-infra-x |
eng-securityEngineering Security Realm Docs |
This is for resources managed by the Security team. |
eng-security-x |
eng-supportEngineering Customer Support Realm Docs |
This is for resources managed by the Customer Support team. |
eng-support-x |
sales-csCustomer Success Realm Docs |
This is for resources managed by the Customer Success team, including demo and training systems. |
sales-cs-demo-cloud-xsales-cs-training-cloudsales-cs-sa-xsales-cs-tam-xsales-cs-ps-x |
Want to add a realm? Any departments without their own realm should have resources for their groups (teams) created in the business-ops realm. If there are enough cloud resources and a dedicated infrastructure engineer team member to justify creating a new realm, please see the instructions for creating a new infrastructure realm.
dev-resources and support-resources
dev-resources and support-resources Terraform projects that are used by the engineering development and support teams. There is no deprecation timeline or migration plan yet.
In the spirit of iteration and efficiency, we're working on standardizing how we create and manage ephemeral (sandbox) infrastructure that GitLab team members provision.
The oversimplified user story is "I need to spin up VM(s) or cluster(s) in GCP or AWS to try something (anything, may not be GitLab product specific), what's the company infrastructure standards for doing that?"
The Sandbox Cloud is a custom-built web application that automates the provisioning of an AWS account or GCP project for each GitLab team member that needs one for ephemeral sandbox and testing use cases.
The goal is to create a frictionless approach for technical team members that includes the tagging needed for cost allocation, best practice security configurations, and provide you the ability to create any resources that you need using the AWS or GCP web console or use our shared library of Terraform modules that include documentation and usage examples that can be copied into the Terraform configuration file for each user account. When you sign in with OKTA, we use the OKTA meta data that is integrated with BambooHR to determine your department and entity for cost reporting, and use this for the auto-creation of a tagging policy for resources that you create.
Learn more on the sandbox realm handbook page.
Each realm has one or more team members that are system owners that are the DRI or stable counterparts responsible for all of the infrastructure architecture, billing, resource provisioning and security policies in that realm.
Each realm DRI or counterpart is an engineering manager or experienced infrastructure engineer who can perform all actions needed for day-to-day management of the realm, including responding to security incidents and supporting group owners and counterparts in their realm.
Each of the GitLab department groups that have a GCP project within a realm have a Group DRI and counterparts that provide day-to-day support for users in their realm and escalate to realm DRIs or counterparts as needed.
Our infrastructure standards are designed to provide a well defined baseline with guidelines for customization by realm owners as needed within their realm.
The AWS architecture is currently being designed. Please create a GitLab issue and tag jeffersonmartin, dawsmith, and pharrison for assistance in the interim.
