Bridging the Gap: Local Testing with Shared Kubernetes Clusters

Signadot - Aug 10 '23 - - Dev Community

With the latest release, we’re excited to announce support for local testing. During development, you can include microservices running locally into a Sandbox, and test them in high fidelity with dependencies running within a shared Kubernetes cluster.

About a year ago, we announced a public beta of Sandboxes - a type of lightweight environment that we built for Kubernetes that makes it efficient and quick to test changes to microservices-based applications at scale. Over the past year, we improved Sandboxes to scale well when there are many hundreds of microservices involved, we made it robust to use concurrently across hundreds of developers by enabling data isolation through a resource plugin framework. It has evolved into a critical building block for our users to build their preview environments and testing workflows in Kubernetes.

Then we came to a realization, that to take the next step in creating the best Developer Workflow, we needed to go back and solve a key piece - local testing. This means not just relying on CI processes and docker builds, but enabling developers to get feedback from the whole application as they iterate on code. Today, we’re releasing an update that lets you include test versions of microservices running in your workstation in a Sandbox. These local workloads seamlessly connect to dependencies in the Kubernetes cluster and provide quick feedback during the iterative development process.

Sandboxes for Local Testing

With this new update, you can make changes to any microservice, run it on your workstation, and then set up a Sandbox that encompasses the local workload as well as cluster-side components to create an isolated lightweight environment.

Image description

You can use this sandbox as before to test your change in the context of the larger shared environment - all of this without having to push docker images to a registry or wait for feedback from later in the development lifecycle.

Image description

All of this happens without duplicating any infrastructure or setting up isolated (expensive) copies of the microservices stack. Under the hood, they continue to use service meshes or Kubernetes sidecars for request routing, and projects like OpenTelemetry for context propagation.

Image description

Systems like this have been used to supercharge the development workflow at companies like Doordash and share similarities with Uber’s SLATE. We’re excited to make it available more widely for everyone running their applications in Kubernetes.

Data Isolation and Collaboration

An important but often understated aspect of any system utilizing a shared Kubernetes cluster is data isolation. We wanted to make sure that the data isolation mechanisms we designed for in-cluster sandboxes translate well to sandboxes comprising local workloads as well. That makes it possible to build robust and isolated environments that can be used for developer testing, preview environments, and end-to-end testing.

Earlier this year, we released Route Groups which enable collaboration on top of sandboxes, like being able to test changes in one microservice with other microservices while they are also under development. We extended that to encompass sandboxes that contain local workloads as well, so, you can do something like this:

Image description

Using RouteGroups, you can combine local workloads and preview versions of services in Sandboxes to test your changes with other changes that haven’t merged yet!

Sandboxes supporting local workloads are available right now - once you upgrade our Kubernetes Operator to v0.13+. You can try it yourself using the local development quickstart, or check out the video below:

What’s Next?

What’s next for us? We want to continue to expand the scope of local workloads in Sandboxes so that they can work well together with other sandboxed entities such as Resources. This is on our roadmap and something we’re actively seeking feedback from users on. Aside from that, we’re continually working towards making it easy for organizations to adopt Sandboxes, with planned improvements to the Developer Experience in our CLI, as well as IDE integrations in the future.

We wouldn't have made it this far without your feedback and support. Thank you for joining us as we evolve and iterate, and we hope you'll continue to let us know what's working, what's missing, and what you're excited to see next. If you’d like to try Sandboxes for local testing, you can sign up for free at https://www.signadot.com, or schedule a demo with us.


Originally published at https://www.signadot.com.‍

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .