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. |
I don’t only mean the debugger, but also the flight recorder.
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
But dynamically changing new “trace”points with a running prod instance is indeed a new functionality it seems.
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.
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!
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
https://github.com/runsidekick/sidekick/blob/v0.0.1/LICENSE
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.
can you elaborate what is wrong with using a license that is listed on https://opensource.org/licenses/alphabetical ?
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
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.
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...)
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.)
* 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
> 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.