Skip to main content

How it works

Signadot is a Kubernetes-native platform that helps you accelerate the development of microservices-based applications. It speeds up development by enabling developers to test code changes in Kubernetes against real dependencies as they write code.


Traditionally, high-fidelity Kubernetes clusters (such as staging) are difficult to share across many engineers working and validating their changes to microservices concurrently. It leads to engineers being blocked on one another, queuing up to test their changes, or worse, getting unclear feedback about their changes when testing against other dependencies in an unstable shared environment. Debugging test failures in this environment is also non-trivial because many commits are co-mingled and it may take a long time to hunt down the root cause of an issue.

As a workaround, namespace / cluster-based "dev" environments in Kubernetes are sometimes set up to try and reduce bottlenecks in the high-fidelity environment. These are effective at a smaller scale, but even as there are more than 20 or so microservices, this approach runs into several problems such as:

  1. Significant infrastructure costs and maintenance burden keeping the dev environment(s) up-to-date
  2. Testing against stale dependencies causes issues to be discovered later in the development lifecycle
  3. Long startup time for the environment to become ready and the complexity of developer setup results in low usage within organizations
  4. Lack of realistic data or 3rd party dependencies in dev environments

Systems like Signadot are a new way of providing high-quality developer and test environments. Lightweight environments called "sandboxes" set up using Signadot can scale to hundreds of microservices. They take seconds to spin up and ensure that each developer's changes are isolated from one another. Below, we'll take a deeper look at sandboxes.

What is a Sandbox?

A "sandbox" is the primary abstraction within Signadot. A sandbox defines workloads that run locally or within Kubernetes, and resources for isolating stateful components, cloud resources, serverless components, etc.

Sandboxes are defined using a declarative specification. A sandbox specification represents only a "diff", i.e. what's changed from the baseline environment. Unchanged dependencies are automatically re-used from the shared baseline. See the sandbox concept documentation for more detail.

How do you use Sandboxes?

First, you install the Signadot Operator into a Kubernetes cluster within your infrastructure. It could be an existing "staging" Kubernetes cluster or a new cluster set up for developer environments. This cluster typically contains all microservices in the entire application, which are collectively called the baseline environment. This baseline environment is continuously updated using a Continuous Integration / Continuous Deployment (CI/CD) process as code changes merge. Once the Signadot Operator has been connected with the Signadot Control Plane, you can create and use sandboxes using the Signadot CLI, API, or UI.

Local Development: Developers can set up a local workload in a sandbox using the Signadot CLI to run local versions of one or more microservices. These local workloads can connect to dependencies running within Kubernetes and allow testing of the change end-to-end as you develop.

Previews and PR Testing: You can integrate sandboxes into the Continuous Integration (CI) pipeline as well. For a given Pull Request on a particular microservice, once a docker image has been built in CI, a sandbox with a test version of the microservice running that new docker image can be automatically deployed into Kubernetes. This sandbox serves as a preview or integration test environment to collaborate and run automated tests before merging. You can configure these sandboxes to be updated automatically with each commit and deleted when a pull request is closed.

For any sandbox whether running workloads locally or within the cluster, developers can perform manual testing as well as automated testing using tools like Postman, grpcurl, etc, or by invoking frontend applications (web, mobile, etc) and testing end-to-end.

How does request-level isolation work in a Sandbox?

Each sandbox is a separate "tenant" and has an associated piece of metadata called a routing key. The routing key is typically passed around the system between microservices sending requests to each other using OpenTelemetry-based context propagation. The routing key ensures that requests sent to one sandbox's workloads don't interfere with other sandboxes or the baseline.

Request routing within Kubernetes is implemented by the Signadot Operator either via integrations with an existing service mesh such as Istio or Linkerd (coming soon!), or by using a system of built-in DevMesh sidecars.

Note how the requests taking the green path are isolated from the requests that take the orange path, and both of these in turn are isolated from the requests following the original black path (baseline). Such a system can be used in parallel by many developers and other users for exercising application flows without interfering with each other and without needing to create replicas of dependent microservices.

How do you test a sandboxed microservice?

Local Development:

During local development, all in-cluster services are accessible to each developer. They can directly send requests to any of them, or to the ingress URL with the routing key associated with their sandbox to test APIs or end-to-end. As long as the routing key is specified, test requests originating anywhere will end up on the local workload running on the developer's workstation.

Previews and PR Testing:

For previews, you can use an existing ingress endpoint directly by setting the required routing key header on it manually, using Postman, or using browser extensions that modify the outgoing request headers.

For convenience, you can also use Signadot-hosted authenticated Preview URLs associated with any sandbox. Requests made to these preview URLs are routed to your cluster via the secure tunnel established by the Signadot Operator. The preview URLs offer the following conveniences:

  • Automatically adding headers used to dynamically route requests to services in Sandboxes as described in Request Routing.
  • Allowing authenticated access to your sandboxed workloads securely without a VPN or port-forwarding via an identity-aware proxy.

What are some other systems like Signadot?

Signadot is a Kubernetes-native implementation of the request-based isolation paradigm that shares some similarities and ideas with the following systems: