Hacker News new | ask | show | jobs
by doctorpangloss 732 days ago
I don’t know what the Sentry guy is really saying - I mean you can write whatever code you want, go for it man.

But I do have to “pip uninstall sentry-sdk” in my Dockerfile because it clashes with something I didn’t author. And anyway, because it is completely open source, the flaws in OpenTelemetry for my particular use case took an hour to surmount, and vitally, I didn’t have to pay the brain damage cost most developers hate: relationships with yet another vendor.

That said I appreciate all the innovation in this space, from both Sentry and OpenTelemetry. The metrics will become the standard, and that’s great.

The problem with Not OpenTelemetry: eventually everyone is going to learn how to use Kubernetes, and the USP of many startup offerings will vanish. OpenTelemetry and its feature scope creep make perfect sense for people who know Kubernetes. Then it makes sense why you have a wire protocol, why abstraction for vendors is redundant or meaningless toil, and why PostHog and others stop supporting Kubernetes: it competes with their paid offering.

3 comments

> eventually everyone is going to learn how to use Kubernetes

That seems obviously true... yet, there are so many people out there that seem unable to learn it that I don't think it's a reliable prediction.

Why necessarily Kubernetes?

For many applications, it's enough to spin up a VPS/plain Docker container, and it will run fine for many, many years, without adding the Kubernetes complexity on top.

If the application is easy to install and autoconfigures itself, it's even better than having to configure everything yourself or create multi-server Kubernetes clusters.

Why you should use kubernetes? You most likely shouldn't.

But why should you learn kubernetes? Because everybody else is using it, whether they should or not. Very few people manage to work alone on IT.

But anyway, every single possible OT user needs something like kubernetes. It comes first at the scaling requirements.

Learning k8s carries a significant cognitive cost. I've learned hundreds of technologies in my 22+ years of career and I am not about to proactively learn something that people started making certification courses for (and some are quite long, we're talking weeks of training daily). And I am definitely not proactively learning it if it's only 1% likely I'll need it. (I am now working at the second company that actually truly benefits from k8s. Out of 15+.)

I have proactively learned what can k8s do and why is it useful however. That's a context that's very needed because k8s is also a huge investment and you should really know the pros and cons before jumping in. That I did.

> unable

I wouldn't equate unwillingness or not needing it to inability to learn

Why have I heard only bad things on k8s? To the point where it’s a meme to understand k8s…
I think it gets used as part of 'best practices' a lot where it was not actually helpful. But it hasn't been my experience that knowing it is a meme or even it being a bad thing. It just gets a little silly when you see stuff like a service managed by k8s that probably made more sense as a library
Personally I could never get into k8s. For most of my use-cases, simply getting a VPS, or having a Dockerfile is enough.

Most apps can run fine for millions or hundreds of thousands of user sessions on a $5-$50 VPS. People prematurely optimize for scale, adding a lot of complexity that only makes development slower, and by having more moving parts, there are more things that can break. Start simple. Scaling is mostly a solved problem nowadays, if you quickly need to scale, there are always solutions to do so. In the worst case, you have to scale horizontally, and if you reach the limit of horizontal scaling, other your app is inefficient, or your business is already successful, so you are no longer in the "start" phase.

Yep, strong agree here, and indeed the modern hardware can achieve mind-blowing stuff. I have used a $250 laptop (i5 CPU that's now 8-9 years old, 16GB RAM, SATA SSD) to stress test some of my Rust apps and I could achieve ~250K requests per second.

Sure that doesn't apply to all tech (f.ex. my favorite Elixir is much slower than this) but for most intents and purposes a plain old VPS with good backups is quite enough and always will be. Or if you are particularly paranoid like myself: have a load balancer and have 2-3 copies of your app servers, 1 DB server, and overzealous backup scripts.

A bit offtopic, but do you recommend any load balancer?

I could have another VPS as a load balancer, but what if goes down? The load balancing services seem quite expensive, as they charge per request.

Ah, I meant use your hosting provider's load balancer + use their VPS-es. I think Digital Ocean allows this, AWS and GCP as well.

That way you're outsourcing the problem of "but what if the load balancer itself falls down?".

I usually want to load-balance between different hosting providers (so if AWS goes down, I still have DO running). From what I've seen, most of them only provide load-balancing within their local networks.
One solution I was thinking of, is to load balance using DNS, or at least to have failure recovery using DNS (one server goes down, update the DNS to point to the other server). I am fine with a small downtime.
The Sentry SDK is open source and easy to contribute to in my experience.
Yeah but who wants to contribute to an SDK for a service that you need to pay for? That would be like if Oracle DB was open to contribution
Sentry is technically self-hostable, but they provide no deployment guidance beyond running the giant blob of services/microservices (including instances of postgres, redis, memcache, clickhouse, and kafka) as a single docker-compose thing. I get why they do this and think it's totally reasonable of them, but Sentry is a very complicated piece of software and takes substantially more work IME to both get up and running and maintain compared to other open-source self-hosted observability/monitoring/telemetry software I've had the pleasure of working with.
Our Linux devops engineer, who had not used Sentry before, set up a self-hosted Sentry in a day.
> Our Linux devops engineer, who had not used Sentry before, set up a self-hosted Sentry in a day.

I've also spent 1 hour setting up a Kubernetes cluster on a set of desktops I had lying around. This does not mean Kubernetes is simple or easy.

It’s easy to setup but painful to keep running and it’s hard to backup.
Yeah, it works for a time, but they don't support on-premise versions and they don't offer a Helm chart install, its all community based.

I tried it for well over a year, and there are so many moving parts and so many "best guesses" from the community that we had to rip it out. There's a lot of components, sentry, sentry-relay, snuba, celery, redis, clickhouse, zookeeper (for clickhouse), kafka, zookeeper (for kafka), maybe even elasticsearch for good measure. It did work for a time, but there are so many moving parts that required care and feeding it would inevitably break down at some point.

Problem is I can't ship data to their SaaS version because we have PHI and our contracts forbid it, even if scrubbed, so I had to settle on OTEL.

PostHog and Rudderstack say the same things. They're not really self hosted. But that's the rub, if someone authored a good operator for Sentry, Sentry as a commercial service would cease to exist. That's not good in my opinion, they do real innovative stuff.

It's tough. We should have never done "give away the software, charge for hosting." The market, in every sense, has been telling you that you're really building value for AWS, for years, by doing that.

But not foss. It's using the BSL or FSL or whatever.
Although I do not like those licences, I would not care so much about 2yrs until it goes FOSS. Before all this rush development RRDTool and OpenTSDB was so slow, this whole thing seems rather ideological than substantial criticism. Now going down the licence rabbit hole based to criticise the original argument seems like a classical strawman.
Just want to say I appreciate your stance.

(also no one should feel like they have to contribute to our SDKs, but please file a ticket if somethings fucked up and we'll deal w/ it)

I was supporting a variation in my head of the "Yeah but who wants to contribute to an SDK for a service that you need to pay for?" claim.

You can self-host for free, so maybe @hahn-kev don't mind contributing to the SDK now.

For me, I refuse to contribute to an open-source SDK for a non-foss product. And I refuse to self-host a non-foss product.

Personally, I don't care if non-foss licenses speeds development. So yeah in my case it's ideological.

If I'm using something for employment, and the employer would get value out of it getting a bug fixed, why would I not fix it?
Sentry provides a great hosted service. You can self host if you like, but it’s nicer to let them do it
I've been using GlitchTip https://glitchtip.com with the Sentry SDKs and I couldn't be happier. Completely self-hosted, literally just the container and a db, requires zero attention.