agsandrew - Fotolia
Moving data from a monolith to microservices architecture
Monolithic apps may contain a wealth of data within them. Moving to microservices means you need a plan for storing, accessing and backing up in a microservice database.
Many companies have a plan for which services to start moving to microservices and which parts to keep as a monolith. Whatever plans have already been formulated, it's important for your team to give extra consideration to how your data will be handled.
The data that powers monolithic apps is a precious resource. This data could exist as documentation spanning multiple decades. How you handle this data during your transition from monolith to microservices is crucial to the success and functionality of your organization.
The goals of data storage
When it comes to microservice data storage, there are several objectives to achieve. Developers should prioritize high availability. But to effectively access databases, strong performance and low latency are also necessary. Additionally, developers should build security into every interaction and layer of the data. Finally, developers should enable applications that are built using multiple programming languages, but can access the same databases. Enacting every one of these requires forethought and careful planning, but they will certainly make your switch to microservices more rewarding.
These are demanding goals and take planning to achieve. Fortunately, microservices give you a better shot at achieving these goals than a traditional monolith.
Use a cloud storage service
When migrating to microservices, move your data from on-premises storage to cloud storage early on. Having your data on premises undercuts the benefits of microservices by slowing down performance and presenting new issues.
Today's selection of cloud technologies has options suited for every type of data and workload. AWS, for example, offers Elastic Block Store (EBS), Elastic File System, Simple Storage Service and more cloud storage services.
Switching will entail a learning curve, particularly for security and disaster recovery practices. Those two processes work quite differently in the cloud, as a vendor is now hosting your data. Be aware that, among the various available cloud storage services, there are several pricing models. However, no matter your specific choice, you are better off moving on from on-premises data storage.
Choose your database wisely
Once you've decided where to store your data, the next step is to decide how you'll store it. Typically, monolithic applications have their data stored in SQL databases. There's no need to move from this model entirely. You can still retain such a structured relational database model in a microservice-based application.
However, look for opportunities where you can introduce NoSQL storage for the components that need it. There are numerous NoSQL databases, including MongoDB, Cassandra, Kafka and Elasticsearch. The one you choose will greatly depend on your own individual situation.
Get storage architecture right
Microservices engender stateless services and stateful storage. Therefore, it can be easy to overlook having architecture where storage remains highly available -- and able to perform. To ensure both are possible, make certain data durability is at an appropriate level. Cloud vendors themselves provide some default backups and guarantees, but to be certain, you can opt for exclusive data durability software like Nakivo Backup & Replication. With safeguards like Nakivo, you can fully back up a virtual machine and all the data associated with it.
The database you choose may have built-in functionalities to enable this. It may, for example, allow you to store data in clusters of databases. Furthermore, each database has a replica, and if there is a failure at any point, there still is a full copy of the data. In times of high load, the load can be shared across multiple replicas. While it can be challenging, it's important to plan for cross-cluster or cross-database querying, as a single request may touch multiple databases that store data differently from each other. Ensuring this process doesn't get in the way of performance is essential.
Embrace container-specific storage
Docker containers have brought a world of change to the software delivery process; subsequently, storage practices have evolved. Containers introduce a new layer of orchestration that greatly helps with storage management. Kubernetes is the leading container orchestrator and provides support for persistent storage volumes via third-party services, like AWS EBS, Flocker and Portworx.
While it is possible that a container orchestrator may introduce additional complexity, it can also greatly improve availability and performance -- two big goals for successful storage management. It gives you a single management layer for all your data, regardless of what data type or database type, where it is stored and which services use it. This is the ideal state you hope to achieve with microservices, and it's possible with container-centric storage services.
As you move from a monolith to microservices architecture, it will change how you manage and use your data. But if you're building microservices into your team's workflow the right way, you will enjoy the full benefits that made you want to make the transition in the first place.
