Software design principles
Principles exist in many areas of life, and they generally represent a fundamental truth or belief from which others are derived. In software, principles are rather abstract guidelines, which are supposed to be followed while designing software. There are fundamental principles for writing quality software such as KISS (Keep it simple, stupid), DRY (Don’t repeat yourself), YAGNI (You aren’t gonna need it), SoC (Separation of concerns), etc. Even if these principles do not specify concrete rules, they represent a language and common wisdom that many developers understand and refer to regularly.
There are also SOLID principles that were introduced by Robert C. Martin, which represent guidelines for writing better object-oriented software. It is a framework consisting of complementary principles that are generic and open for interpretation but still give enough direction for creating better object-oriented designs. The SOLID principles use object-oriented primitives and concepts such as classes, interfaces, and inheritance for reasoning about object-oriented designs. In a similar way, there also principles for designing cloud native applications in which the main primitive is the container image rather than a class. Following these principles will ensure that the resulting containers behave like a good cloud native citizen, allowing them to be scheduled, scaled, and monitored in an automated fashion.
SOLID principles for cloud native applications
Cloud native applications anticipate failure; they run and scale reliably even when their infrastructure experiences outages. To offer such capabilities, cloud native platforms like Kubernetes impose a set of contracts on applications. These contracts ensure that applications they run conform to certain constraints and allow the platform to automate application management. Nowadays, it is possible to put almost any application in a container and run it. But to create a containerized application that can be automated and orchestrated effectively by a cloud native platform such as Kubernetes requires additional efforts. The principles for creating containerized applications listed here use the container as the basic primitive and the container orchestration platforms as the target container runtime environment.
Below is a short description of what each principle implies. To read in more debth, download the freely available white paper from here.
Build time:
- Single Concern: Each container addresses a single concern and does it well.
- Self-Containment: A container relies only on the presence of the Linux kernel. Additional libraries are added when the container is built.
- Image Immutability: Containerized applications are meant to be immutable, and once built are not expected to change between different environments.
Runtime:
- High Observability: Every container must implement all necessary APIs to help the platform observe and manage the application in the best way possible.
- Lifecycle Conformance: A container must have a way to read events coming from the platform and conform by reacting to those events.
- Process Disposability: Containerized applications must be as ephemeral as possible and ready to be replaced by another container instance at any point in time.
- Runtime Confinement: Every container must declare its resource requirements and restrict resource use to the requirements indicated.
The build time principles ensure that containers have the right granularity, consistency, and structure in place. The runtime principles dictate what functionalities must be implemented in order for containerized applications to possess cloud native function. Adhering these principles, we are more likely to create containerized applications that are better suited for automation in cloud native platforms such as Kubernetes. Check out the white paper for more details.
| Published on System Code Geeks with permission by Bilgin Ibryam, partner at our SCG program. See the original article here: Cloud Native Container Design Principles Opinions expressed by System Code Geeks contributors are their own. |
