[Feature] splitting the moonlit service to microservices architecture

[AdamRussak]

• if the services will be split it will be possible to have HA and LB features
• allowing deployment in Docker Swarm and K8S

I think it's kind of a standard today and I couldn't find it with Emby.

suggestions:
add Redis to cache data for active connections
adding a service like Appwrite to support RT-DB & DB management (could be supplied as advance features)

[softworkz]

1. Why?
2. What do you want to achieve?
3. In which way do you think that a PERSONAL media server would benefit form that kind of architecture?

[AdamRussak]

1. Why?
2. What do you want to achieve?
3. In which way do you think that a PERSONAL media server would benefit form that kind of architecture?

for many reasons:
a. allow modification of DB usage for advanced users
b. allowing LB and HA for multi-connection (i got 12TB of content been shared with 10+ family members)
my current wish is to set it up in my home K8S environment what is holding me back is:
a. allowing connections to "jump" between instances
b. shared DB for all servers instance
for any Advance user deployment there should be a more modular and micro-service approach to deploy docker services (for now its a monolith packaged in a container)

[softworkz]

Thanks for the clarification.

Let us be honest: What you are talking about is not a personal media server setup - it's a professional media server deployment, so please don't try to sell me some "large-family-story".

I always had a lot of sympathy for going into this direction, and a bunch of ideas exist about how this could be done.
In the past, I have talked to a number of customers which have been asking for Emby to provide features in that direction, and the first thing I use to explain is this:

• Software development costs money - a lot of money
• Emby development is funded by its users - either subscription-wise or lifetime licenses
• When we develop new features, there needs to be a benefit for a wide range of our users
• What you are asking for, is something that at least 99.9% of Emby users do not want or need

You will surely understand that we can't let our regular users pay for implementing such kind of features.
Which means In turn, that there needs to be a different business model behind this, to back the development cost. It's a feature for very few only, and as such, it would require a totally different calculation of license cost. In other words: it would mean to add a few zeros behind the regular monthly fees for Emby Server.

Still interested?

[AdamRussak]

TNX for the honest answer.
just to be clear, I am using it only for my family and friends and got about 12+TB of content.
and I am also a DevOps engineer and wanted to host it on my K8S stack...but at its current build it's not efficient and I will leave it as a docker deployment.
and as for the payment, I am a premium user.

*do you want to close it? or is there a 0.1% chance it will happen?

[softworkz]

do you want to close it? or is there a 0.1% chance it will happen?

From those few who are using Emby in a more-or-less (semi-)professional way already, and to some of which I had talked to, I don't think it would suffice to fund this.
But there are still chances - it might take just a single strong industry customer to pave the way. There have been contacts and talks, and others may come in the future, so it's surely not a "never" and I'd say chances are >1% at least.

[AdamRussak]

good enough for me :)
ill keep it open...hopefully you will be peer-pressured into this ;)