Creating Your Cloud-Native Data Strategy

Earlier this year, I wrote about how to ensure you build the right data architecture for a cloud-native application. That article focused on the isolation of data into your individual services so that each service owns its own data and the management of that data. Further, it talked about using only official APIs to access data that is owned and managed by other services. If you are currently involved in building a data strategy for a cloud-native application, please read that article.

This is a great strategy that I highly recommend, but it’s not the only strategy for improving your cloud-native data architecture. There are other things you can—and should—do to make your application’s data strategy effective in a cloud-native environment.

Use the Right Type of Database

The first and most important decision in architecting your data is to understand what type of database you need to store and access your data. This decision is based on a couple of key questions: What type of data will you be storing, and how will you need to access the data? Based on the answers to these questions, you can make some determinations of what you’ll need for your data strategy. Will you need to:

• Store highly structured data or simple key-value data?
• Persist data permanently or only for a short period of time?
• Access the data randomly or sequentially?
• Use a fixed schema, or do you need a flexible, dynamic schema? On the other end of the spectrum, might a simple flat file be sufficient?
• Use a relational database that supports industry-standard SQL queries?

You need answers to these questions to determine the type of database you need to use. Depending on those answers, you might choose an SQL database, a simple key-value store, a memory-resident cache, a simple object store or a highly structured data store. The answers will determine if you need to use a database such as MySQL, PostgreSQL, or a more basic but faster database such as Redis, or a cloud-based data service such as S3 or DynamoDB.

The type of database you select will dictate what your database is ultimately capable of doing and how well it will perform in your application use case. Things as integral to your application as determining your scalability and availability requirements are significantly impacted by your database choice.

These decisions can—and should—be made on a service-by-service basis. Each service should pick the type of database that works best for its unique data requirements. This is one of the fundamental benefits of having data owned and managed by a single service—the owners of that service have significantly more freedom to make database choice decisions that match their service’s unique needs.

Frontend Vs. Backend

Usually, when we think about data architecture, we focus on the backend database architecture. What data is stored in the back end of our application, how is it structured and who can use it?

But as applications become more interactive and web-based applications become more feature-rich, the need to store data within the user’s browser is becoming more and more critical. Often this data is a cached copy of some backend data or, even more commonly, unsaved (or offline) copies of backend data that is synced to a backend store only when necessary. Sometimes, there is data that simply does not need to go to the backend at all. Yet, it is important to the application and must be available for use within the application’s front end inside the user’s browser.

The needs, structure and usage patterns for frontend data are typically very different than for backend data. As such, as you build your data architecture, it’s important you take into account both the backend and the frontend data architecture requirements.

Your Cloud-Native Strategy

Building your cloud-native strategy involves many steps and many decisions, but the cornerstone to many of these decisions is selecting a data strategy that works for your application. Selecting an appropriate data strategy early on in an application’s development or before a major cloud-native migration is absolutely critical to a successful application strategy for your business.