Cloud-native applications are deployed to elastic container environments, which separate the logical and physical states of storage. A container may have a persistent logical residence, but it’s not attached to any single physical host. This transience is due to the inherently ephemeral nature of containers.
A container is only spun up when its microservice is needed to perform a function within the application. As soon as that function is complete, the container is shut down or deleted until it’s needed again. The next time that container – or an exact copy – is spun up again, it could be on a different physical host.
This feature makes cloud-native applications extremely scalable and elastic, so you only need to manage and pay for resources that are actively in use by your application. Cloud-native apps are also highly resilient because if a particular container or host fails, you can always start up new instances on a different host.
However, since containers are physically transient and ephemeral, they didn’t initially support persistent storage. When a container was powered down or deleted – which happens often – any data created within that container would be destroyed. This scenario is fine for some functions that generate data that doesn’t require maintenance but presents a problem for cloud-native applications that require data retention and sharing.
To get around this issue, you need persistent external storage accessible by containers no matter where they physically reside or how frequently they’re deleted.