Show HN: Signadot (YC W20): Local Testing with Shared Kubernetes Clusters

Hi again HN, we’re Arjun and Anirudh, founders of Signadot (YC W20). Signadot helps teams developing microservices test their changes using lightweight environments called “Sandboxes”. We use a relatively new approach, using traffic labeling (using OpenTelemetry) and request routing (using a Service Mesh) to isolate environments in a shared Kubernetes cluster. Today, we’re launching a new feature to help developers with local testing of microservices during the iterative development process.

When we initially launched in September last year (https://news.ycombinator.com/item?id=32854746), we focused on preview & PR test environments in Kubernetes. Something we heard from developers overwhelmingly was that while these preview environments were useful for testing changes once they’re pushed to a branch, the feedback loop wasn’t quite as fast as it could be - because it still involved waiting for docker images to build and CI processes to kick in, which could take many minutes for each commit before it updated a sandboxed microservice running in Kubernetes.

With our new release, we’re addressing this feedback. With an updated version of our CLI & Kubernetes Operator, Sandboxes can now encompass not just services running in the cluster, but also those running on a developer workstation. These “local workloads” in Sandboxes can connect out to dependencies running in the cluster, and receive certain labeled traffic back on the workstation. For traffic routing from the cluster to the workstation, just as before, this functionality works out of the box if you’re using a service mesh like Istio (or using our K8s sidecars).

In building out support for local testing, we wanted to make sure that the framework we built for spinning up ephemeral databases or schemas associated with a Sandbox can work well in this context as well. This is one of the areas where we found existing tooling that enables workstation <> cluster connectivity lacking in that they do not provide ways to address data isolation, which makes a shared Kubernetes cluster less stable over time. Additionally, we wanted to support the collaboration just as it works with preview environments - combining Sandboxes containing changes to different microservices and testing them together.

If you’re interested, you can try this out by going to app.signadot.com, using the quickstart guide at https://www.signadot.com/docs/quickstart/local-development. We have “playground clusters” that can be provisioned via our UI if you don’t have a Kubernetes cluster handy.

We’re working next on improvements to the Developer Experience for local testing in our CLI, and extending our request routing layer to work with other service meshes like Linkerd. We’d love to get feedback and comments from the HN community!