Unbind has a few key concepts that are important to understand in order to fully understand how to use Unbind effectively.

Team

A Team is at the highest level of the Unbind hierarchy. It encompasses Projects, Environments, and Services.

• Kubernetes namespace: Each team is associated with a Kubernetes namespace, which is used to isolate resources within the cluster.
• Kubernetes RBAC: Team permissions are translated directly into kubernetes Role-Based Access Control (RBAC) rules, meaning permission enforcement is also happening at the cluster level.

Within one team, you can create multiple Projects.

Project

A Project is a collection of Environments and therefore Services. It is a logical grouping of resources that are related to a specific application or service.

• Kubernetes label: Each project is associated with a Kubernetes label, which is used to group resources within the cluster.
• Permission enforcement: Despite teams directly linked to Kubernetes RBAC, permissions are still configurable and enforceable at the project level.
  • This means you could have a user that has access to a team, but only has access to specific projects within that team.

Within one project, you can create multiple Environments.

Environment

An Environment is a logical grouping of Services that are intended to be related to a specific environment, such as development, staging, or production.

• Kubernetes label: Each environment is associated with a Kubernetes label, which is used to group resources within the cluster.
• Permission enforcement: Permissions are also configurable and enforceable at the environment level.
  • This means you could have a user that has access to a team and project, but only has access to specific environments within that project.

Within one environment, you can create multiple Services.

Service

A Service is a single application or service that is deployed within an environment. It can be a web application, database, or any other type of service that you want to deploy.

• Kubernetes label: All resources associated with a service are labeled with the service, environment, project, and team IDs.
  • At the low level, this means that we can logically group logs and metrics for a service, environment, project, or team.
• Kubernetes resource: Each service is associated with at least one, but often more Kubernetes resources, such as a Deployment, StatefulSet, Job, Ingress, etc.

Instance

An instance is a specific running container (pod) of a service.

• Replicas: Most of the time, the number of instances will be equal to the number of replicas defined in the service configuration.
  • This is the case for stateless services, such as web applications or APIs.
  • Some databases will have multiple instances serving different roles, such as a read-replica of a database.
• Load balancing: Your traffic will be automatically load balanced across all instances of a service.

Variable

A Variable is a synonym for a Kubernetes Secret. They directly correlate to environment variables within each instance.

• Build time: All variables are also injected at build time, meaning that they are available to the application during the build process.
• Runtime: Variables are also injected at runtime, meaning that they are available to the application during execution.
• Scope: Variables can be scoped to a service, environment, project, or team.
  • Team: Variables scoped to a team, are available to be referenced by any service within that team.
  • Project: Variables scoped to a project, are available to be referenced by any service within that project.
  • Environment: Variables scoped to an environment, are available to be referenced by any service within that environment.
  • Service: Variables scoped to a service, are available to be referenced by other services within that environment.
• References: Variables can be references of other variables, or service endpoints. Just use $ to list all available references when creating a variable.
  • Auto syncing: Referenced variables update everywhere. If Service A is referencing ${Service B.DATABASE_PASSWORD} - and you update the password for Service B, it will automatically trigger a redeployment of Service A with the new password.
  • Composition: You can compose variables with plaintext and as many references as you want. For example, pg://user:${Service B.DATABASE_PASSWORD}@${Service B.DATABASE_HOST}:${Service B.DATABASE_PORT}/${Service B.DATABASE_NAME}.