> One such scenario that I've seen is companies running multi-tenancy services where clients don't share the same databases
That's our situation soon. We're about to start migrating away from a desktop win32 application.
Any good deployment options for such a scenario?
We're talking 4-500 customers with their own db, less than 10k users. On-premise installation must be possible (though "give us a VM" is what we currently do, so that might not be to different).
The other poster made some very reasonable suggestion. The answer is largely depend on your app architecture. For example, if it's as simple as an web-app + db, then docker compose image should be sufficient. Do your best to extract some of the more generic features such as email list, storage, log server out of your app and have a shared service for those if possible.
Honestly, managing on-prem VM is actually one of the easiest thing to do in my experience if the entire architecture is in a single bundle.
For the rest of your customers, you can still run K8s. If you aren't concern about scaling, then run webapp + db in a single pod. This is somewhat of an anti-pattern because it changes your ability to scale. If you do want to scale for an individual customer, then move db into its own pod, and then connect to it from your webapp.
Personally, I would rather run your ephemeral load such as webapp in K8s, then run databases on VMs to make it a bit easier to manage.
That's our situation soon. We're about to start migrating away from a desktop win32 application.
Any good deployment options for such a scenario?
We're talking 4-500 customers with their own db, less than 10k users. On-premise installation must be possible (though "give us a VM" is what we currently do, so that might not be to different).