{"title":"Expressive Data Storage Policies for Multi-cloud Storage Configurations","authors":"A. Rafique, D. Landuyt, W. Joosen","doi":"10.1109/SYNASC.2015.58","DOIUrl":null,"url":null,"abstract":"Software-as-a-Service (SaaS) providers increasingly rely on multi-cloud setups to leverage the combined benefits of different enabling technologies and third-party providers. Especially, in the context of NoSQL storage systems, which are characterized by heterogeneity and quick technological evolution, adopting the multi-cloud paradigm is a promising way to deal with different data storage requirements. Existing data access middleware platforms that support this type of setup (polyglot persistence) commonly rely on (i) configuration models that describe the multi-cloud setup, and (ii) the hard-coded logic in the application source code or the data storage policies that define how the middleware platforms should store data across different storage systems. In practice, however, both models are tightly coupled, i.e. the hard-coded logic in the application source code and data storage policies refer to specific configuration model elements, leads to fragility issues (ripple effects) and hinders reusability. More specifically, in multi-cloud configurations that change often (e.g., in dynamic cloud federations), this is a key problem. In this paper, we present a more expressive way to specify storage policies, that involves (i) enriching the configuration models with metadata about the technical capabilities of the storage systems, (ii) referring to the desired capabilities of the storage system in the storage policies, and (iii) leaving actual resolution to the policy engine. Our validation in the context of a realistic SaaS application shows how the policies accommodate such changes for a number of realistic policy change scenarios. In addition, we evaluate the performance overhead, showing that policy evaluation is on average less than 2% of the total execution time.","PeriodicalId":6488,"journal":{"name":"2015 17th International Symposium on Symbolic and Numeric Algorithms for Scientific Computing (SYNASC)","volume":"3 ","pages":"329-336"},"PeriodicalIF":0.0000,"publicationDate":"2015-09-21","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"2","resultStr":null,"platform":"Semanticscholar","paperid":null,"PeriodicalName":"2015 17th International Symposium on Symbolic and Numeric Algorithms for Scientific Computing (SYNASC)","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1109/SYNASC.2015.58","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
引用次数: 2
Abstract
Software-as-a-Service (SaaS) providers increasingly rely on multi-cloud setups to leverage the combined benefits of different enabling technologies and third-party providers. Especially, in the context of NoSQL storage systems, which are characterized by heterogeneity and quick technological evolution, adopting the multi-cloud paradigm is a promising way to deal with different data storage requirements. Existing data access middleware platforms that support this type of setup (polyglot persistence) commonly rely on (i) configuration models that describe the multi-cloud setup, and (ii) the hard-coded logic in the application source code or the data storage policies that define how the middleware platforms should store data across different storage systems. In practice, however, both models are tightly coupled, i.e. the hard-coded logic in the application source code and data storage policies refer to specific configuration model elements, leads to fragility issues (ripple effects) and hinders reusability. More specifically, in multi-cloud configurations that change often (e.g., in dynamic cloud federations), this is a key problem. In this paper, we present a more expressive way to specify storage policies, that involves (i) enriching the configuration models with metadata about the technical capabilities of the storage systems, (ii) referring to the desired capabilities of the storage system in the storage policies, and (iii) leaving actual resolution to the policy engine. Our validation in the context of a realistic SaaS application shows how the policies accommodate such changes for a number of realistic policy change scenarios. In addition, we evaluate the performance overhead, showing that policy evaluation is on average less than 2% of the total execution time.