Many applications are being written, or re-written, for cloud-native infrastructure stacks that make extensive use of containers. Containers began as a mostly stateless mechanism for deploying application code, but state is where a lot of the value lives. Data is what makes an application come alive.
We increasingly see developers opportunistically placing stateful data inside containers to address the need for access to state, particularly when porting existing applications from virtual-machine deployments into containers. Containers are being used as small virtual-machines that contain compute, networking, and storage, not as a compute isolation primitive that more closely reflects their actual construction and early heritage.
We believe this is leading to architectural errors that are already causing problems for customers. By moving storage of state from existing, robust and feature rich options, customers are needlessly re-creating problems that have already been solved by existing data storage solutions. While this creates market opportunities for vendors who are creating container-base storage solutions to address these problems, this seems somewhat wasteful.
Instead, we advocate for a rethink of how storage of state can be managed in container environments. We suggest that existing architectural structures, have plenty of benefits, well-understood risks, and have been tested in a variety of real-world conditions. We think there is value in learning the lessons of history and not abandoning hard-won knowledge as we embrace new techniques.
Specifically, we advocate for a three tier cloud native architecture that embraces the benefits of cloud native techniques where it makes sense to do so but also retains existing, proven approaches to data storage. This provides most of the benefits of containers and cloud-native approaches such as fast deployment and rollback, CI/CD pipelines, automated scaling, and infrastructure-as-code but retaining the rich data services of existing enterprise technology options.
We see cloud-native techniques as an augmentation of existing options, rather than as a replacement. We believe this provides a smoother migration path for many enterprises that are finding cloud-native infrastructure (particularly Kubernetes) complex, time-consuming, and error-prone.
Read the rest of this whitepaper here.