4 ms·

This is something I've noticed a lot of open core projects suffer from. They make architecture decisions that make sense for their huge, multi-tenant production

This is something I've noticed a lot of open core projects suffer from. They make architecture decisions that make sense for their huge, multi-tenant production system but correspondingly make self-hosting on a single node feel like administering a rube goldberg machine.

vbezhenar 4y ago
My opinion is that they optimize for huge deployments. Tiny companies are supposed to use cloud. And self-hosting is supposed to be used by big companies with thousands of people. I guess that's where their money is, anyway. That said, they're doing good job of documenting things required for smaller installations.
- totetsu 4y ago
  So true. I was in charge of setting up self hosted GitLab at tiny computer company. Was very proud of the cicd setup untill the boss asked for review apps to be launched for each commit. Gitlab had no solution for this but to use Kubernetes.
- mekster 4y ago
  Bullshit, the inability to properly optimize doesn't mean it's optimized well for huge deployments. It will need much more resource on huge deployments and still quite some RAM on small deployments too. At this point, the code base is too big for them to fix the performance and they want to use their time on new features and bug fixes as that's what customers are asking more while customers may solve the performance problem by spending more money on the server. It's just that the initial technical decisions sucked and it's no longer possible to fix it at this point.
  - deleted 4y ago
    [deleted]
mr-karan 4y ago
This is so true. Sentry's architecture[1] is insanely complex. It runs some ~30 containers on the instance and all you've to pray is that their tooling[2] for `docker-compose` _just works_. [1]: https://develop.sentry.dev/architecture/ https://develop.sentry.dev/architecture/ [2]: https://github.com/getsentry/self-hosted https://github.com/getsentry/self-hosted
- the_mitsuhiko 4y ago
  Armin from Sentry here: It's definitely something we're battling with. At the scale we're operating, providing all features on an alternative architecture that does not involve as many independent pieces is pretty tricky. I'm somewhat hopeful that we see reduction in the total types of moving pieces over time at least.
  - mekster 4y ago
    At least for our small use case, the web interface is snappy enough that it's just about spending more money to host it but I'd definitely like it to reduce its memory usage as I'll have to double the server size just for Sentry.
  - mr-karan 4y ago
    Hey Armin. That's very nice to hear that reduction is something on your roadmap. Pre Snuba, the number of external services were fairly limited but I understand as Sentry got more mature and added a bunch of extra services than "just error/crash reports" is when the architecture also sorta started to become complex.
    - the_mitsuhiko 4y ago
      It's not even just that there are extra services, it's that the volume of traffic is just too high for rabbitmq. So we put a bunch of kafka in and with that, the complexity quickly went up as you end up writing more and more consumers. Most of the services still mostly "just do crash and error reports" but they are doing it in more scalable ways now. Snuba is one of the services that largely really requires kafka to function though I think theoretically limited functionality is also available by directly talking HTTP to it.
Loic 4y ago
Some projects stay very lean. We are running our very small company on: - Gitea - Woodpecker CI - Self hosted private Docker registry - Minio They are easy to deploy and upgrade (the upgrade procedure is for me the most important because I want to do it easily or at the end you do not do it).

vbezhenar 4y ago

My opinion is that they optimize for huge deployments. Tiny companies are supposed to use cloud. And self-hosting is supposed to be used by big companies with thousands of people. I guess that's where their money is, anyway. That said, they're doing good job of documenting things required for smaller installations.

totetsu 4y ago
So true. I was in charge of setting up self hosted GitLab at tiny computer company. Was very proud of the cicd setup untill the boss asked for review apps to be launched for each commit. Gitlab had no solution for this but to use Kubernetes.
mekster 4y ago
Bullshit, the inability to properly optimize doesn't mean it's optimized well for huge deployments. It will need much more resource on huge deployments and still quite some RAM on small deployments too. At this point, the code base is too big for them to fix the performance and they want to use their time on new features and bug fixes as that's what customers are asking more while customers may solve the performance problem by spending more money on the server. It's just that the initial technical decisions sucked and it's no longer possible to fix it at this point.
- deleted 4y ago
  [deleted]

mr-karan 4y ago

This is so true. Sentry's architecture[1] is insanely complex. It runs some ~30 containers on the instance and all you've to pray is that their tooling[2] for `docker-compose` _just works_. [1]: https://develop.sentry.dev/architecture/ https://develop.sentry.dev/architecture/ [2]: https://github.com/getsentry/self-hosted https://github.com/getsentry/self-hosted

the_mitsuhiko 4y ago
Armin from Sentry here: It's definitely something we're battling with. At the scale we're operating, providing all features on an alternative architecture that does not involve as many independent pieces is pretty tricky. I'm somewhat hopeful that we see reduction in the total types of moving pieces over time at least.
- mekster 4y ago
  At least for our small use case, the web interface is snappy enough that it's just about spending more money to host it but I'd definitely like it to reduce its memory usage as I'll have to double the server size just for Sentry.
- mr-karan 4y ago
  Hey Armin. That's very nice to hear that reduction is something on your roadmap. Pre Snuba, the number of external services were fairly limited but I understand as Sentry got more mature and added a bunch of extra services than "just error/crash reports" is when the architecture also sorta started to become complex.
  - the_mitsuhiko 4y ago
    It's not even just that there are extra services, it's that the volume of traffic is just too high for rabbitmq. So we put a bunch of kafka in and with that, the complexity quickly went up as you end up writing more and more consumers. Most of the services still mostly "just do crash and error reports" but they are doing it in more scalable ways now. Snuba is one of the services that largely really requires kafka to function though I think theoretically limited functionality is also available by directly talking HTTP to it.

Loic 4y ago

Some projects stay very lean. We are running our very small company on: - Gitea - Woodpecker CI - Self hosted private Docker registry - Minio They are easy to deploy and upgrade (the upgrade procedure is for me the most important because I want to do it easily or at the end you do not do it).