Control Your Chaotic Deployment Workflows with Upbound

In the realm of infrastructure and cloud resource management, one must tread lightly upon the path between complexity and chaos, much like the treacherous terrain on the path to Mordor. Complex workflows hold the potential to ensnare even the most seasoned platform wizard when scaling or modifying workspaces. Just as the One Ring brought perilous consequences, so too can unchecked complexity descend into calamity in our cloud domains.

In these dark places, Upbound may be a light for you, when all other lights go out. In this post, we’ll embark on a journey to find how Upbound can help you battle the Balrog of complexity in your workspace deployments.

Let’s identify the essential elements of this example deployment:

• Workload cluster
• Workspace environments
• Application delivery

The first step in this quest is to provision a cluster to manage the underlying work for the application.

Gather your fellowship

This example repository contains an AWS cluster example. The directory contains the underlying infrastructure for you to deploy your workspaces and applications.

The `cluster` directory contains the following resources:

These resources are the foundation of your application workspace and you can deploy them with Crossplane or Upbound.

This example is based on the `Cluster-as-a-Service` configuration, an "out of the box" pre-built configuration that exposes an API to create Kubernetes clusters in AWS.

After you’ve gathered your fellowship of nodes, it’s time to segment them into different environments.

Construct the realms of your workspace environments

You can create Composite Resource Definitions to help you divide your workspace environments. In this example, we're creating individual namespaces by team. These teams contain the `kind`, metadata, and users that have access to that team with their associated role.

Here's an example of a generic team composition that shapes your team configurations:

This composition uses the go-template function to patch multiple teams into your deployment workflow.

To deploy a specific team namespace, you can construct your `team` manifest like:

This approach can help you with resource isolation and resource management. Each team can work within their own dedicated cluster with appropriately scaled resources like CPU, memory, and storage. These segmented clusters provide flexibility and autonomy to each team as they have more control over their clusters and can tailor the environment to their specific requirements and workflows.

Namespaced team segmentation can provide a practical approach to scaling clusters. With specific clusters scaling up or down as needed, your teams can optimize their cluster configurations without impacting other teams.

You've gathered your fellowship of clusters, gathered your namespaced armies, now is the hour to deploy your application.

Light the beacons of your application

You're almost at the end of your journey, but the most important step is still ahead. Deploying your application with the workspace and cluster already built ensures your workflow stays consistent and repeatable.

The application definition references your target cluster, namespace, and the repository you've stored your application:

The Cluster-as-a-Service configuration you've built includes a gitops based deployment system with the option to configure flux or ArgoCD.

With this example, you'll use ArgoCD to complete the process.