2. Outline
● What does a Cloud Native Platform needs?
● Multi-tenancy
● Challenges of Multi-tenancy
● Carbon Platform
● Multi-tenancy Architecture
● Stratos
● Conclusion
3. Outsourcing IT through Cloud
● Ideally users want to just outsources their non-
competitive IT parts.
● They want to buy IT aspects as a Utility (like
water or electricity), making Niclous Carr's “IT
does not matter” prediction a reality
5. What does Cloud a Native Platform
Needs(1/2)?
● Distributed/Dynamically Wired (works properly in
the cloud)
– Supports deploying in a dynamically sized cluster
– Finds services across applications even when they
move
● Elastic (Uses the cloud efficiently)
– Scales up and down as needed
– Works with the underlying IaaS
● Multi-tenant (Only costs when you use it)
– Virtual isolated instances with near zero incremental
cost
– Implies you have a proper identity model
6. What does Cloud a Native Platform
Needs(1/2)?
● Self-service (in the hands of users)
– De-centralized creaton and management of tenants
– Automated Governance across tenants
● Granularly Billed and Metered (pay for just what
you use)
– Allocate costs to exactly who uses them
● Incrementally Deployed and Tested (seamless live
upgrades)
– Supports contnuous update, side-by-side operaton, in-
place testng and incremental producton
7. What Multi-tenancy ?
● Many Parties shared same set of resources,
while giving each an his own space
8. Multi-tenancy is for Maximizing
Resource Sharing
● Possible SaaS Implementations
– First generation: Machine for User
– Second Generation: VM per User
– Third Generation: Using multi-tenancy to share
same server/machine/VM across users.
rd
●
Efficient implementations of SaaS needs 3
generation multi-tenancy
9. Multi-tenant SOA Platform
● Data multi-tenancy is great – most of the focus
has been there
● But we need multi-tenancy in other layers as
well.
– E.g. Google apps provides a Servelt as a
Service.
● Mosts apps, SOA handles most
logic/executions. A Multi-tenant SOA platform
will ease the development of Apps as a Service
to a greater extent.
13. Our Goal
● Developing an architecture to provide SOA
Container (s)/ Platform as a Service.
● Let users run their single tenet apps (Services,
Business processes, Web applications,
Mediation logic, Rules etc. ) in this multi-tenant
environment without any change.
14. Understanding Multi-tenancy
● Goal of multi-tenancy is to provide different users
of the system (which we shall call tenants)
isolation in each of these spaces while
maximizing resource sharing.
● Resource sharing and isolation are a tradeoff.
● Furthermore, Chang et al. [4] has proposed three
properties for multi-tenancy in addition to
isolation:
– Scalable,
– Multi-tenant-efficient: same instance hosts
multiple tenants
– configurable.
15. Challenges of Multi-tenancy
● Isolation between tenants
● Admin view vs tenants views and programming
model, maximum configuration without
compromising isolation.
● Scalability: multi-tenancy tend to accumulate
load so it has to be scalable.
16. SOA Multi-tenancy
● We break multi-tenancy at SOA in to three parts (Based on
Chang et al.).
– Execution: Business Processes, Workflows and Mashups
– Security: ownership and authorization of both data, as well as
executions in the framework
– Data
18. Achieving Tenant Isolation
● Each Tenant is given a Security Domain
● Each domain may have its own User Store and Permissions,
thus have a set of users and permissions enabling users to access
resources
● Each domain is isolated and do not have access to other
domains
19. Achieving Data Isolation
● All data access to the Carbon platform is done
through Registry interface.
● At Multi-tenant environments, system loads with
multi-tenant implementation of the registry,
which enforces isolation
● Multi-tenancy options at Database level
● Separate database
● Separate tables
● Shared tables ** [We use this]
20. Achieving Execution Isolation
● All executions are based on Axis2
● Axis2 have stateless executions and keep all state in a
Context.
● So if we create different context for each tenant, they
are isolated.
23. Extending this to Products
● WSAS (Web Services Application Server) ,
Registry, Identity Server directly get Multi-
tenancy once security, data, and execution,
● BPS keeps all the data either in Context or in
registry, and each tenet see a specific view.
● Some products need some work, but in general
they are implemented using registry for data
and services for executions So the
aforementioned model covers most usecases.
28. Open Questions/Challenges
● Scaling Up beyond simple Clustering: Tenant partitioning
strategy combined with tenant aware load balancing
● Archival Formats that describe applications that uses
different parts of the SOA (Services, BPEL, Workflows,
Rules, CEP etc).
● Bringing in discovery: WS-Discovery based deployment
● Monitoring and Managing Stratos Deployment
● Making Sessions work with Scalability Solutions
● Tenant-aware JDBC driver
● Supporting Hybrid Cloud Architectures, and on demand
scaling out to Public Cloud.
● Incremental deployment and versioning
29. Conclusion
● We discussed an architecture to enable multi-
tenancy in an SOA platform
● We discussed how architecture handle three
aspects, Security, data, and execution and how
those three aspects can yield a Multi-tenet SOA
platform
30. More Info
Corporate website: http://wso2.com
Developer portal: http://wso2.org
Business development team: bizdev@wso2.com
srinath@wso2.com