Wikimedia Release Engineering Team/Seakeeper proposal/Kubernetes vendor selection

= Kubernetes vendor selection =

Overview
Kubernetes vendor criteria are in service to the Seakeeper proposal and informed by  Future CI requirements. Requirements herein defined are scoped such that they cover only the products, services and relationship WMF Release Engineering is seeking to establish with a Kubernetes PaaS provider for the purpose of rolling out and maintaining an Argo based CI system. These requirements must bolster those of the greater CI system—and should directly reference them when relevant—but may also be informed by considerations outside the precise purview of CI.

Discussion between primary participating stakeholders should drive the creation of these requirements and should be kept to the discussion page of this article as much as possible.

Classification of requirements
Requirements will be classified into four distinct categories, each of which is a quadrant formed by two main category axes function/quality and service/organization.


 * Function/Quality:
 * A functional requirement describes what the k8s vendor and service needs to do for us.
 * A quality (aka non-functional) requirement describes constraints on how the vendor and platform are to operate and deliver, generally expressed using some kind of  quality attribute.


 * Service/Organization:
 * A service requirement speaks to the k8s platform and supporting services being provided by the vendor.
 * An organization requirement speaks to the history/standing of the vendor organization itself, and its underlying ability to provide and support the service, akin to supplier evaluation criteria.

Categories


Combined, these main axes constitute four category quadrants we can use for classifying requirements.


 * Service Function (SF): A requirement that speaks to the behavior of the provided k8s platform and is informed by the material needs of Wikimedia technical contributors and WMF admins.
 * Examples:
 * SF1 – API supports standard k8s toolchain
 * SF2 – Allows custom resource definitions (CRDs)
 * SF3 – Supports single-node tenancy


 * Service Quality (SQ): A requirement that speaks to the qualities of the provided k8s PaaS and our needs around availability, scalability, performance, maintainability, etc. Some of these will map directly to service level objectives (SLOs).
 * Examples:
 * SQ1 – Cluster availability exceeds 99.99%
 * SQ2 – Node performance meets or exceeds current levels


 * Organization Function (OF): A requirement that speaks to the capacity of the vendor organization to deliver and continue to support its service.
 * Examples:
 * OF1 – Financially stable as a k8s provider
 * OF2 – Demonstrates competency as a k8s operator
 * OF3 – Support level with at least 1-hour response window


 * Organization Quality (OQ): A requirement that speaks to the vendor organization itself, its business practices and its alignment with WMF's culture and values.
 * Examples:
 * OQ1 – Contributes improvements to k8s upstream
 * OQ2 – Track record of equitable labor practices
 * OQ3 – Scored four-star EFF data-request rating

Requirements
Requirements listed below will will later be used to score each prospective vendor. Each new requirement added to the table must include the following:


 * Code: Unique identifier formed by a classification prefix and number.
 * Weight: Whether this requirement constitutes a should have or a must have requirement. Should a vendor not meet a must have requirement, it is highly likely it will not be chosen unless all other candidates fail in some way as well.
 * Name: Short but descriptive name of the requirement.
 * Description: Full requirement description.
 * Reason: Justification for including the requirement with links to upstream documents such as the Future CI requirements and  Seakeeper proposal.
 * Status: Either needs review or reviewed (linking to any relevant | discussion topic).