Core Infra team vision discussion

@dawsmith and I were discussing ideas for clarifying, expanding, and updating our [team vision](https://about.gitlab.com/handbook/engineering/infrastructure/team/reliability/core-infra/#vision), and I wanted to kickstart a discussion amongst the team to make sure we incorporate all perspectives with any changes we make.

Here's one section from my notes:
> I’ve struggled for a long time trying to figure out what our team should be, what our vision is, and where our north star lies. This statement: “Continue delivering tangible value for both GitLab.com, but indirectly our self-managed customers who run at a larger scale. It has been mentioned too many times, but every improvement we make at scale for .com is a challenge our self-managed customers won't have to deal with.” resonated strongly with me. The areas that core infra owns include many areas we take for granted, a bit. Rarely do we have clear ways to incorporate a link back to our self-hosted customers, outside of the occasional sales call where we answer questions about how we manage .com. Incorporating more focus on reusability for self-hosted GitLab admins would significantly help us to answer those questions, clarify priorities, and provide impetus to improve the quality of our work products.
> - Chef (and next, Ansible), with all the related cookbooks/playbooks, pipelines, testing, and deployment
> - Standardize around publicly available/distributed terraform modules, helper scripts, pipeline definitions, etc.
> - Frontend traffic management, allow/blocklists, WAF, etc.
> - Kubernetes cluster monitoring and management

In addition to ensuring we focus more on repeatability and reusability in our code artifacts, one common theme I keep coming back to in my 1:1 discussions with @dawsmith centers around shifting our mindset to think about services and platforms instead of (just) tools and technologies. So instead of attacking the problem of managing infrastructure by thinking about terraform code updates and custom scripts, I'd like to think through some standard use-cases and abstract those implementation details a bit. We can still leverage the best technology for a given purpose on the backend, but we can more effectively enable self-service for other teams within GitLab by codifying what it means to deploy infrastructure _in our environment_ with a narrower, more focused abstractions.

The idea is to enable scalability and SaaS platform maturity by distilling down complex codebases and diverse technologies into simpler, more consumable interfaces.

One example might be to define a "frontend service" that comprises managing allow/blocklists, path-based routing & ACLs, DNS, and SSL certificates; another could be dealing with the mountain of options with raw GCP/GKE APIs, console, and CLI options, and presenting a service/API/CLI of our own that allows a user to "just" create a VM, project, etc. while ensuring that the results of that action are properly tagged, follow naming conventions, have appropriate security measures in place, and are subject to lifecycle policies to reduce bloat in idle infrastructure.

For a GitLab engineer looking to engage with our infrastructure, it is much less intimidating to be presented with a curated selection of common use-cases via a web frontend, internal API, or custom CLI utility, than to be told "Oh yeah - just check out our thousands of lines of terraform/chef/ansible/go code, that'll get you what you need." The easier and safer we make it for more people to productively contribute to the growth and management of gitlab.com, the better all our lives will be. As things stand, we often operate as a bit of a "service team", dealing with many fractured ad-hoc requests from many different directions, and that simply won't scale effectively.

These are just a couple points from my perspective. What does everyone else think? Since we could brainstorm a thousand ideas that may or may not be feasible/important/urgent, we should try to focus on the things that are most critical, alleviate the most pain, provide the greatest value, etc. As a concrete exercise, one way of framing this is to consider the end goal for a particular timeframe, then work backwards from there filling in the broad strokes of what it'll take to get there.

Ex:  
_It is February 2022; in the past year we have_
- _implemented a core webservice/API and associated CLI that we use to holistically manage frontend services for gitlab.com. So far we can manage allow/blocklists in Cloudflare, page rules, WAF rules, and path-based routing_
- _while we have emergency-use out-of-band SSH credentials for SREs, we have successfully migrated all other infrastructure authn and authz to Okta or OAuth integrations_
- _we have a service that allows us to create and manage VM base images, with reports on utilization throughout the environment for visibility as we facilitate updates, OS upgrades, and removal of outdated images from the catalog_
- _we have established a baseline definition of the standards required for our GKE cluster, and have a plan to develop a CLI for creating, updating, and validating foundational cluster configuration throughout all our environments_

Story points: 8.0