Answers: <p>The process I'll called as service here, <strong>1 container ~ 1 service</strong>, if any of my service is failed then I'll only spin up that respective container and with-in seconds everything is up again. So, there won't be any dependencies between services. It is best practice to keep your container size less than 200 MB and max 500 MB (exception to windows native containers are more than 2 GB's) otherwise, its going to be the similar as virtual machine, not exactly but, performance suffice. Also, take into consideration few parameters as scaling, how could I make my services resilience, auto-deploy, etc.</p>
  
  <p>And, its purely your call how you need to make your architectural patterns like micro-service in polygot environment using the containers technology that best suite your environment and will automate the things for you.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-11-18T07:12:23.263Z
Answers: 2017-11-18T07:12:23.263Z
Answers: mohan08p
Answers: <p>Having slain a &quot;two processes&quot; container a few days ago, there are some pain points for me which caused me to use two container instead of a python script that started two processes:</p>
  <ol>
  <li><p>Docker is good at recognizing crashed containers. It can't do that when the main process looks fine, but some other process died a gruesome death. Sure, you can monitor your process manually, but why reimplement that?</p>
  </li>
  <li><p>docker logs gets a lot less useful when multiple processes are spewing their logs to the console. Again, you can write the process name to the logs, but docker can do that, too.</p>
  </li>
  <li><p>Testing and reasoning about a container gets a lot harder.</p>
  </li>
  </ol>
  
Answers: CC BY-SA 3.0
Answers: 2018-01-15T19:07:10.707Z
Answers: This should be the accepted answer.
Answers: ClintM
Answers: CC BY-SA 3.0
Answers: 2018-03-06T17:09:04.173Z
Answers: Agreed. While there are some other answers with some great points, the key point is about docker's handling of PID 1.
Answers: Brett Wagner
Answers: CC BY-SA 4.0
Answers: 2019-12-01T01:00:15.007Z
Answers: This and the answer by Jon that was accepted are the combined right answer. I finally truly get why one process or function or PID is the *right* thing to do. Theory above and practical here. I would not have bought in with out both of them together. Thank you both.
Answers: Michael McGarrah
Answers: CC BY-SA 4.0
Answers: 2017-08-31T14:18:50.697Z
Answers: 2021-02-08T06:47:21.160Z
Answers: 2021-02-08T06:47:21.160Z
Answers: Christian Sauer
Answers: <p>The recommendation comes from the goal and design of the <a href="https://en.wikipedia.org/wiki/Operating-system-level_virtualization" rel="noreferrer">Operating-system-level virtualization</a></p>
  <p>Containers have been designed to isolate a process for others by giving it its own <a href="https://en.wikipedia.org/wiki/User_space" rel="noreferrer">userspace</a> and filesystem.</p>
  <p>This is the logical evolution of <code>chroot</code> which was providing an isolated filesystem, the next step was isolating processes from the others to avoid memory overwrites and allowing to use the same resource (I.e TCP port 8080 for example) from multiple processes without conflicts.</p>
  <p>The main interest in a container it to package the needed library for the process without worrying about version conflicts.
  If you run multiples processes needing two versions of the same library in the same userspace and filesystem, you'd had to tweak at least LDPATH for each process so the proper library is found first, and some libraries can't be tweaked this way, because their path is hard coded in the executable at compilation time, see <a href="https://stackoverflow.com/questions/847179/multiple-glibc-libraries-on-a-single-host">this SO question</a> for more details.<br />
  At the network level you'll have to configure each process to avoid using the same ports.</p>
  <p>Running multiple processes in the same container require some heavy tweaking and at the end of the day defeat the purpose of isolation, if you are ok to run multiples processes within the same userspace, sharing the same filesytem and network resources, then why not run them on the host itself?</p>
  <p>Here is the non exhaustive list of the heavy tweaking/pitfalls I can think of:</p>
  <ul>
  <li><p>Handling the logs</p>
  <p>Either being with a mounted volume or interleaved on stdout this brings some management. If using a mounted volume your container should have its own &quot;place&quot; on host or two same containers will fight for the same resource. When interleaving on stdout to take advantage of <code>docker logs</code> it can become a nightmare for analysis if the sources can't be identified easily.</p>
  </li>
  <li><p>Beware of zombie processes</p>
  <p>If one of your process in a container crashes, supervisord may not be able to clean up the children in a zombie state, and the host init will never inherit them. Once you exhausted the number of available pids (2^22 so roughly 4 millions) a bunch of things will fail.</p>
  </li>
  <li><p>Separation of concerns</p>
  <p>If you run two separated things, like an apache server and logstash within the same container, that may ease the log handling, but you have to shutdown apache to update logstash. (In reality, you should use the logging driver of Docker)</p>
  <p>Will it be a graceful stop waiting the current sessions to end or not ? If it's a graceful stop, it may take sometime and become long to roll the new version. If you do a kill, you'll impact users for a log shipper and that should be avoided IMHO.</p>
  </li>
  </ul>
  <p>Finally when you have multiple processes you're reproducing an OS, and in this case using a hardware virtualization sounds more in line with this need.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-09T13:51:05.263Z
Answers: I find these arguments unconvincing. There is a huge difference between a process with multiple containers and running on host. While explaining the original intention of containers is somewhat relevant, it's not really a compelling reason to avoid multi-process containers. IOW, you're answering "why not" with "why yes", which isn't as helpful as it could be. It can be very convenient to run multiple processes in the same container - that's the why yes. The why not remains to be explained.
Answers: Assaf Lavie
Answers: CC BY-SA 3.0
Answers: 2017-03-09T14:05:08.210Z
Answers: @AssafLavie why does "Running multiple processes in the same container require some heavy tweaking and at the end of the day defeat the purpose of isolation, " doesn't explain the not ? I don't really get what you find missing
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-03-09T15:58:19.450Z
Answers: You haven't elaborated on the kind of tweaking you had in mind. And you haven't made the case that this tweaking is more work than setting up multiple containers. Let's take a concrete example: you often see packaged docker images that have supervisord running some main process and some auxiliary process. This is very easy to set up; arguably just as easy as separating the containers. e.g. app & log shipper. So, the onus is on your part, I believe, to argue why this isn't the case.
Answers: Assaf Lavie
Answers: CC BY-SA 3.0
Answers: 2017-03-09T16:00:13.390Z
Answers: BTW, I do believe there are valid arguments against multi-process containers, but you did not mention any of them. But in any case, it's far from being a clear cut case. In some instances it's perfectly acceptable to allow more than one process. Heck, some very popular images spawn several sub-process - is that evil as well? What I'm saying is there are trade-offs, and your answer paints a one-sided picture that lacks nuance and detail.
Answers: Assaf Lavie
Answers: CC BY-SA 3.0
Answers: 2017-03-09T16:03:21.493Z
Answers: @AssafLavie Fair enough, supervisord is the heavy tweaking in itself, the fact it is pre-baked doesn't remove it's a twist from the original goal. But I see your point (and agree it's not a binary choice) I was more on the why it should be avoided, I'll see to bring some more references when I have time.
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-03-10T11:12:50.953Z
Answers: @AssafLavie I've expended my point of view, is it better ?
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-03-13T15:16:37.057Z
Answers: @Pierre.Vriens No I've no idea who it is from and I don't really care to be honest. If someone find this not useful he/she's allowed to, I'll live with it :) But sure a reason for the downvote would be great just to know the why, if it's because of the wording or just because the person disagree. for the wording I can try again to express it differently, if it's disagreement, well, end of talk ;)
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-03-13T15:55:07.027Z
Answers: interesting ... It sounds like we have similar (identical) opinion on this. Maybe you should just ignore it in this case, because it was from somebody who wanted to earn the [Critic badge](http://devops.stackexchange.com/help/badges/7/critic) ... and decided to abuse your answer to get that badge ...
Answers: Pierre.Vriens
Answers: CC BY-SA 3.0
Answers: 2017-03-13T20:32:49.380Z
Answers: @Pierre.Vriens don't rush to conclusion, Jon answer is clearly in favor of using concern instead of process, this doesn't mean the downvoter did downvote this answer for a badge because he prefer the concern approach, he may have downvoted something else in this timeframe or maybe because he thinks this answer is not useful, or another reason. Truth is you can't read minds :) And I'm against early conclusion (even if I fall into this trap sometimes)
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-03-13T20:49:41.873Z
Answers: I don't "rush" to conclusion ... I just recommend you to ignore it. But "you" cannot change my mind on what I have seen with my own eyes about who the anonymous downvoter of your answer is. Anyway, time to move on ...
Answers: Pierre.Vriens
Answers: CC BY-SA 4.0
Answers: 2017-03-09T08:59:14.877Z
Answers: 2021-02-08T06:31:45.923Z
Answers: 2021-02-08T06:31:45.923Z
Answers: Tensibai
Answers: <p>As in most cases, it's not all-or-nothing.  The guidance of "one process per container" stems from the idea that containers should serve a distinct purpose.  For example, a container should not be both a web application <em>and</em> a Redis server.</p>
  
  <p>There are cases where it makes sense to run multiple processes in a single container, as long as both processes support a single, modular function.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-09T14:50:56.233Z
Answers: 2017-03-09T14:50:56.233Z
Answers: Dave Swersky
Answers: <p>Lets forget the high-level architectural and philosophical arguments for a moment. While there may be some edge cases where multiple functions in a single container may make sense, there are very practical reasons why you may want to consider following "one function per container" as a rule of thumb:</p>
  
  <ul>
  <li>Scaling containers horizontally is much easier if the container is isolated to a single function. Need another apache container? Spin one up somewhere else. However if my apache container also has my DB, cron and other pieces shoehorned in, this complicates things.</li>
  <li>Having a single function per container allows the container to be easily re-used for other projects or purposes. </li>
  <li>It also makes it more portable and predictable for devs to pull down a component from production to troubleshoot locally rather than an entire application environment.</li>
  <li>Patching/upgrades (both the OS and the application) can be done in a more isolated and controlled manner. Juggling multiple bits-and-bobs in your container not only makes for larger images, but also ties these components together. Why have to shut down application X and Y just to upgrade Z?
  
  <ul>
  <li>Above also holds true for code deployments and rollbacks. </li>
  </ul></li>
  <li>Splitting functions out to multiple containers allows more flexibility from a security and isolation perspective. You may want (or require) services to be isolated on the network level -- either physically or within overlay networks -- to maintain a strong security posture or comply with things like PCI. </li>
  <li>Other more minor factors such as dealing with stdout/stderr and sending logs to the container log, keeping containers as ephemeral as possible etc.</li>
  </ul>
  
  <p>Note that I'm saying function, not process. That language is outdated. The official docker documentation <a href="https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#general-guidelines-and-recommendations" rel="noreferrer">has moved away</a> from saying "one process" to instead recommending "one concern" per container. </p>
  
Answers: CC BY-SA 3.0
Answers: 2017-11-19T17:50:03.223Z
Answers: Still, it seems the low-level argument against threads fits here... http://web.stanford.edu/~ouster/cgi-bin/papers/threads.pdf
Answers: jeffmcneill
Answers: CC BY-SA 4.0
Answers: 2019-04-30T19:27:58.127Z
Answers: Is the idea that the question didn't really mean 'process' in the OS sense - that docker and related writings were using a different terminology that has now been clarified by switching to the word 'function'?  Because otherwise, while I acknowledge that this is the accepted and highest rated answer, I don't think it answers the question that was asked.
Answers: Tom
Answers: CC BY-SA 4.0
Answers: 2019-10-30T12:43:12.807Z
Answers: Concerns may not always correspond 1:1 to processes. What if I have a cron job to do somnething about my service? The job is not independent from the service. But I know folks who make a container for litteraly every unix process with no cheating. And they keep chanting one process=one container mantra as a justification to do this. Something seems off to me.
Answers: Gherman
Answers: CC BY-SA 3.0
Answers: 2017-03-09T15:30:06.530Z
Answers: 2017-03-09T15:30:06.530Z
Answers: Jon
Body: <p>In many blog posts, and general opinion, there is a saying that goes "one process per container".</p>
  
  <p>Why does this rule exist?
  Why not run ntp, nginx, uwsgi and more processes in a single container that needs to have all processes to work?</p>
  
  <p>blog posts mentioning this rule:</p>
  
  <ul>
  <li><a href="https://runnable.com/docker/rails/run-multiple-processes-in-a-container" rel="noreferrer">"Single-­process-­per-­container is a recommended design pattern for Docker applications."</a></li>
  <li><a href="https://blog.codeship.com/using-honcho-create-multi-process-docker-container/" rel="noreferrer">"Docker is only for creating single-process or single-service containers."</a></li>
  <li><a href="https://stackoverflow.com/questions/30003338/docker-one-process-per-container">"better to use one process per container"</a></li>
  <li><a href="https://blog.risingstack.com/operating-system-containers-vs-application-containers/" rel="noreferrer">"Run a single service as a container"</a></li>
  <li><a href="https://getcarina.com/docs/best-practices/container-design-philosophy/" rel="noreferrer">"One process per container"</a></li>
  <li><a href="https://github.com/docker/docker.github.io/pull/1418" rel="noreferrer">"one process per container"</a></li>
  </ul>
  
Comments: CC BY-SA 3.0
Comments: 2017-09-01T03:10:12.397Z
Comments: But - would it be okay to have a very "fat" container with dozens of processes in order to stage a rollout and operation of an enterprise server which still can't have Docker?
Comments: Ta Mu
Comments: CC BY-SA 3.0
Comments: 2017-09-01T09:51:04.547Z
Comments: @J.Doe it will probably not be okay. containers are different than VMs, there are multiple small problems even for a small application - for an enterprise rollout it will be a two year project get it all to run in a container in the first place.
Comments: Evgeny Zislis
Tags: <docker><containers>
Title: Why it is recommended to run only one process in a container?
UserDisplayName: Evgeny Zislis
ThreadText: # Why it is recommended to run only one process in a container?
  
  (Asked by: username_0 on 2017-03-09)
  
  In many blog posts, and general opinion, there is a saying that goes "one process per container".
  
  Why does this rule exist?
  Why not run ntp, nginx, uwsgi and more processes in a single container that needs to have all processes to work?
  
  blog posts mentioning this rule:
  
  * ["Single-­process-­per-­container is a recommended design pattern for Docker applications."](https://runnable.com/docker/rails/run-multiple-processes-in-a-container)
  * ["Docker is only for creating single-process or single-service containers."](https://blog.codeship.com/using-honcho-create-multi-process-docker-container/)
  * ["better to use one process per container"](https://stackoverflow.com/questions/30003338/docker-one-process-per-container)
  * ["Run a single service as a container"](https://blog.risingstack.com/operating-system-containers-vs-application-containers/)
  * ["One process per container"](https://getcarina.com/docs/best-practices/container-design-philosophy/)
  * ["one process per container"](https://github.com/docker/docker.github.io/pull/1418)
  
  **Tags:** docker, containers
  
  > **Comments:**
  > **username_1**: But - would it be okay to have a very "fat" container with dozens of processes in order to stage a rollout and operation of an enterprise server which still can't have Docker?  
  > **username_0**: @J.Doe it will probably not be okay. containers are different than VMs, there are multiple small problems even for a small application - for an enterprise rollout it will be a two year project get it all to run in a container in the first place.  
  
  ---
  
  ## 5 answers
  
  ### Answer by username_11 on 2017-03-09. Score: 123 | Accepted answer
  
  Lets forget the high-level architectural and philosophical arguments for a moment. While there may be some edge cases where multiple functions in a single container may make sense, there are very practical reasons why you may want to consider following "one function per container" as a rule of thumb:
  
  * Scaling containers horizontally is much easier if the container is isolated to a single function. Need another apache container? Spin one up somewhere else. However if my apache container also has my DB, cron and other pieces shoehorned in, this complicates things.
  * Having a single function per container allows the container to be easily re-used for other projects or purposes.
  * It also makes it more portable and predictable for devs to pull down a component from production to troubleshoot locally rather than an entire application environment.
  * Patching/upgrades (both the OS and the application) can be done in a more isolated and controlled manner. Juggling multiple bits-and-bobs in your container not only makes for larger images, but also ties these components together. Why have to shut down application X and Y just to upgrade Z?
    + Above also holds true for code deployments and rollbacks.
  * Splitting functions out to multiple containers allows more flexibility from a security and isolation perspective. You may want (or require) services to be isolated on the network level -- either physically or within overlay networks -- to maintain a strong security posture or comply with things like PCI.
  * Other more minor factors such as dealing with stdout/stderr and sending logs to the container log, keeping containers as ephemeral as possible etc.
  
  Note that I'm saying function, not process. That language is outdated. The official docker documentation [has moved away](https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#general-guidelines-and-recommendations) from saying "one process" to instead recommending "one concern" per container.
  
  > **Comments:**
  > **username_12**: Still, it seems the low-level argument against threads fits here... http://web.stanford.edu/~ouster/cgi-bin/papers/threads.pdf  
  > **username_13**: Is the idea that the question didn't really mean 'process' in the OS sense - that docker and related writings were using a different terminology that has now been clarified by switching to the word 'function'?  Because otherwise, while I acknowledge that this is the accepted and highest rated answer, I don't think it answers the question that was asked.  
  > **username_14**: Concerns may not always correspond 1:1 to processes. What if I have a cron job to do somnething about my service? The job is not independent from the service. But I know folks who make a container for litteraly every unix process with no cheating. And they keep chanting one process=one container mantra as a justification to do this. Something seems off to me.  
  
  ---
  
  ### Answer by username_3 on 2017-08-31. Score: 67
  
  Having slain a "two processes" container a few days ago, there are some pain points for me which caused me to use two container instead of a python script that started two processes:
  
  1. Docker is good at recognizing crashed containers. It can't do that when the main process looks fine, but some other process died a gruesome death. Sure, you can monitor your process manually, but why reimplement that?
  2. docker logs gets a lot less useful when multiple processes are spewing their logs to the console. Again, you can write the process name to the logs, but docker can do that, too.
  3. Testing and reasoning about a container gets a lot harder.
  
  > **Comments:**
  > **username_4**: This should be the accepted answer.  
  > **username_5**: Agreed. While there are some other answers with some great points, the key point is about docker's handling of PID 1.  
  > **username_6**: This and the answer by Jon that was accepted are the combined right answer. I finally truly get why one process or function or PID is the *right* thing to do. Theory above and practical here. I would not have bought in with out both of them together. Thank you both.  
  
  ---
  
  ### Answer by username_7 on 2017-03-09. Score: 21
  
  The recommendation comes from the goal and design of the [Operating-system-level virtualization](https://en.wikipedia.org/wiki/Operating-system-level_virtualization)
  
  Containers have been designed to isolate a process for others by giving it its own [userspace](https://en.wikipedia.org/wiki/User_space) and filesystem.
  
  This is the logical evolution of `chroot` which was providing an isolated filesystem, the next step was isolating processes from the others to avoid memory overwrites and allowing to use the same resource (I.e TCP port 8080 for example) from multiple processes without conflicts.
  
  The main interest in a container it to package the needed library for the process without worrying about version conflicts.
  If you run multiples processes needing two versions of the same library in the same userspace and filesystem, you'd had to tweak at least LDPATH for each process so the proper library is found first, and some libraries can't be tweaked this way, because their path is hard coded in the executable at compilation time, see [this SO question](https://stackoverflow.com/questions/847179/multiple-glibc-libraries-on-a-single-host) for more details.  
  At the network level you'll have to configure each process to avoid using the same ports.
  
  Running multiple processes in the same container require some heavy tweaking and at the end of the day defeat the purpose of isolation, if you are ok to run multiples processes within the same userspace, sharing the same filesytem and network resources, then why not run them on the host itself?
  
  Here is the non exhaustive list of the heavy tweaking/pitfalls I can think of:
  
  * Handling the logs
  
    Either being with a mounted volume or interleaved on stdout this brings some management. If using a mounted volume your container should have its own "place" on host or two same containers will fight for the same resource. When interleaving on stdout to take advantage of `docker logs` it can become a nightmare for analysis if the sources can't be identified easily.
  * Beware of zombie processes
  
    If one of your process in a container crashes, supervisord may not be able to clean up the children in a zombie state, and the host init will never inherit them. Once you exhausted the number of available pids (2^22 so roughly 4 millions) a bunch of things will fail.
  * Separation of concerns
  
    If you run two separated things, like an apache server and logstash within the same container, that may ease the log handling, but you have to shutdown apache to update logstash. (In reality, you should use the logging driver of Docker)
  
    Will it be a graceful stop waiting the current sessions to end or not ? If it's a graceful stop, it may take sometime and become long to roll the new version. If you do a kill, you'll impact users for a log shipper and that should be avoided IMHO.
  
  Finally when you have multiple processes you're reproducing an OS, and in this case using a hardware virtualization sounds more in line with this need.
  
  > **Comments:**
  > **username_8**: I find these arguments unconvincing. There is a huge difference between a process with multiple containers and running on host. While explaining the original intention of containers is somewhat relevant, it's not really a compelling reason to avoid multi-process containers. IOW, you're answering "why not" with "why yes", which isn't as helpful as it could be. It can be very convenient to run multiple processes in the same container - that's the why yes. The why not remains to be explained.  
  > **username_7**: @username_8 why does "Running multiple processes in the same container require some heavy tweaking and at the end of the day defeat the purpose of isolation, " doesn't explain the not ? I don't really get what you find missing  
  > **username_8**: You haven't elaborated on the kind of tweaking you had in mind. And you haven't made the case that this tweaking is more work than setting up multiple containers. Let's take a concrete example: you often see packaged docker images that have supervisord running some main process and some auxiliary process. This is very easy to set up; arguably just as easy as separating the containers. e.g. app & log shipper. So, the onus is on your part, I believe, to argue why this isn't the case.  
  > **username_8**: BTW, I do believe there are valid arguments against multi-process containers, but you did not mention any of them. But in any case, it's far from being a clear cut case. In some instances it's perfectly acceptable to allow more than one process. Heck, some very popular images spawn several sub-process - is that evil as well? What I'm saying is there are trade-offs, and your answer paints a one-sided picture that lacks nuance and detail.  
  > **username_7**: @username_8 Fair enough, supervisord is the heavy tweaking in itself, the fact it is pre-baked doesn't remove it's a twist from the original goal. But I see your point (and agree it's not a binary choice) I was more on the why it should be avoided, I'll see to bring some more references when I have time.  
  > **username_7**: @username_8 I've expended my point of view, is it better ?  
  > **username_7**: @username_9 No I've no idea who it is from and I don't really care to be honest. If someone find this not useful he/she's allowed to, I'll live with it :) But sure a reason for the downvote would be great just to know the why, if it's because of the wording or just because the person disagree. for the wording I can try again to express it differently, if it's disagreement, well, end of talk ;)  
  > **username_9**: interesting ... It sounds like we have similar (identical) opinion on this. Maybe you should just ignore it in this case, because it was from somebody who wanted to earn the [Critic badge](http://devops.stackexchange.com/help/badges/7/critic) ... and decided to abuse your answer to get that badge ...  
  > **username_7**: @username_9 don't rush to conclusion, Jon answer is clearly in favor of using concern instead of process, this doesn't mean the downvoter did downvote this answer for a badge because he prefer the concern approach, he may have downvoted something else in this timeframe or maybe because he thinks this answer is not useful, or another reason. Truth is you can't read minds :) And I'm against early conclusion (even if I fall into this trap sometimes)  
  > **username_9**: I don't "rush" to conclusion ... I just recommend you to ignore it. But "you" cannot change my mind on what I have seen with my own eyes about who the anonymous downvoter of your answer is. Anyway, time to move on ...  
  
  ---
  
  ### Answer by username_10 on 2017-03-09. Score: 11
  
  As in most cases, it's not all-or-nothing. The guidance of "one process per container" stems from the idea that containers should serve a distinct purpose. For example, a container should not be both a web application *and* a Redis server.
  
  There are cases where it makes sense to run multiple processes in a single container, as long as both processes support a single, modular function.
  
  
  ---
  
  ### Answer by username_2 on 2017-11-18. Score: 5
  
  The process I'll called as service here, **1 container ~ 1 service**, if any of my service is failed then I'll only spin up that respective container and with-in seconds everything is up again. So, there won't be any dependencies between services. It is best practice to keep your container size less than 200 MB and max 500 MB (exception to windows native containers are more than 2 GB's) otherwise, its going to be the similar as virtual machine, not exactly but, performance suffice. Also, take into consideration few parameters as scaling, how could I make my services resilience, auto-deploy, etc.
  
  And, its purely your call how you need to make your architectural patterns like micro-service in polygot environment using the containers technology that best suite your environment and will automate the things for you.
  
  
  ---
  
  