PERSIST: Policy-Based Data Management Middleware for Multi-Tenant SaaS Leveraging Federated Cloud Storage

NoSQL data stores are often combined to address different requirements within the same application. The implication of this trend is particularly important and relevant in the context of multi-tenant SaaS applications where tenants commonly have different storage- and privacy-related requirements and thus they desire to customize the storage setup according to their specific needs. Consequently, application developers are increasingly combining storage resources: on-premise and public cloud resources in a hybrid cloud setup, different external public cloud storage resources and providers in a federated cloud storage setup, etc. The consequences of these trends are twofold: (i) application developers and SaaS providers have to deal with heterogeneous technologies, different APIs, and implement complex storage logic (to address different requirements of tenants), all within the application layer; and (ii) storage architectures have become less rigid, and techniques are required to flexibly change the storage configuration of running applications, up to the level of individual service requests. To address these challenges, we present PERSIST, a middleware architecture that (i) externalizes the complexity of a federated cloud storage architecture and the complex storage logic from the SaaS application to storage policies, allows tenants to enforce different storage- and privacy-related requirements at a fine-grained level; and (ii) supports the dynamic (re)configurability of the underlying federated cloud storage architecture. Application-specific policies can be customized by individual tenants at run time, and PERSIST offers support for run-time cross-provider polyglot persistence and the confidentiality of sensitive data through encryption. We have validated PERSIST in a working prototype implementation. Our extensive evaluation efforts show (i) the accomplished reduction in the required development effort to support complex storage policies, (ii) the reduction in cost/effort to change the data storage architecture itself, and finally (iii) the acceptability of the performance overhead (around 6% for insert, and 2% for read, update and delete transactions).