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