Pragmatic Docker Container Architecture Heuristics
To compose or not compose that is the question. When constructing a Docker stack for an application. One of the decision points you will come to is when and where to split services into separate containers.
The most straightforward path if you are focusing on local development is to package the entire application and dependent services in one container. For trivial applications, proof of concept and development stacks this may make sense. Complex applications will usually require a more complex solution.
Many applications will require multiple containers. Building and running multiple containers is made easier by orchestration solutions such as Docker Compose. When designing multiple containers the most common philosophy is role based container. Another alternative is single service/process per container.
Rather I advocate a pragmatic solutions based on heuristics. You should design a personalized set of heuristics to help with the decision making. Below is an example of some heuristics you can use.
Logical organization — Does it make sense from an overall application architecture for two or more services to share a container. e.g. Role Based or Layer Based Design.
“Physical” organization — Do services communicate directly or share resources.
Performance — Does including multiple services in one container have an impact on overall application performance.
Scaling — Do we want services to scale together or do some services not scale at the same rate. e.g. caching/memory database may need to scale more often while sql databases may not scale as frequently.
Operational Complexity — Will splitting services make overall application more difficult to manage from an infrastructure stand point.
Development Complexity — Will splitting services increase the complexity or development time of features.
These are just a few examples of heuristics you can use, but you should personalize it to your needs. These are just a few examples to get you started.
Even though the container revolution has changed our thinking when it comes to application architecture. Allowing us to more easily modularize our applications and move to service oriented architectures.
Fundamental engineering principals and computer science rules apply no matter the underlying architecture. Being pragmatic when it comes to our container design and doing what works when the rubber meets the road is more important than methodology even if it is occasionally unconventional.
