Efficient Customization of Multi-tenant SaaS Applications with Service Lines
53
Capita Selecta: Efficient Customization of Multi- tenant SaaS Applications with Service Lines Maarten Christiaen Niels Claeys
-
Upload
niels-claeys -
Category
Technology
-
view
108 -
download
0
description
The presentation illustrates how multi-tenant SAAS applications can be customized to achieve variability between tenants.
Transcript of Efficient Customization of Multi-tenant SaaS Applications with Service Lines
Capita Selecta: Efficient Customization of Multi-tenant SaaS
Applications with Service Lines
Maarten ChristiaenNiels Claeys
2
Overview1. Context
2. Walraven summary
3. Illustration
4. Related work
5. Critical analysis
6. Quantitative evaluation
Context: SaaS
• Cloud service model:-> Delivering software services online (e.g. over the internet) and on-demand to tenants-> The application is hosted by the SaaS provider• Tenant = An organisation that configures the application for its customers
3
Context: Multi-tenant SaaS
• Multi-tenant: -> sharing of resources among a group of tenants• Customization:-> Satisfying different requirements of tenants-> No one-size-fits-all approach
4
Context: Multi-tenant SaaS
5
Context: SPL
• Software engineering methodology• Collection of similar products• Incorporates variability:-> Reusability between products• Two steps:
•Domain engineering•Application engineering
6
Context: SPL
7
Context: SPL & Multi-tenant SaaS
8
• SPL provides:• Only static composition• One dedicated product instance per customer
=> Not sufficient for Multi-tenant SaaS
9
Overview1. Context
2. Walraven summary
3. Illustration
4. Related work
5. Critical analysis
6. Quantitative evaluation
Service Line Engineering
10
• Dynamically customizable SPL• Feature-based approach:-> model application as collection of distinct functional or non functional characteristic of a software system• Entire service line is deployed-> shared among tenants
Service Line Engineering
11
Service Line Engineering
12
Service Line Engineering
13
SLE: Domain analysis
14
• Result is feature model• Difference with SPL:
• Includes non-functional requirements• Versioning of features
SLE: Domain analysis
15
Service Line Engineering
16
SLE: Architectural Design & impl
• Customization based on variation points:-> Plug-in compositions dynamically• Features are implemented as a composition of components-> difficult for non-functional requirements• Compatible features => stable interfaces
17
SLE: Architectural Design & impl
18
Service Line Engineering
19
SLE: Deployment & Operation
• SaaS middleware platform• Versioning support• Gradual roll-out of upgrades• Multi-tenancy support• Support for dynamic composition• Support for service line management
20
SLE: Deployment & Operation
21
Service Line Engineering
22
SLE: Requirements Analysis
• Each tenant selects a comprehensive list of features for his application• Automatic verification based on feature model• Mapping of tenant and his configuration
23
Service Line Engineering
24
SLE: Configuration Mapping
• Automated transformation of feature configuration to software configuration
• Using feature-to-composition mapping• Defines variants bound to each variation point• Immediately effective in service line
• Tenants-specific software configurations co-exist in running service line
25
Service Line Engineering
26
SLE: Configuration Activation
• On per-request basis• Dynamically activate tenant-specific configuration
27
Evaluation proof-of-concept
• More effort in initial development phase• Variability analysis• Mappings for each feature
• Less effort to provision clients• Self-service of features• Automatic configuration
• Beneficial for evolution and maintenance• Scalability depends on #features and not on #tenants
28
29
Overview1. Context
2. Walraven summary
3. Illustration
4. Related work
5. Critical analysis
6. Quantitative evaluation
Illustration: Introduction
•The application provides the necessary functionality for building and hosting websites
•Intuitive point and click creation•Different functional and non functional requirements•Aimed at small business without IT knowledge
30
Illustration: Feature model
31
Illustration: Use Cases
32
•Sharing economy service (Airbnb, Uber, …)•Marketplace•ScreenSize: All sizes•InternalPaymentService•Scalability on•Availability back-end and front-end premium•Social and sms integration
Illustration: Feature model
33
Illustration: Use Cases
34
•Shop (clothing, wine, appliances, …)•MailService•Analytics•Screensize: large•Scalability off•Payment external•Webshop•No integration
Illustration: Feature model
35
Illustration: Use Cases
36
•Company information site•Front-end available but not back-end•Mailservice•ScreenSize large•Scalability off
Illustration: Feature model
37
38
Overview1. Context
2. Walraven summary
3. Illustration
4. Related work
5. Critical analysis
6. Quantitative evaluation
Related work: Dynamic software adaptation for SOPL
39
+ Dynamic adaptation based on QoS
+ Hierarchical replacement
+ Reuse: SOA architecture patterns
- Multi-tenancy- No coexisting
configurations- Variability is focused on
one product- No quantifiable results
Related work: Dynamic software adaptation for SOPL
40
•Context-aware adaptation•Monitoring service•Triggers based on threshold•Dynamic adaptation
•Use case•Availability monitoring•Failing machines trigger degradation mode
Related work: Context awareness for dynamic SOPL
41
+ Automatic reconfiguration at runtime
+ Separate application from platform specifics
- Case study- Code generation
→ maintenance hard- No quantifiable results- No multi-tenancy- No coexisting
configurations - No hierarchically replace
components
42
Overview1. Context
2. Walraven summary
3. Illustration
4. Related work
5. Critical analysis
6. Quantitative evaluation
Critical analysis: paper Walraven
- No combination of variants- Non functionals not addressed completely
43
+ Middleware services• Multi-tenancy• Versioning• Dynamic composition
+ Focus on variability• Multiple levels
+ Scalable configuration management
• Self-service•Automatic control
+Case study
Availability: paper Walraven
44
• Efforts to minimize downtime• Versioning• Gradual roll-out of updates• Runtime adaptation• Stateless services
• SLA support for features
45
Overview1. Context
2. Walraven summary
3. Illustration
4. Related work
5. Critical analysis
6. Quantitative evaluation
46
+ Complete set of scenarios
+ Necessary parameters included
- No quantifiable results- Limited scope
- No comparison with other costs (e.g. design)
- Lines of code measure
Quantitative evaluation: assessment
Quantitative evaluation: proposals
• Include migration costs-> more convincing argument• Specify relative importance of scenarios• Compare gain in configuration costs to the additional design effort for SLE
47
Questions?
Extra1
49
Extra1
50
Extra1
51
Extra2
52
Extra2
53
