Skip to content

Cell: Routing PoC: Cloudflare Worker

The routing layer is meant to offer a consistent user experience where all Cells are presented under a single domain (for example, gitlab.com), instead of navigating to separate domains.

We need to decide what technology the routing service is written in. The choice depends on the best-performing language and the routing layer's expected way and place of deployment. If it is required to make the service multi-cloud, it might be necessary to deploy it to the CDN provider. Then, the service needs to be written using a technology compatible with the CDN provider.

We also have a PoC from @andrewn https://gitlab.com/andrewn/stateless-router, see #408507 (comment 1379811355) from more context.

As an outcome of this issue, we expect:

  • Evaluate Cloudflare worker as the technology to implement the routing layer
  • Document decisions in the Cells blueprint
  • Create a plan with concrete issues to continue the development of the routing layer: discovery, single domain interaction, endpoints classification, GraphQL, etc.

Related to #408507.

Reference:

Requirements:

See https://docs.gitlab.com/ee/architecture/blueprints/cells/routing-service.html#requirements

Results

We deployed the router in https://rules-router.sxuereb.workers.dev/ and you can see the demo where we have a single domain routing to 2 different GitLab instances.

Pros

  • Low Latency: Around 10-15ms, or max is 50ms
  • Global Deployment: We automatically deploy to multiple regions, which helps us move towards regional deployments.
  • At the Edge: We are at the edge of the request, having the ability to route to multiple Cells before reaching GCP's network.
  • Autoscaling: We don't have to provision scale up/down manually, everything is handled for us. Cloudflare is a trustworthy company we've been using and we know it can handle our load.
  • Multiple Protocol support: Multiple Protocol support like websockets.
  • Meet requirements Can meet all the requirments, which some work since not everything is out of the box.
  • Support for storage: Provides cache, and KV for storage options that are global and scale up /down with workers.
  • Security: Since this is a hosted offering it has a strong security model to prevent problems.
  • Enforce Zero Trust: All sub requests need to go to public resources but provides easy mTLS authentication
  • Community Support: The documentation is informative, and they provide a forum and discord for support (outside of enterprise support)
  • Deployment tooling: Can use our existing deployment/provisioning tooling like GitLab CI and Terraform
  • Developer experience: Easy to get set up locally and provides a good and fast experience.

Cons

Action items

Resources

Edited by Steve Xuereb