Skip to content

Why Stateful Containers

Northon Torga edited this page Dec 5, 2024 · 1 revision

The standard practice with containers is to run a single process in a stateless environment. This approach is beneficial as it allows for the recreation of containers with fresh system images and facilitates the running of multiple instances of the same application seamlessly. However, this methodology also necessitates:

  • Continuous Deployment Pipelines: Regularly building container images requires a well-configured continuous deployment pipeline;

  • Clustered Storage Systems: Application data must be stored on clustered storage systems such as NFS, Ceph, Longhorn etc, adding significant complexity, especially for non-cloud native applications;

  • Object Storage for Static Files: Managing static files often relies on object storage solutions;

While these added complexities are manageable for large enterprises, they present significant challenges for smaller businesses and individual developers. These smaller entities are accustomed to deploying simple PHP+MySQL applications on shared hosting environments. Transitioning from this to an enterprise-level setup involving Kubernetes, CI/CD, S3, and advanced databases like Aurora, DynamoDB or Elasticsearch is a substantial leap.

In the hosting industry, we observe diverse container usage patterns. Some users run all their containers manually with docker run, others use docker-compose, and a few adventurous ones attempt to deploy open-source container platforms. Most containers in use are standard images from official repositories, with minimal optimization for production environments. These containers often remain outdated post-deployment, with deployments frequently conducted via docker exec -it containerName /bin/bash, followed by wget and unzip commands.

Most Platform-as-a-Service (PaaS) providers overlook the needs of these smaller developers. Infinite, however, aims to democratize container technology, eliminating the need for users to learn how to write and maintain Dockerfiles, CI/CD pipelines, and other complex but beneficial processes.

Infinite strives to create a middle ground, merging the simplicity of shared hosting with the robustness of enterprise hosting. This involves making some necessary concessions, such as using stateful containers with multiple processes. However, this does not imply compromising on security. Infinite OS ensures that containers always utilize up-to-date packages. Infinite Ez reboots the host weekly and applies kernel patches automatically using an immutable file system (more on this in "Why MicroOS").

In the future, Infinite Ez will also support hard upgrades of Infinite OS, automatically migrating all files, databases, and configurations to a brand-new Infinite OS container with an up-to-date operating system. We recognize the compromises involved, but we aim to navigate a hybrid path with few precedents, offering an alternative for those in the middle ground—developers seeking to deploy their applications without the expertise or financial resources required for enterprise cloud-native Kubernetes deployments.

Clone this wiki locally