This document discusses multi-tenancy and virtualization in the cloud context. It describes the challenges of managing variability and customer-specific configurations for software product lines deployed in public or private clouds. The document compares solving variability through virtualization versus application-level multi-tenancy and outlines some of the tradeoffs of each approach. It also summarizes some research projects exploring these issues, including using dependency injection to implement multi-tenancy, developing a reference platform architecture, and optimizing feature placement across cloud infrastructure.

1. iMinds 2011
Variability in the Cloud
Multi-tenancy
vs
Virtualisation
Koen.Handekyn@unifiedpost.com

2. Agenda
UnifiedPost
The Challange: Service Product Lines in a Cloud Context
Architectural Variations
Application Level Multitenancy challanges
Project Results

3. UnifiedPost
Specialized in the optimization
of inbound and outbound
document flows.
 Standard and Tailor-made
solutions in a transactional
Software-as-a-Service model
 Offering both paper,
electronic and hybrid
solutions
 >10 years experience in the
SAAS world with a growth at
40% per year Moving from ASP to PaaS puts higher further
stresses the importance of efficiently handling
variations points and customer driven
engineering (CDE)

4. ThomsonReuters: worldwide solution
Print, e-invoice, e-archiving
Started in 2003
>1.000.000 invoices per year, presenting a revenue of around 20 billion pound
Invoices towards 120 countries via distributed printing
Support SOX control workflow logic
E-invoice roll-out to 50 countries
Merger Thomson and Reuters: UP gets all the Thomson invoices

5. Thomson-reuters

6. MultiTenant Platform Overview
 refers to a principle in software
Community
Convert
Receive
Receive
Archive
Render
SocSec
architecture where a single instance of
Closed
Portal
Send
Send
Send
Sign
CAS
Pay
UP
UP
UP
UP
UP
UP
the software runs on a server, serving multiple
client organizations (tenants). Solutions Services
Docstore
DocFlow: [receive] User Manager: Multi
 is contrasted with a multi-instance architecture batch processing Input Channels
Alexandria
Temp
Identity, SSO
Space auth. model
Static Content
where separate software instances (or ReatTime Doc
Services
[send]
Output Channels
Resource Mngmnt
Docs:
Triples
List, Actions,
hardware systems) are set up for different Realtime Payment [offline payments]
SQL
Distributed Hash
Workflow
Services Payment Channels
client organizations. With a multitenant
architecture, a software application is Core Services
Processing Channels Persistence
App
designed to virtually partition its data and & Service
Platform
&
Connectors
&
Streaming
Platform
configuration, and each client organization Foundation Middleware
works with a customized virtual application Development : Operations : Business Intelligence
instance. Support Components
 is also regarded as one of the essential
attributes of Cloud Computing.
[ wikipedia ]

7. Levels of SaaS Multinenancy Maturity
• Level 1 - Ad-Hoc/Custom: At the first level of maturity, each customer has its own
customized version of the hosted application and runs its own instance of the application on the
host's servers. Migrating a traditional non-networked or client-server application to this level of
SaaS typically requires the least development effort and reduces operating costs by consolidating
server hardware and administration.
• Level 2 - Configurable: The second maturity-level provides greater program flexibility through
configurable metadata, so that many customers can use separate instances of the same
application code. This allows the vendor to meet the different needs of each customer through
detailed configuration options, while simplifying maintenance and updating of a common code
base.
• Level 3 - Configurable, Multi-Tenant-Efficient: The third maturity level adds multi-
tenancy to the second level, so that a single program instance serves all customers. This
approach enables more efficient use of server resources without any apparent difference to the
end user, but ultimately comes up against limits in scalability.
• Level 4 - Scalable, Configurable, Multi-Tenant-Efficient: The fourth and final SaaS
maturity level adds scalability through a multitier architecture supporting a load-balanced farm of
identical application instances, running on a variable number of servers. The provider can
increase or decrease the system's capacity to match demand by adding or removing servers,
without the need for any further alteration of applications software architecture.

8. From ASP to PAAS
ASP SAAS SAAS
Servers Servers PAAS
Data Data IAAS IAAS IAAS
Center Center
Isolation Isolation
Between Tenants Tenant / Services Provider / Platform Provider
SLA SLA
Towards Tenants Complex cascade from Tenant to Infrastructure

9. Development and deployment support
For service line architectures
In public and private cloud contexts
Background : A software product-line is “a set of software-intensive systems sharing a
common, managed set of features that satisfy the specific needs of a particular market
segment or mission and that are developed from a common set of core assets in a
prescribed way” – A Feature model is a compact representation of all the products of
the Software Product Line (SPL) in terms of "features".
Goals:
 Service Line Architecture: Family of related software services managed on
behalf of a large customer base
 Service Line Platform: Development and cloud based execution platform
supporting a service line paradigm

10. CUSTOMSS Challanges
 Automating configuration and deployment of customer-
specific variations inside a public or private cloud context
managing:
 Functional variatons and conflicts
 Security/Isolation
 Resources/SLA: modelling, provisioning, monitoring
 Quality: protect for erosion of software quality
 Do public cloud offerings support application level multi-
tenancy ?

11. Solving Variability through
Virtualisation
+ Leverage existing software product line principles and
deploy variations in an isolated way
Tenant- Tenant-
+ Easily monitor and bill resource usage (cpu hours, specific specific
memory, bandwidth) service service
instance instance
+ Simplified Resource Provisioning
+ Limited security riscs Middleware- Middleware-
library v2 library v1
+ Legacy applications easily portable to the cloud
VM1 VM2
- No resource sharing for features that are identical between CPU+Mem
instances
Shared DB
- Coarse grained allocation of resources at application level Per tenant schema’s
- “Open door” for “version hell”
- Systems Administration requires advanced automation to
be scalable
- Operations and Support require extra tools to keep an
overview
- Architecture allows „non scalable solutions‟

12. Solving Variability through
Application Level Multitenancy
An architectural design principle for SAAS
applications to enable the servicing of
multiple customers (tenants) by a (logically)
single application instance and code base Multi Tenant
Service Instances
+ Optimal use of resources through
Multi-Tenant
+ Fine grained allocation of resources at feature level Middleware
+ Operations and support see one system
VM1
+ Simplified systems management
CPU+Mem
- Security becomes a core challenge Shared DB
Single schema for all tenants
- Non trivial monitoring of resource usage
- Non trivial fine grained allocation of resources
- Forced to think about scalability from the start
- No migration path for legacy applications

13. GAE Experiment (KULeuven)
with an on-line booking application
Dependency injection (DI) separates the management of
component dependencies from the application code into
separate modules and it enables tenant-specific software
variations.
Each tenant is represented by 200 users who each execute a
booking scenario. This booking scenario consists of 10 requests
to the application
The performance overhead of using DI (Guice) is low.
Less instances are created in the multitenant variant.
Nr of CPU hours as measured by Google for billing purpose is close to equal
allthough we expect the multitenant version to be more efficient.
Instable behaviour from > 40 tenants (might be google protecting for
overloadA), specifically more so for the multitenant variant

14. Reference Platform Architecture Java/.NET
(KULeuven)
JBoss AS 7
 Open Source
 JBoss cluster (domain management,
server groups...)
 JGroups (reliable multicast
communication)
 mod_cluster (load balancer)
 Infinispan: distributed in-memory
storage (cache, shared memory)
 Supports JEE 6
 WS & RS (soa)
 CDI (variablity)
 JBoss Modules & OSGi support
(versioning)
 Async messages: JBoss HornetQ
RedHat OpenShift
 Very similar to our suggestion
 Amazon EC2
 Not yet open source

15. Feature Placement (UGent)
 Question: Where to place application instances in clouds to ensure demand
is met?
 Assumption to variability: use (multi-tenant) instances of features and
create application linking instances using service-oriented architecture
 Integer Linear Programming (ILP): optimal but to slow. Can we find an
efficient heuristic Solver based on first-fit algorithm? Yes, it seems …

16. Different feature conversions
Server counts
Feature Counts Application Counts