One of the challenges that DevOps teams commonly face when migrating to a microservices infrastructure based on containers is the difficulty of determining where to store data persistently. Although many microservices are transient in nature and have no requirement for persistent data storage, the fact remains that some do. And containers don’t provide a simple way to store data persistently.
For that reason, it’s worth knowing what options are available when you encounter this hurdle. In this article, we’re going to look at one solution for persistent microservices data storage: NetApp Cloud Volumes. Cloud Volumes make it simple to connect microservices (or, for that matter, monoliths) hosted in the cloud to stateful storage.
The Problem with Data Storage for Microservices
If you have ever worked with containers and microservices, you already know why persistent data storage for this type of environment is challenging.
Unlike earlier types of infrastructure (namely, bare-metal servers and virtual machines), the software environment inside a container is not directly connected to a persistent storage medium. Although you can read and write data to a file system from within a container, that file system only exists as long as the container is running. It is not automatically synced to a virtual hard disk or other type of storage medium that lives outside the container. Once the container shuts down, your data is gone forever, unless you take steps to integrate it with a persistent storage medium first.
If you have spent much time using containers, you know that there are a variety of persistent storage solutions available for them, such as what Docker calls data volumes. You could also connect your container to a network file system that is hosted somewhere outside the container and use it to store data persistently. There are a variety of other approaches, too.
The problem with many of these solutions for persistent data storage for containers is that they require a fair amount of effort and orchestration to deploy and manage. The effort increases exponentially when you have multiple microservices running inside multiple containers. In many cases, it’s simply not practical to manage all of that complexity by hand. And while there are some automation tools available to help you, they tend to be tied to a specific deployment platform, such as a particular public cloud’s container service.
The Flexibility of Cloud Volumes for Data Storage
All of the above is why, for certain types of workloads, Cloud Volumes from NetApp provide a better storage solution.
Cloud Volumes allow you to build a persistent storage location, then connect it to your containers from a variety of locations. Because Cloud Volumes work with multiple cloud platforms and orchestration tools, it doesn’t matter which other technologies you deploy as part of your container stack. Whatever you’re using, it will probably work with Cloud Volumes.
This means not only that Cloud Volumes enable persistent storage for containers hosted in different locations (or ones that you migrate from, say, on-premises to the cloud), but also that Cloud Volumes can provide stateful data for many different types of applications and purposes. They can store application logs from your containers, or host an entire database.
They can store data for an individual microservice or for an entire Web app. In short, they’re very flexible, which is key if you want to take full advantage of the nimble types of architectures that containers and microservices allow you to build.
And by managing Cloud Volumes with Trident—NetApp’s storage orchestration tool—you can easily automate storage provisioning and make adjustments in real time.
Enabling Microservices Migrations
Because Cloud Volumes allow you to store data for a variety of applications persistently, and without being locked into any particular hosting platform, they are ideal for helping to advance a migration from a monolithic architecture into a microservices-based one—which is a typical feat to accomplish if you want to move a traditional application into the cloud.
Cloud Volumes can provide persistent data storage for your monolith today, and continue to provide persistent storage as you refactor the monolith into microservices.
This function is very powerful because it eliminates a huge roadblock that gets in the way of many microservices migrations: persistent data storage. By allowing your data storage architecture to remain mostly the same even as you refactor your app, Cloud Volumes let developers focus on rebuilding the app in a way that maximizes scalability, flexibility and efficiency, without being distracted by the issue of persistent storage.
Conclusion
Persistent storage for containers and microservices has traditionally been hard to achieve in an automated, streamlined way. Cloud Volumes allow you to overcome that challenge by creating a persistent storage location for microservices to access from anywhere, and automating management through Trident.
