multi-tenant soa middleware for cloud computing
TRANSCRIPT
Multi-Tenant SOA Middleware for Cloud Computing
July 2010Srinath Perera, Ph.D.,Architect, WSO2 Inc.
Outline
What does a Cloud Native Platform needs?
Multi-tenancy
Challenges of Multi-tenancy
Carbon Platform
Multi-tenancy Architecture
Stratos
Conclusion
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
Cloud Computing
For end-users
For developers, integrators, architects
For infrastructure specialists
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
What does Cloud a Native Platform Needs(1/2)?
Self-service (in the hands of users)De-centralized creation 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 continuous update, side-by-side operation, in-place testing and incremental production
What Multi-tenancy ?
Many Parties shared same set of resources, while giving each an his own space
Multi-tenancy is for Maximizing Resource Sharing
Possible SaaS ImplementationsFirst generation: Machine for User
Second Generation: VM per User
Third Generation: Using multi-tenancy to share same server/machine/VM across users.
Efficient implementations of SaaS needs 3rd generation multi-tenancy
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.
To Understand Multi-tenant SOA platform, you have to first understand Our SOA Platform
WSO2 Carbon Platform
WSO2 Carbon Platform
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.
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.
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.
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
Multi-tenancy Architecture
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
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 levelSeparate database
Separate tables
Shared tables ** [We use this]
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.
Achieving Execution Isolation (Contd.)
Extending this to Products
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.
Performance
WSO2 Stratos
http://cloud.wso2.com
AppServer
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
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
More Info
Corporate website: http://wso2.com
Developer portal: http://wso2.org
Business development team: [email protected]