←back to thread

466 points blacktechnology | 1 comments | | HN request time: 0s | source
Show context
danpalmer ◴[] No.41834089[source]
Reading the deployment information, there's an interesting tension here with applications that target self-hosting.

Deploying this requires running 5 different open source servers (databases, proxies, etc), and 5 different services that form part of this suite. If I were self-hosting this in a company I now need to be an expert in lots of different systems and potentially how to scale them, back them up, etc. The trade-offs to be made here are very different to when architecting a typical SaaS backend, where this sort of architecture might be fine.

I've been going through this myself with a hobby project. I'm designing it for self-hosting, and it's a radically different way of working to what I'm used to (operating services just for my company). I've been using SQLite and local disk storage so that there's essentially just 2 components to operate and scale – application replicas, and shared disk storage (which is easy to backup too). I'd rather be using Postgres, I'd rather be using numerous other services, background queue processors, etc, but each of those components is something that my users would need to understand, and therefore something to be minimised far more strictly than if it were just me/one team.

Huly looks like a great product, but I'm not sure I'd want to self-host.

replies(28): >>41834100 #>>41834175 #>>41834204 #>>41834282 #>>41834308 #>>41834334 #>>41834356 #>>41834450 #>>41834538 #>>41834603 #>>41834672 #>>41834792 #>>41834861 #>>41834865 #>>41834973 #>>41835133 #>>41835222 #>>41835339 #>>41835929 #>>41835949 #>>41836134 #>>41836856 #>>41836958 #>>41838118 #>>41839489 #>>41840080 #>>41876861 #>>41905212 #
crabmusket ◴[] No.41834356[source]
This reminds me of Sentry. This podcast interview had an interesting discussion of self-hosting: https://www.flagsmith.com/podcast/sentry

> In terms of how much thought and design you put into the self-hosted story, this is one of the things that we've been slowly realizing that every time the product gets more complex and the infrastructure required that run it gets more complex. As soon as you include a time series database, then that's adding another ratchet up of complexity if you're self-hosting it, but more outside of docker name. How much did you have that in your mind when you were designing the platform?

> I would say that's changed a lot over time. Early on, Sentry’s goal was to adapt to infrastructure. We use Django. We’ve got support for different databases out of the box, SQLite, Postgres, MySQL. MySQL is going all this other stuff at some point too. We had that model early on. ... Our whole goal, and this is still the goal of the company, we want everybody to be able to use Sentry. That's why the open source thing is also critical for us. Adapting infrastructure is one way to do that. Now, we changed our mind on that because what that turned into is this mess of, we have to support all these weird edge cases, and nobody is informed about how to do things. We're like, “That's all dead. We only support Postgres.” Key value is still a little bit flexible. It's hard to mess up key values. We're like, “You can write an adapter. We only support Redis for this thing. We use a technology called Cortana. We only support ClickHouse for this thing.” We're over this era of, “Can we adapt it because it looks similar?” and it made our lives so much better.

replies(1): >>41834954 #
1. NetOpWibby ◴[] No.41834954[source]
Venture-backed open-source typically wants the software to run everywhere because some percentage of devs will have the power to get the enterprise they work for to shell out $$$ for the hosted service.

Great for short/medium-term but unsustainable long-term.