<aside>
💡 This document is very much work in progress
</aside>
Introduction
Gitpod is really two systems integrated into one:
- workspace contains everything that's required to start, maintain and control a workspace. This includes
- controlling Kubernetes,
- providing control over the workspace's features (e.g. ports or admission),
- routing traffic to workspaces,
- providing access to (headless) workspace logs,
- initialising and backing up their content,
- isolating the workspaces w.r.t. each other.
- meta which includes everything required to make workspaces useful and convenient:
- user login, authentication and authorisation,
- an API for the frontend,
- integration with Git hosting platforms (e.g. GitHub, GitLab or Bitbucket),
- prebuild management,
- (in gitpod-com) subscriptions and billing,
- persist workspace (instance) state.
https://youtu.be/svV-uE0Cdjk
The diagram below should provide a rough overview of the components involved, where they sit and who they talk to.
Architecture diagram of Gitpod
Principles
Distributed only where we have to
Gitpod is a distributed monolith. We try to keep things as closely related and together as possible, while at the same time maintaining proper separation of concerns, and introducing well-designed APIs. We're deliberately not putting every concern into their own service, because every service edge introduces a chance for failure and increases operational complexity.
Instead, Gitpod distributes across its components because it has to. The individual components exist because:
- we want to limit the blast radius/failure domain of something,
- some parts are better written in Go or TypeScript and we want to use both,
- we need to integrate with systems beyond our control (mainly Kubernetes),