Skip to main content

Detailed text description: Landscape and Workspace architecture

This page provides a long description of the architecture diagram used in the Landscapes and Workspaces article.

Overview​

The diagram presents two main runtime zones that share infrastructure:

  1. Workspace deployment area on the left.
  2. Landscape deployment area on the right.

Main components​

  1. Workspace deployment:
  • Contains a single reactive instance.
  • That instance powers the Workspace Toolkit used by developers.
  1. Landscape deployment:
  • Contains multiple workload types.
  • Includes a reactive service named foo with three replicas.
  • Includes a reactive docker image service named bar with two replicas.
  • Includes one managed service.
  • Includes one Helm/Kubernetes workload.
  • Includes the Workspace Router service with two replicas.
  1. Workspace Router:
  • Runs as a service inside the landscape deployment, above the other services.
  • Is marked as the Landscape gateway.
  • Receives all incoming requests from outside the landscape.
  • Routes traffic by path to services or custom targets.
  1. Network file system:
  • Shared across the Workspace Toolkit and all reactive services.
  • Represents common persistent storage.

Traffic and routing flow​

  1. Users send traffic from either:
  • A custom domain using the pattern customdomain.com/*.
  • The workspace development domain.

  1. Requests first reach the Workspace Router, which is the Landscape gateway.

  2. The router forwards requests based on path mapping, including examples:

  • /foo to service foo.
  • /bar to service bar.
  • /dashboard to the Helm/Kubernetes workload, configured as a custom target.
  1. Services within the landscape communicate over private internal hostnames.

Developer interaction​

The developer interacts through the Codesphere UI and manages the workspace and toolkit side while the landscape workloads run separately on dedicated compute resources.