Answers: <p>I can answer the 2nd point:</p>
  
  <p>Docker is most suited in a micro service based architecture when the application runs inside the containers but the storage or any other live sessions are maintained in shared RAM or the database. </p>
  
  <p>Basically you just should not store anything inside the docker container. There are many reasons to it:</p>
  
  <ol>
  <li><p>Consider upgrade: Someone from your team has created a newer image of the application and you need the container running with the latest image. The current docker and popular way of doing this is to bring the existing container down and spin a new container with the same run time parameters as the older container but with the newer image. This is one of the biggest reasons why containers should always be stateless and not contain any data. You can have all your data mounted to some place and sessions kept inside a db or something like memchached etc.</p></li>
  <li><p>One of the big use case of docker is to build clusters. If you start keeping data inside your containers then its an overhead to maintain that data in sync between the application containers.</p></li>
  <li><p>The docker community in general does not recommend to keep any data in container and hence nobody has tried taking this risk in production and nobody wants to be the first storyteller of how they messed up production :)</p></li>
  </ol>
  
Answers: CC BY-SA 3.0
Answers: 2017-07-28T11:51:25.030Z
Answers: 2017-07-28T18:26:49.187Z
Answers: 2017-07-28T18:26:49.187Z
Answers: lakshayk
Body: <p>I've recently started working for a company that wants to break their monolithic SaaS application up into containerized microservices. I'm having a hard time grasping a fundamental part of persistent storage, though. Why are there so many different competing platforms? Portworx, Rexray, StorageOS, Flocker, Inifint, etc.</p>
  
  <p><strong>My Questions</strong></p>
  
  <ol>
  <li><p>Why wouldn't someone simply spin up an NFS server and use a hierarchical folder structure there as their storage backend? What gains do you get when using one of these tools? </p></li>
  <li><p>How dangerous is it to use something like this with Docker? What are the common causes for catastrophic data loss in a docker-based environment?</p></li>
  <li><p>What persistent storage solution would you recommend and why? My company operates a SaaS platform. The data payloads are small in size (5kb-100kb). Data processing is small-medium in resource consumption. Overall volume is medium, but continues to grow. We're hoping to completely move our monolithic application to the cloud as separate containerized microservices. Including our data warehouse. </p></li>
  <li><p>Somewhat unrelated, but it ties in. What are the strengths of using Kubernetes as an orchestrator as opposed to Rancher/Cattle? Isn't Kubernetes over-engineered for a small-medium sized platform? Are there any strengths to using Kubernetes in Rancher aside from the one-click installation? </p></li>
  </ol>
  
  <p><em>Thank you for the insight. Sorry for the naivety. I welcome all documentation and supplemental reading material.</em></p>
  
  <p>EDIT: For context we are using Azure as our underlying Cloud platform.</p>
  
Comments: CC BY-SA 3.0
Comments: 2017-07-04T07:49:33.773Z
Comments: For the 4: Kubernetes play well with azure to create [Persistent Volumes as Azure Disk](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#azure-disk). NFS has a history of bad locking mechanism, in case of error in the orchestrator you may corrupt your files kinda easily.
Comments: Tensibai
Comments: CC BY-SA 3.0
Comments: 2017-07-12T15:37:18.963Z
Comments: teams I have worked with in this context have good experiences with Cassandra as storage backend for a set of mucroservices but the focus is rather on reading than on writing data
Comments: Ta Mu
Comments: CC BY-SA 3.0
Comments: 2017-07-28T17:55:27.207Z
Comments: What *kind* of data? Database data? Pictures? Text files?
Comments: James Shewey
Comments: CC BY-SA 3.0
Comments: 2017-07-28T18:06:47.657Z
Comments: Possibly related: https://devops.stackexchange.com/questions/742/what-practices-or-tools-enable-continuous-deployment-of-databases/1220#1220
Comments: James Shewey
Tags: <docker><kubernetes><storage><data><data-protection>
Title: Persistent Storage with Docker in Production - Which Solution and Why?
UserDisplayName: TJ Zimmerman
ThreadText: # Persistent Storage with Docker in Production - Which Solution and Why?
  
  (Asked by: username_0 on 2017-07-03)
  
  I've recently started working for a company that wants to break their monolithic SaaS application up into containerized microservices. I'm having a hard time grasping a fundamental part of persistent storage, though. Why are there so many different competing platforms? Portworx, Rexray, StorageOS, Flocker, Inifint, etc.
  
  **My Questions**
  
  1. Why wouldn't someone simply spin up an NFS server and use a hierarchical folder structure there as their storage backend? What gains do you get when using one of these tools?
  2. How dangerous is it to use something like this with Docker? What are the common causes for catastrophic data loss in a docker-based environment?
  3. What persistent storage solution would you recommend and why? My company operates a SaaS platform. The data payloads are small in size (5kb-100kb). Data processing is small-medium in resource consumption. Overall volume is medium, but continues to grow. We're hoping to completely move our monolithic application to the cloud as separate containerized microservices. Including our data warehouse.
  4. Somewhat unrelated, but it ties in. What are the strengths of using Kubernetes as an orchestrator as opposed to Rancher/Cattle? Isn't Kubernetes over-engineered for a small-medium sized platform? Are there any strengths to using Kubernetes in Rancher aside from the one-click installation?
  
  *Thank you for the insight. Sorry for the naivety. I welcome all documentation and supplemental reading material.*
  
  EDIT: For context we are using Azure as our underlying Cloud platform.
  
  **Tags:** docker, kubernetes, storage, data, data-protection
  
  > **Comments:**
  > **username_1**: For the 4: Kubernetes play well with azure to create [Persistent Volumes as Azure Disk](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#azure-disk). NFS has a history of bad locking mechanism, in case of error in the orchestrator you may corrupt your files kinda easily.  
  > **username_2**: teams I have worked with in this context have good experiences with Cassandra as storage backend for a set of mucroservices but the focus is rather on reading than on writing data  
  > **username_3**: What *kind* of data? Database data? Pictures? Text files?  
  > **username_3**: Possibly related: https://devops.stackexchange.com/questions/742/what-practices-or-tools-enable-continuous-deployment-of-databases/1220#1220  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_4 on 2017-07-28. Score: 4 | Accepted answer
  
  I can answer the 2nd point:
  
  Docker is most suited in a micro service based architecture when the application runs inside the containers but the storage or any other live sessions are maintained in shared RAM or the database.
  
  Basically you just should not store anything inside the docker container. There are many reasons to it:
  
  1. Consider upgrade: Someone from your team has created a newer image of the application and you need the container running with the latest image. The current docker and popular way of doing this is to bring the existing container down and spin a new container with the same run time parameters as the older container but with the newer image. This is one of the biggest reasons why containers should always be stateless and not contain any data. You can have all your data mounted to some place and sessions kept inside a db or something like memchached etc.
  2. One of the big use case of docker is to build clusters. If you start keeping data inside your containers then its an overhead to maintain that data in sync between the application containers.
  3. The docker community in general does not recommend to keep any data in container and hence nobody has tried taking this risk in production and nobody wants to be the first storyteller of how they messed up production :)
  
  
  ---
  
  