| ▲ | seanwilson 2 days ago |
| > we don’t necessarily recommend self-hosting to everyone. In addition to existing hidden costs, as Sentry evolves, our self-hosted version will become more complex, demanding additional types of infrastructure. Any insights on why Sentry is so complex and needs so much resources? Is collecting, storing, and organizing errors messages and stack traces at scale difficult? Or it's the other features on top of this? |
|
| ▲ | eitland 2 days ago | parent | next [-] |
| Some ideas: - they had enough money that they never needed to think seriously about maintenence cost, and the sales process was strokg enough to keep customers arriving anyway (look to Oracle for another example of hopelessly complicated installation process but people keep using it anyway) - at some point someone realized this was actually a feature: the more complicated it got, the harder it became to self host. And from that perspective it is a win-win for the company: they can claim it is open source without being afraid that most people will choose to self host. |
| |
| ▲ | vanschelven 2 days ago | parent [-] | | I'd say that the architecture that is desirable from the point of view of a large scale SaaS is very different than the one that's desirable from the point of view of a tool that just needs to work for a single organization. And since the SaaS is bringing in all the money, that's where the architecture follows. > actually a feature I would guess that for a few people people (e.g. the ones who made the scary visual of rising costs) this is explicitly so, but for most people it's more implied. i.e. I don't think anyone advanced their career with Sentry by making self-hosting easier. | | |
| ▲ | BYK 9 hours ago | parent [-] | | Well I actually did as I was literally hired for that and worked on it for almost 3 years :) |
|
|
|
| ▲ | slyall 2 days ago | parent | prev [-] |
| Anything gets complex at scale. This is the same software they us to host their SaaS system. Presumably has to scale to many thousands of customer and a huge number of events per second. They have all sorts of caching, autoscaling, distributed systems and other stuff thats complete overkill for all except that largest installation. Plus all sorts of software features only needed by a few customers and extra layers to be multi-customer. It's the difference between a hoop in your back yard and a NBA Stadium |
| |
| ▲ | seanwilson a day ago | parent [-] | | Is this a common architectural issue for self-hosted options from SaaS companies? As in, a huge SaaS company offers their product for self-hosting to individual companies, but it's not practical to self-host because the code is highly specialized for supporting hundreds of companies instead of just one? And it's hard to have an architecture that works well for just one and for hundreds? | | |
| ▲ | pebble a day ago | parent [-] | | It's more about scale than tenancy. Not many SaaS companies offer such an option in the first place but it is typical that the in-house product is the priority and the architectural decisions are made with that in mind firstly, and self-hosting second if at all. For example Sentry requires ClickHouse, Postgres, Kafka, and Redis presumably because they were the right tools for their needs and either they have the resources to operate them all or the money to buy the managed options from vendors. Also, the main concern people have with hosting Sentry is the sheer number of containers required but most of them are just consumers for different Kafka queues which again is presumably this way because Sentry ops prefers it this way, whether it be for fine tuning the scaling of each one or whatever the reason. What makes sense for a SaaS company rarely translates to sensible for self-hosting. |
|
|
