[edweis]

Nice, thank you for the insight.

I can tell that the on-premises will be deployed on AWS accounts. We can manage the resources ourselves.

We have few fanouts that can be refactored. So Redis/Valkey for SQS is OK, hopefully it can also cover our SNS use case.

I am afraid Kubernetes is overkill for our lambda needs.

If we manage to bundle our whole app in one server and have only 1-2 clients on -premise, do you still suggest Kubernetes or a simpler rsync on all servers is enough?

Also, should we have a separate database instance for each client, or a Postgres cluster sharded? The latter seams more manageable.

[adamcharnock]

> If we manage to bundle our whole app in one server and have only 1-2 clients on -premise, do you still suggest Kubernetes or a simpler rsync on all servers is enough?

rsync is nice and simple. Personally I'd say at least use Ansible, with its built-in rsync support. Then you can do more than just copy files.

> Also, should we have a separate database instance for each client, or a Postgres cluster sharded? The latter seams more manageable.

Depends on the size. Run postgres separately for your on-prem clients. For your cloud clients, I'd say keep them on the same server until you start to get over 100GB-1TB of data, then start to think about sharding. RDS gets super expensive, so sharing too early may be uneconomical.

> I am afraid Kubernetes is overkill for our lambda needs.

For just Lambda, I agree. But if running everything outside of AWS (i.e. racking servers) then it shines, because then you have your app, postgres, valkey, etc, all balanced between servers.

[edweis]

Thank you again, this is gold. We'll do a POC with 1-2 services and see how it goes.