API boundary analysis
We divided the end-to-end automation into four stages. We can ignore stage one as it is about preparing the Crossplane control plane itself. It’s essential to understand why we split the remaining stages into three with four XR/claim APIs. The following are the ideas behind our API boundaries:
- The cluster XR/claim: Setting up the cluster is not just relevant to
product-a. All modern workloads are generally deployed in Kubernetes, and the organization will have many such cluster setup activities in the future. Building a separate API to enable reusability and centralized policy management makes sense. Another critical reason to keep the API separate is that the cluster setup is a one-time activity and acts as cross-cutting for further application workload deployments. - The onboarding API: The XR/claim for the GitLab project onboarding is developed as a separate API. We don’t need to onboard the repository and CI pipeline for every environment...
