PaaSHopper: Policy-driven middleware for multi-PaaS environments

Walraven, Stefan; Landuyt, Dimitri Van; Rafique, Ansar; Lagaisse, Bert; Joosen, Wouter

doi:10.1186/s13174-014-0017-x

Cited by 10 publications

(13 citation statements)

References 28 publications

(37 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…In recent work, we have extended such architecture with an additional tier of application-level middleware services [14,22,20]. These services provide support for specific non-functional requirements across multiple cloud providers that cannot be fully supported by a single third-party PaaS provider.…”

Section: A Container-based Architec-ture For Multi-tenant Saasmentioning

confidence: 99%

“…It consists of three services: (i) the Tenant SLA Manager service for tenant SLA management and performance isolation [20], (ii) the Tenant Data Manager service for adaptive data management across multiple database technologies (e.g. MongoDB and Cassandra) and cloud providers [14] and (iii) the MultiCloud Deployer service for deploying SaaS application components across multiple cloud providers [22]. Each of these middleware services implement a policy-based architecture, possibly extended with application-centric montoring and an autonomic control loop.…”

Section: A Container-based Architec-ture For Multi-tenant Saasmentioning

confidence: 99%

“…SaaS applications increasingly rely on complex middleware solutions to support the above requirements [22,20,14]. These solutions involve complex policy engines [14,22], etc.…”

Section: Introductionmentioning

confidence: 99%

“…Multi-cloud and hybrid cloud deployment: By leveraging the combined benefits of different cloud resources, both private and/or public, and having the ability to dynamically add resources offered by different providers, a number of additional benefits can be attained: (i) Cloud portability: SaaS applications must be able to run on different cloud providers, which is not straightforward due to the high degree of heterogeneity between cloud technologies; (ii) Dynamic reconfiguration: by observing the underlying cloud platforms and offerings, SaaS applications can be built that support varying degrees of dynamicity, for example to automatically migrate the application (or parts thereof) to different cloud providers [22,14].…”

Section: Introductionmentioning

confidence: 99%

“…However, such shared-everything architectures trade the gain in efficiency for a weaker security isolaton between tenants. Another consideration is that multi-tenant SaaS applications typically rely on complex application-level middleware services for performance isolation [20], tenant data management [14] and multi-cloud deployments [22]. In principle, it is possible to simplify these middleware services by shifting some functionality to a container orchestration layer.…”

Section: Introductionmentioning

confidence: 99%

See 4 more Smart Citations

Towards a container-based architecture for multi-tenant SaaS applications

Truyen

Landuyt

Reniers

et al. 2016

Proceedings of the 15th International Workshop on Adaptive and Reflective Middleware

Self Cite

View full text Add to dashboard Cite

SaaS providers continuously aim to optimize the costefficiency, scalability and trustworthiness of their offerings. Traditionally, these concerns have been addressed by application-level middleware platforms that implement a multi-tenant architecture.However, the recent uprise and industry adoption of container technology such as Docker and Kubernetes, exactly for the purpose of improving the cost-efficiency, elasticity and resilience of cloud native services, triggers the unanswered question whether and how container technology may affect such multi-tenant architectures.To answer this question, we outline our ideas on a container-based multi-tenant architecture for SaaS applications. Subsequently, we make an assessment of the technical Strengths, Weaknesses, Opportunities, and Threats (SWOT) which should be taken into account by a SaaS provider when considering the adoption of such containerbased architecture.

show abstract

Section: A Container-based Architec-ture For Multi-tenant Saasmentioning

confidence: 99%

Section: A Container-based Architec-ture For Multi-tenant Saasmentioning

confidence: 99%

“…SaaS applications increasingly rely on complex middleware solutions to support the above requirements [22,20,14]. These solutions involve complex policy engines [14,22], etc.…”

Section: Introductionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

Towards a container-based architecture for multi-tenant SaaS applications

Truyen

Landuyt

Reniers

et al. 2016

Proceedings of the 15th International Workshop on Adaptive and Reflective Middleware

Self Cite

View full text Add to dashboard Cite

show abstract

A survey on the service interoperability in cloud computing: Client‐centric and provider‐centric perspectives

2020

View full text Add to dashboard Cite

The vendor lock-in is a prominent issue in cloud computing. It is caused by cloud providers who offer proprietary services, which hinders the cloud interoperability. Client-centric interoperability enables the migration of the data and applications across clouds; it gives the clients control over their workloads and a wider range of service choices. Whereas, provider-centric interoperability allows the providers to collaborate. Thus, providers, who have spare resources, can lend them to other providers who lack computational or storage capabilities to overcome the limitations of their local resources. In this article, we conduct a survey to differentiate between client-and provider-centric interoperability solutions. We aim to provide an up-to-date analysis of the current tendencies and the neglected areas of the cloud interoperability field. Thus, we study the cloud service interoperability evolution through the years. Furthermore, we propose definitions for the intra-cloud and inter-cloud interoperability. Moreover, we propose a taxonomy to classify the cloud interoperability approaches into client-centric and provider-centric categories. Then, for each category, we classify the approaches based on their interoperability environment into single cloud or interconnected clouds. Finally, we analyze and compare the approaches based on multiple criteria. The study reveals the focus on the client-centric solutions and the interoperability in interconnected clouds. We notice more interest in the data and application levels interoperability, mainly, in infrastructure as a service model. We also find that client-centric solutions are, mostly, semantic technologies and brokers. However, provider-centric solutions are middleware, protocols, and standards. We conclude that a generic cloud service interoperability model is needed.

show abstract