<p>Based upon my understanding you essentially have a <a href="https://docs.microsoft.com/en-us/azure/architecture/best-practices/data-partitioning" rel="nofollow noreferrer">Data Partitioning</a> problem, in that you need to maintain a degree of separation between each of your customers but also host the service centrally.</p>

<p>You have suggested that you instantiate a Docker container for each of your customers, I think there are a couple of issues with this:</p>

<ol>
<li>Containers are designed to be somewhat ephemeral, you can use some of the <a href="https://kubernetes.io/docs/tasks/run-application/run-single-instance-stateful-application/" rel="nofollow noreferrer">concepts within Kubernetes</a> to effectively create a singleton per customer, however:

<ol>
<li>Availability will likely be hurt by virtue of it being a singleton if the pod, node or cluster fails then that pod will need to be rescheduled.</li>
<li>The cost is likely to be quite high, as each of those containers will consume some resources regardless of whether they are being used or not.</li>
</ol></li>
<li>Depending on how many customers you have, you get into the realms of too many containers:

<ol>
<li>Orchestrators such as Kubernetes, Docker Swarm and Mesosphere are generally designed to support a large number of containers, however, the expectation is that's lots of the same workload not lots of disparate workloads. Kubernetes has in the past <a href="https://github.com/kubernetes/kubernetes/issues/74412" rel="nofollow noreferrer">experienced slowdown</a> when lots of ConfigMaps, Pods and CustomResourceDefinitions are deployed.</li>
<li>Whilst lightweight each container will consume system resources, not just Memory, CPU but also TCP/IP pool exhaustion.</li>
</ol></li>
<li>Isolation - containers are a good way to isolate workloads from each other, but it's not infallible - Read <a href="https://www.docker.com/blog/containers-are-not-vms/" rel="nofollow noreferrer">Containers are not VMs</a></li>
</ol>

<p>If I were to approach your problem I would be inclined to use Kubernetes as a Microservices platform hosting your application across <a href="https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/" rel="nofollow noreferrer">multiple ReplicaSets</a> then implement your partitioning at the datastore level in AWS via DynamoDB and EFS.  You are already encrypting your data so you have cryptographic certainty that isolation can be achieved.</p>

CC BY-SA 4.0
2019-10-22T15:36:11.427Z
2019-10-22T15:36:11.427Z
Richard Slater
<p>Please help me here based on your experiences.</p>

<p>We have launched a desktop application where users can download all their online data from several platforms at one place. Our motto is to provide users access to their digital footprint so that they can utilize it in their own different ways.The whole idea of desktop application is to put privacy first, Our servers only have access to the users login information and never had access to the users data, which is also encrypted at rest on users machine with user's mnemonic.</p>

<p>Based on the users feedback, We have realized that most of the users did like our platform but they don't want to bear the hassle of installing a desktop application. For them, Making use of their data (search, organize etc) is more important than military grade privacy.</p>

<p>As a result, we have decided to provide both the options to the user, Desktop application as well as web app.</p>

<p>Now shifting such a huge data on users machine (around 50GB to 1 TB for single user) to common database on cloud would be a cumbersome task, In terms of servers required for replication, sharding , caching etc, their costs and complexities which comes with data at scale.</p>

<p>Our Approach:</p>

<p>We are thinking to maintain docker containers for every user with their storage on Elastic file system on AWS. Data on rest on EFS for a container will always be encrypted with user's mnemonic and will only be decrypted on successful users login.</p>

<p>Every user docker container will have a small SQLite database to make this data searchable and indexed. In future, containers can also have their own Elastic search database with any other NoSql or Sql database.</p>

<p>The identities of the users can be put of AWS Cognito or Any decentralized identity system.</p>

<p>One other approach could be: Instead of running dockers we can keep different encrypted SQLITE DB for different users.</p>

<p>It would be a problem because then we have to keep track of all the SQLite db files present being accessed by the user, because SQLite doesnt support multi threading, we cannot open different instances of same SQLite database,</p>

<p>In case of docker, We will only spin docker when user logs in, that ways we always know that only one instance of SQLite is being accessed.</p>

<p>Our worry: We are still trying to figure out loopholes in this approach. Please help us in identifying the same.</p>

<p>Note: <a href="https://aws.amazon.com/blogs/containers/welcome-to-the-aws-containers-blog/" rel="nofollow noreferrer">https://aws.amazon.com/blogs/containers/welcome-to-the-aws-containers-blog/</a></p>

<docker><amazon-web-services><containers>
Container for every user
GraphicalDot
# Container for every user

(Asked by: username_0 on 2019-10-22)

Please help me here based on your experiences.

We have launched a desktop application where users can download all their online data from several platforms at one place. Our motto is to provide users access to their digital footprint so that they can utilize it in their own different ways.The whole idea of desktop application is to put privacy first, Our servers only have access to the users login information and never had access to the users data, which is also encrypted at rest on users machine with user's mnemonic.

Based on the users feedback, We have realized that most of the users did like our platform but they don't want to bear the hassle of installing a desktop application. For them, Making use of their data (search, organize etc) is more important than military grade privacy.

As a result, we have decided to provide both the options to the user, Desktop application as well as web app.

Now shifting such a huge data on users machine (around 50GB to 1 TB for single user) to common database on cloud would be a cumbersome task, In terms of servers required for replication, sharding , caching etc, their costs and complexities which comes with data at scale.

Our Approach:

We are thinking to maintain docker containers for every user with their storage on Elastic file system on AWS. Data on rest on EFS for a container will always be encrypted with user's mnemonic and will only be decrypted on successful users login.

Every user docker container will have a small SQLite database to make this data searchable and indexed. In future, containers can also have their own Elastic search database with any other NoSql or Sql database.

The identities of the users can be put of AWS Cognito or Any decentralized identity system.

One other approach could be: Instead of running dockers we can keep different encrypted SQLITE DB for different users.

It would be a problem because then we have to keep track of all the SQLite db files present being accessed by the user, because SQLite doesnt support multi threading, we cannot open different instances of same SQLite database,

In case of docker, We will only spin docker when user logs in, that ways we always know that only one instance of SQLite is being accessed.

Our worry: We are still trying to figure out loopholes in this approach. Please help us in identifying the same.

Note: <https://aws.amazon.com/blogs/containers/welcome-to-the-aws-containers-blog/>

**Tags:** docker, amazon-web-services, containers


---

## 1 answers

### Answer by username_1 on 2019-10-22. Score: 2

Based upon my understanding you essentially have a [Data Partitioning](https://docs.microsoft.com/en-us/azure/architecture/best-practices/data-partitioning) problem, in that you need to maintain a degree of separation between each of your customers but also host the service centrally.

You have suggested that you instantiate a Docker container for each of your customers, I think there are a couple of issues with this:

1. Containers are designed to be somewhat ephemeral, you can use some of the [concepts within Kubernetes](https://kubernetes.io/docs/tasks/run-application/run-single-instance-stateful-application/) to effectively create a singleton per customer, however:
   1. Availability will likely be hurt by virtue of it being a singleton if the pod, node or cluster fails then that pod will need to be rescheduled.
   2. The cost is likely to be quite high, as each of those containers will consume some resources regardless of whether they are being used or not.
2. Depending on how many customers you have, you get into the realms of too many containers:
   1. Orchestrators such as Kubernetes, Docker Swarm and Mesosphere are generally designed to support a large number of containers, however, the expectation is that's lots of the same workload not lots of disparate workloads. Kubernetes has in the past [experienced slowdown](https://github.com/kubernetes/kubernetes/issues/74412) when lots of ConfigMaps, Pods and CustomResourceDefinitions are deployed.
   2. Whilst lightweight each container will consume system resources, not just Memory, CPU but also TCP/IP pool exhaustion.
3. Isolation - containers are a good way to isolate workloads from each other, but it's not infallible - Read [Containers are not VMs](https://www.docker.com/blog/containers-are-not-vms/)

If I were to approach your problem I would be inclined to use Kubernetes as a Microservices platform hosting your application across [multiple ReplicaSets](https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/) then implement your partitioning at the datastore level in AWS via DynamoDB and EFS. You are already encrypting your data so you have cryptographic certainty that isolation can be achieved.


---

