kubernetes logo

7 Container Design Principles that you should know

Read Time:3 Minute, 53 Second

With the increasing adoption of containers and microservices in the enterprises, there is a need now to focus on structuring the containers and other distributed building blocks so that we can solve some of the common design challenges. In this post, we take look at some of the key design principles that could be used in Docker, Kubernetes, and other container platforms.

These principles are based on SOLID (Single responsibility, Open/closed, Liskov substitution, Interface segregation, Dependency inversion) principles that were introduced by Robert C. Martin, which represent guidelines for writing better object-oriented software.

Following these principles would ensure that the resulting containers behave like a good cloud-native citizen in most container orchestration engines, allowing them to be scheduled, scaled, and monitored in an automated fashion.

#1. Single Containment Principle

Every container should address ONLY a single concern. This principle is more like the single responsibility principle (SRP), which advises that a class should have only one responsibility.

Image – Single Concern Principle

#2. Self-Containment Principle

A container should rely only on the presence of the Linux kernel and have any additional libraries added to it at the time the container is built.

Image – Self-Containment Principle

Some applications are composed of multiple containerized components. For example, a containerized web application may also require a database container. This principle does not suggest merging both containers. Instead, it suggests that the database container contains everything needed to run the database, and the web application container contains everything needed to run the web application, such as the webserver. At runtime, the web application container will depend on and access the database container as needed.

#3.Image Immutability Principle

Containerized applications are meant to be immutable, and once built are not expected to change between different environments.

We should prevent the creation of similar container images for different environments but stick to one container image configured for each environment.

Image – Image Immutability Principle

#4.High Observability Principle

Every container must implement all necessary APIs to help the platform observe and manage the application in the best way possible.

Image – High Observability Principle

#5.Lifecycle Conformance Principle

A container should have a way to read the events coming from the platform and conform by reacting to those events.

Image – Lifecycle Conformance Principle

#6.Process Disposability Principle

Containerized applications need to be as ephemeral as possible and ready to be replaced by another container instance at any point in time. This means that containerized applications must keep their state externalized or distributed and redundant.

Image – Process Disposability Principle

#7.Runtime Confinement Principle

Every container should declare its resource requirements and it is also important that the application stay confined to the indicated resource requirements.

Image – Runtime Confinement Principle

In addition to passing the resource requirements of the container, it is also important that the application stay confined to the indicated resource requirements.

In addition to the above principles, follow the common container-related best practices:

  • Aim for small images – this reduces container size, build time, and networking time when copying container images.
  • Support arbitrary user IDs – avoid using the sudo command or requiring a specific userid to run your container.
  • Mark important ports – specifying ports using the EXPOSE command makes it easier for both humans and software to use your image.
  • Use volumes for persistent data – the data that needs to be preserved after a container is destroyed must be written to a volume.
  • Set image metadata – Image metadata in the form of tags, labels, and annotations makes your container images more discoverable.
  • Synchronize host and image – some containerized applications require the container to be synchronized with the host on certain attributes such as time and machine ID.
  • Log to STDOUT and STDERR – logging to these system streams rather than to a file will ensure container logs are picked up and aggregated properly.
  • Automate testing and deployment using CI/CD pipeline.
  • Use Container design patterns to make containers reusable, fault-tolerant, and reliable.

Like this post? Don’t forget to share it!

Additional Resources :

About Post Author


Allo! My name is Karthik,experienced IT professional.Upnxtblog covers key technology trends that impacts technology industry.This includes Cloud computing,Blockchain,Machine learning & AI,Best mobile apps, Best tools/open source libs etc.,I hope you would love it and you can be sure that each post is fantastic and will be worth your time.
0 %
0 %
0 %
0 %
0 %
0 %
7 Container Design Principles that you should know
Article Name
7 Container Design Principles that you should know
In this post, we take look at some of the key design principles that could be used in Docker, Kubernetes, and other container platforms.
Publisher Name
Publisher Logo

Average Rating

5 Star
4 Star
3 Star
2 Star
1 Star

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Are you facing challenges with developing, deploying, monitoring, clustering, storing, securing, and managing Kubernetes in production environments? My book 'IoT Edge Computing with MicroK8s' gets you up and running with production-grade, highly available (HA) Kubernetes clusters on MicroK8s using best practices and examples based on IoT and edge computing.

%d bloggers like this: