Building and operating applications designed to leverage the strengths of cloud computing begins with taking advantage and optimizing for more aspects of cloud architectures. It is at this point that smarter applications will emerge that can leverage resources on-demand in any cloud. The industry’s done a good job through containers, so far, and with the collaboration offered by the Cloud Native Computing Foundation we cheerfully expect that trend to continue.

But one element in application design hasn’t gotten quite as much attention: storage. Pioneers in this area have rightly focused so far on stateless applications. That’s reasonable; there have been plenty of best practices to adopt in such things as scheduling microservices for scalability and creating a front-end architecture to support microservices.

However, most business applications massage data in some way. The ability to be portable and delegate to cloud resources, and efficiently store and access information is a concern as well as an opportunity for improvement. If data is unavailable or corrupt, a lot of people are going to have a bad day, whether you’re running an application for streaming video, an e-commerce site, or losing access to your application if your only cloud goes down. Business applications and core services don’t operate in a completely stateless architecture; they have some kind of data that goes somewhere.

As a result, thinking forward about applications in cloud native requires us to consider the design of applications with more persistent data. Many cloud applications are built towards a nonpersistent front end and middleware, where what matters is user interaction and the business logic, and scalability means “add more instances and make them available.” Consumption of data happens through higher order data services working with blobs, streams, and time series. Problem resolution isn’t necessarily simple here, but ultimately, if the stateless application has a problem, you just roll up a new instance.

Data-centric applications cannot lose a byte of data, though. These apps are storing and tracking data and are much more intricate to operate. Scalability here may mean “add more capacity, add more instances, and grow the cluster.”  All of these statements involve a tightly prescribed recipe of best practices, and thus scalability is more complicated. Cloud native will have a material impact on these apps just as it did stateless applications.

To build successful cloud native applications, developers have to consider new ways to manage storage. In particular, build and define applications that separate the applications from their data. This lets the software be portable, run from anywhere, and enables the data to be accessed universally as cloud native storage from any cloud.

This means that developers, not just Ops staff, need to learn to leverage cloud, containers, orchestration, and interoperability. The old way was colocation in a data center, where jointly the application and its data formed the heart of the app. Sensible design suggests you separate these: Treat data separately and discretely, so you can handle instance failure and dynamically manage it in different ways and in different places.

Cloud native storage has several issues to address today. We want environments that are interoperable, providing storage services for applications and containers under a container orchestrator. We need to run any kind of application, no matter what type of storage it requires, and to dynamically manage that storage for the purpose of the application. That means developers and operators need ways to define the right application in simple ways without knowledge of infrastructure layers.

For instance, a mobile application needs some parts of its data to be close to the mobile user for a better user experience (so that directions to a destination don’t disappear if a user drives inside a tunnel); other bits should be stored in the data center (particularly if they need a lot of calculations). Each of these may have different storage services, requirements, and capabilities which should be defined with the application.

Underlying the technology is the designer’s awareness of what it means for an application to be successful. That’s based on the business contract that ensures the interoperability of requests, such as how we ask for resources in a common way.

We have to improve applications through cloud native storage. That’s a necessity in order to empower applications to make choices on their own through the cloud layer. It’s also a joy, because we all want to be more successful in creating cloud native applications – not to mention building more elegant software. We want to build out smarter applications that can leverage resources without requiring human intervention to scale and recover during unexpected demand and failure. It is at this point that we will see an emergence of cloud native storage platforms.

That requires attentive design to such things as treating basic interoperability of storage as a first-class cloud challenge. We are moving to a situation in which where there is no application that comingles with data; instead, data is made available to the application that needs it.

It’s an exciting time.