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)

Many times in my career, the team I was working with would develop an application locally using JBoss Application Server, for example, to then have the same application running in production in some other application server. Often it was Weblogic or Websphere, for different reasons. Whenever we did that, we made our lives harder negatively impacting the Lead Time. Here’s my theory:

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)

The architecture of Squash considers that cloud-native deployments can often be ephemeral. To realize that consideration, it interfaces with APIs such as the Kubernetes API create the necessary components which will allow you to debug an application in your preferred IDE remotely.

Java

Let’s take a look at the flow below, which is for debugging a Java application, for example:

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.

Go

For Go software engineers that run and develop for Kubernetes, it’s fair to say that it’s a must-have. There are a few ways to debug a Go application in Kubernetes, but none is as smooth and considerate of enterprise scenarios as Squash.

Security

At Solo, we understand how critical it is to consider the security aspects of debugging applications in distributed environments. To that end, Squash has an unsecured and a secured mode.

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 assumes that users have limited privileges in clusters, which I believe it’s the way it should be. For the Plank pod to do its job, it requires SYS_PTRACE, and once a process is given that permission, it means that they can control any process in a host. How dangerous that is? Well, you can kernel panic a node in no time. We don’t want that.

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 love Squash. We created it for our use, to assist on the development of our other projects like Gloo, a Next Generation API Gateway, and Supergloo, a service mesh orchestration platform. It has been proven to be very useful, which increased our overall productivity.

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.