Skip to main content

Introduction

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.

Introduction​

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.

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.

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.



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.

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: