Squash, the definitive cloud-native debugging tool

Squash 0.5 is out. This new release addresses enterprise debugging use cases making it the most pervasive debugging tool for cloud-native applications.

The ability to do live debugging of an application is an essential piece in the development process. It bothers me, and I often have a hard time understanding how developers can purely rely on log statements to identify if a piece of code is behaving as intended. Adding log statements to the code you write is probably a no brainer, but it should by no means be the primary tool of a productive debugging session.

Applications should be developed in an environment very similar to the ones they will run when in production. In doing that, you have the opportunity to optimize the most crucial development metric in my opinion, which is the Lead Time.

Expectation vs. Reality (Prod environment vs. Dev environment)

I’m hopeful that your organization or the team you work with has long left the situation where the diagram above would apply. Now you face different circumstances like:

  • Most applications run in containers
  • You are users of Kubernetes in its many forms, locations, and flavors
  • Prefer Spring Boot or Golang to Java EE

When we factor in the reality of distributed computing with microservices today, the need for a cloud-native debugging tool is certainly intensified. Fortunately, Squash can be your daily friend on this journey, and for two fundamental reasons: made for cloud-native workloads and enterprise security concerns. Let’s take a look at these points which will also help you understand the Squash architecture.

Built for Cloud-Native (and Kubernetes)


Squash brings excellent value to Java developers in that it will automatically find the debug port that is specified when the JVM starts. After the port is located, it uses port forward and then relies on the IDE’s capability to leverage JDWP.



Unsecured Mode

While this would be only appropriate for local environments or where very high levels of trust are disposed to developers, it is still a valid use case. When on unsecured mode, the debug helper, a pod called ‘Plank’ will assume that the user has elevated privileges on the cluster or namespace which would allow a process to be controlled at the Linux Kernel level. This gets interesting, continue reading about the secure mode.

Secure Mode

The secured mode differs from the unsecured method in that the parts doing the process discovery and attachment are running in a different namespace. This scenario allows for tight control of the debugger process, while also not requiring developers to have elevated privileges. It is ideal for Enterprise use cases.

On the diagram above, the expectation is that the developer that wants to debug the application on namespace ns-a has much fewer privileges than the user responsible for the namespace where the debugger runs. You gain from the ability to debug while not compromising on security.

Try it now

We have invested our precious engineering time to improve the Squash documentation, and we hope it will serve you well.

Go right now to https://squash.solo.io and start being more productive. Squash is open source, and we welcome contributions. Feel free to check-out the code at https://github.com/solo-io/squash.