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

[jaguar75]

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!

[CodeCrafted]

Congratulations on the new feature release! It's impressive how Signadot addresses developer pain points with microservices testing. I'm curious, how do you ensure that ephemeral databases or schemas maintain the stability of a shared Kubernetes cluster?

[anirudhrx]

Thanks for the question. Anirudh here. Firstly, there isn't always a need to isolate everything by default - in some cases, the testing being done may / application layer entities may already provide the isolation necessary.

However, there are cases like needing to test a schema change for example which can't be done at the application layer. For those cases, there's a DAG-based resource plugin (https://www.signadot.com/docs/resource-plugin-overview) framework that we built, that acts like a lifecycle hook associated with each sandbox - running containers when the sandbox is created & destroyed.

What the platform teams do to provide isolation is to write plugins that set up isolation for the sandbox as needed. The isolation is often logical tenants (as opposed to being at the infrastructure level) like a new schema / table / etc, and includes some of the data seeding / restoring a snapshot type of operations. We have some examples already of different plugins and are writing more.