Sandbox
In the microservices context, every change is done incrementally, with each microservice being developed separately. However, with large numbers of microservices, it becomes difficult to get quick high-quality feedback on the overall functioning of the application as individual components are changed.
A Sandbox is a logical abstraction that comprises workloads and some ephemeral resources. The workloads typically represent microservices that are being developed or tested.
Sandboxes enable lightweight and highly scalable environments that can be used to test every change in the context of the entire stack of microservices. The workloads within a sandbox can run either in your cloud environment or locally. The sandboxed workloads and resources are combined dynamically with the baseline environment to provide an isolated environment for testing code changes. Isolation between these sandboxes is accomplished using request routing and context propagation.
Request Routing
Request routing refers to the ability to dynamically route requests amongst a set of interacting microservices. Sandboxes rely on request routing to make requests flow through test workloads, and for isolating the sandbox from baseline services.
Request routing for Sandboxes is realized either using a service mesh such as Istio or without a service mesh, using Signadot's DevMesh. When using a service mesh, Signadot configures the mesh to perform request routing on its behalf without needing additional in-cluster components specific to routing. The DevMesh sidecar is a lightweight envoy-based proxy that can be added to any workload through a Kubernetes Pod annotation.
All routing is done based on an opaque value called the Routing Key. The routing key is unique to each sandbox and generated by the system when the sandbox is created. A request containing the routing key in a supported header will be routed to each changed service in a sandbox, as long as context propagation is enabled along the entire path of requests. Additionally, hosted preview URLs automatically inject the routing key.
Context Propagation
Sandboxes use header-based context to isolate request flows from one another. This header-based context consists of one of several well-known header names and a value, called Routing Key. The routing key is used for making routing decisions during request routing.
Context propagation is a mechanism for propagating information from request to request amongst a set of interacting microservices. This commonly requires either adding a library to your microservice that performs this context propagation automatically, or manual instrumentation to ensure that specific headers on the incoming request are carried over as-is to the outgoing request from that service.
However, there are several mechanisms available that allow adding context propagation to a service in a standardized manner. One preferred way to accomplish this is instrumentation using OpenTelemetry, which originated in distributed tracing. Sandboxes do not require any tracing or trace collection to be implemented. OpenTelemetry simply provides a convenient set of libraries that can take care of propagating the request context for us across the services automatically.
In some languages such as Java and Node.js, instrumentation may be completely automatic with a drop-in library while others may require some code changes.
Context propagation cannot be done for you automatically by a service mesh and must be done at the application layer because it is not generally possible to correlate an incoming request into a service to an outgoing request from the service by observing it externally.
With context propagation in place, requests will carry the context across arbitrary request topologies, making the effects of changes in the sandbox visible from any service in the system when an identifying header is added to the request.
For more details on how sandboxes are used check out the guides covering different use cases.