Show HN: Sidekick - Live application debugger is now open source | Hacker News Reader

Show HN: Sidekick - Live application debugger is now open source

github.com

77 pointssozal24 comments

Sidekick is a live application debugger that lets you troubleshoot your applications while they keep on running. It allows you to add dynamic logs and put non-breaking breakpoints in your running application without the need of stopping & redeploying. Currently supporting Java, Python & Node.js runtimes.

Sidekick Open Source is here to allow self-hosting and make live debugging more accessible. Built for everyone who needs extra information from their running applications.

Open articleView on HN

Why would I use it over the JVM’s stellar observability tools, that I assume can do a much better job due to being integral to it?

I don’t only mean the debugger, but also the flight recorder.

Hi,

This is Serkan. Co-Founder&CTO at Thundra, the company behind Sidekick.

Flight recorder is a very useful tool for profiling your apps running on JVM. But next generation debugging tools like Sidekick allows you to debug your Java applications without stopping at breakpoint (so it can be used even on production)

Sidekick - gives you local debugging like experience with tracepoints (aka non-breaking breakpoints) - And allows you to inject logs dynamically to anywhere on the fly without code change, rebuild and redeploy

JFR can also run in production without any meaningful overhead, it is a very important goal of it.

But dynamically changing new “trace”points with a running prod instance is indeed a new functionality it seems.

Hello, HN! I'm Barış from Sidekick.

Currently supporting Java, Python & Node.js runtimes.

So Sidekick is like Chrome DevTools for your backend.

Problems that we solve

- Collecting dynamic data from running applications is hard

- Adding new logs and redeploying apps takes time ⌛

- Developer onboarding is hard for complex systems

- Microservices are harder to debug

- Logging everything or using APMs create so much unnecessary data

What we offer

Here is how you can benefit from Sidekick and boost your developer productivity up to 3x

- Debug your remote application (monoliths or microservices on Kubernetes, Docker, VMs, or Local) and collect actionable data from your remote application.

- Add logs to your production apps without redeploying or restarting

- Cut your monitoring costs with on-demand & conditional logpoints & tracepoints

- On-board new developers by showing how your apps work using real-time data.

- Observe Event-Driven Systems with ease

- Programmatically control where and when you collect data from your applications

- Either use Sidekick's Web IDE, VS Code & IntelliJ IDEA extensions to control your Sidekick Actions or use headless clients to bring Sidekick to your workflow in any way you want!

- Evaluate the impact of an error on applications with integrated distributed tracing.

- Collaborate with your colleagues by sharing snapshots taken by Sidekick.

- Reduce the time spent context-switching between different tools.

Our journey:

It has been around 6 months since we released Sidekick as a standalone solution and the last 6 months were a roller coaster. We have improved Sidekick to make it a true developer-first tool that makes the developers a part of the core loop. You can read my blog to learn more about our journey:

https://medium.com/runsidekick/past-present-and-future-of-si...

  In addition to our new features, we have decided to make Sidekick Open Source to allow self-hosting and make live debugging more accessible. Now it is ready to meet you!

TLDR; Sidekick is a plus one for your observability stack, built for everyone who needs extra information from their running applications, and now it is open-source! We still have a lot to do and we would love to hear from you in the comments down below, your feedback and your recommendations

In addition to being OSS, Do you mind sharing the differentiation or with overlap w Lightrun and Rookout?

Yeah sure you can check out: https://www.runsidekick.com/rookout-comparison & https://www.runsidekick.com/lightrun-comparison

We are currently updating these pages but we mainly differ with: Our headless approach (REST API & Node.js client), Lower Overhead & Higher Hit count limits, Web IDE, OSS, Thundra APM integration, Collaboration support, Full On-premise solution with Web IDE support

more will come with this months updates

also you can read our benchmark results: https://medium.com/runsidekick/sidekick-blog-production-debu...

This isn't a comparison just a title and misleading bullets. Lightrun supports all these things and so much more.

* Lightrun supports web UI via VSCode.dev support

* Lightrun can be installed on-prem

* It supports all these 3 platforms and .net soon

* It supports SSO and quite a few features required by fortune 100 companies

sorry for being misleading, I was not trying to do so. About the first one I was referring to our own web UI, considering the plugins you are right. 2. one they weren't used to ship with a 3rd party IDE afaik, that's why I've said full on-prem with web ui. don't remember saying anything about the 3rd and the 4th, and it wasn't supposed to be something offensive to our competitors

The site says:

> Sidekick vs Lightrun Why Choose Sidekick

Which implies the following bullet points are thing that sidekick has and Lightrun doesn't. Number 3 and 4 correspond to:

* Comprehensive language coverage (NodeJS, Java, Python)

All supported by Lightrun

* Enterprise features such as SSO, Workspace management, and more

Not sure what workspace management means but Lightrun supports a wide range of enterprise features and is deployed in Fortune 100 and major security conscious enterprises.

> AGPL-3.0 license

https://github.com/runsidekick/sidekick/blob/v0.0.1/LICENSE

I knew what it was going to be before even looking

this article: https://plausible.io/blog/open-source-licenses#what-are-the-... helped us a lot on our decision.

can you elaborate what is wrong with using a license that is listed on https://opensource.org/licenses/alphabetical ?

Just a guess, but I think a lot of people immediately see the letters "GPL" anywhere and back out, rightly or wrongly. The nuances of licenses are poorly understood by many developers (and even legal departments) and there's a "I can't be bothered" attitude a lot of the time, even where AGPL makes a lot of sense and isn't particularly restrictive on the average end user. There certainly needs to be a lot more education in this area.

We hear this a ton from our friends at big companies, but... surely most of them use Linux? Or Git? Or x264, OpenJDK, GIMP, or VLC? Or (if you include LGPL) the WebCore portions of Chrome/Safari/Edge, which originated in KHTML/Konqueror? Or GTK, Cairo, ffmpeg, or WINE?

It's a little hard to believe the "GPL" is that much of a problem to the industry given how popular *GPL software remains in most places.

GPLv3 I realize is a different story, but even then, the companies seem to find a way to hold their nose when they want to. (When we first released Mosh as GPL 3+, we got a call from Apple, who were unhappy that their employees were using Mosh to connect to servers because Apple apparently doesn't want employees to be installing any GPL v3 software on their company-owned Macs. On the phone call, I told them that (a) I didn't think they had anything to worry about in terms of actual problems from the GPLv3, and (b) if they really disagreed, we're open to the conversation, but it would cost them a lot of money for me to want to think about what it would take to give them Mosh under a different license. Somehow they ended up concluding that the GPLv3 wasn't that bad after all...)

Most of the examples you cite are situations where the software is being used as a client or at a distance (in terms of being far down the stack) and not as part of a deliverable. I think using such software is considered straight forward by most (if not by paranoid corporate policies, such as those you've encountered).

Where it gets more difficult is when potential dependencies are (A)GPL licensed. While I support the use of these licenses (particularly the AGPL for protecting cloud deployment of open source tools), I recognize the "friction" they can cause for certain classes of users who might just use something else to avoid thinking about it. (Which, you might say, is their loss.)

Personally I'm really happy to see a commercial entity with a FOSS offering that's protecting their revenue using AGPL instead of these new "open source eventually" business licenses. Don't get discouraged. For everyone that would complain about this license choice there are just as many of us who celebrate it.

Thanks for this comment! We wanted to make live debugging more accessible while protecting our revenue and AGPL seemed reasonable.

It's for sure not "wrong," as (a) it's your software (b) people have different concerns they want to have addressed by license terms

For me, and the company I work for, AGPL is strictly banned. GPL is gravely frowned upon, because the founder had a lot of lawyers involved that almost bombed an acquisition. I appreciate that's anecdata, but for sure it is a "conversation" in the company versus Apache 2 which requires no conversation

I'm actually kind of luke-warm about AGPL for some things, but for what I imagine is a JVM agent, and thus both injected into my software and communicates over the network, hard pass

For clarity: I didn't mean my comment as a scolding: the community is almost certainty better off for you having chosen to share the code, and there will be folks who can and do contribute fixes under the terms of the AGPL. It's just been my overpowering experience that a lot of companies that try to open source code are trying to guard against "being Amazon-ed" and I appreciate why they think that way

> For me, and the company I work for, AGPL is strictly banned. GPL is gravely frowned upon, because the founder had a lot of lawyers involved that almost bombed an acquisition. I appreciate that's anecdata, but for sure it is a "conversation" in the company versus Apache 2 which requires no conversation

This seems to be a development tool that does not need to be incorporated into your software (I'm assuming the library that runs in your software won't be AGPL but I could be wrong *), so it being AGPL should theoretically be strictly less restrictive than just being closed source.

However, perhaps for companies with policies against (A)GPL software like yours it would be better if they offered it both as freeware under a closed source license that doesn't allow modifications AND open source under the AGPL so you could pick which license you like better?

*Actually strictly speaking even if the agent software is AGPL I believe that would only really matter if you distributed a version of the software including the agent outside of your company, so theoretically you could just remove it for production releases, but I agree that it would be a lot more justified to avoid it because of the license in that case, so I hope they intend to release the agent software under a more permissive license.

I think there is a knee jerk reaction against AGPL, because it can be seen as fairly restrictive in the case of software you would incorporate into your application, but it seems perfectly reasonable for a development tool.

At least AGPL-3.0 is more honest and direct than SSPL or other vague licenses to prevent Amazon'd. Lawyers and internal legal departmens did not catch up to those licenses yet. Pretending to be open source until a point and forking under a new license leaves a bad taste.

> I knew what it was going to be before even looking

Assuming that it's just the server part that's AGPL, that's not very restrictive for something that's purely a development tool.

That's VERY different from a library you need to include in your finished application being AGPL or even server software that you might expose to end users being AGPL.

Remove the finger image in the README. It's a huge turnoff.

sad to hear. created a pr for that

Reply on news.ycombinator.com