Multi-Tenant SOA Middleware for Cloud Computing


Published on

Published in: Technology, Business
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Multi-Tenant SOA Middleware for Cloud Computing

  1. 1. Multi-Tenant SOA Middleware for Cloud Computing July 2010 Srinath Perera, Ph.D., Architect, WSO2 Inc.
  2. 2. Outline <ul><li>What does a Cloud Native Platform needs?
  3. 3. Multi-tenancy
  4. 4. Challenges of Multi-tenancy
  5. 5. Carbon Platform
  6. 6. Multi-tenancy Architecture
  7. 7. Stratos
  8. 8. Conclusion </li></ul>
  9. 9. Outsourcing IT through Cloud <ul><li>Ideally users want to just outsources their non-competitive IT parts.
  10. 10. They want to buy IT aspects as a Utility (like water or electricity), making Niclous Carr's “IT does not matter” prediction a reality </li></ul>
  11. 11. Cloud Computing For end-users For developers, integrators, architects For infrastructure specialists
  12. 12. <ul><li>Distributed/Dynamically Wired (works properly in the cloud) </li><ul><li>Supports deploying in a dynamically sized cluster
  13. 13. Finds services across applications even when they move </li></ul><li>Elastic (Uses the cloud efficiently) </li><ul><li>Scales up and down as needed
  14. 14. Works with the underlying IaaS </li></ul><li>Multi-tenant (Only costs when you use it) </li><ul><li>Virtual isolated instances with near zero incremental cost
  15. 15. Implies you have a proper identity model </li></ul></ul>What does Cloud a Native Platform Needs(1/2)?
  16. 16. <ul><li>Self-service (in the hands of users) </li><ul><li>De-centralized creation and management of tenants
  17. 17. Automated Governance across tenants </li></ul><li>Granularly Billed and Metered (pay for just what you use) </li><ul><li>Allocate costs to exactly who uses them </li></ul><li>Incrementally Deployed and Tested (seamless live upgrades) </li><ul><li>Supports continuous update, side-by-side operation, in-place testing and incremental production </li></ul></ul>What does Cloud a Native Platform Needs(1/2)?
  18. 18. What Multi-tenancy ? <ul><li>Many Parties shared same set of resources, while giving each an his own space </li></ul>
  19. 19. Multi-tenancy is for Maximizing Resource Sharing <ul><li>Possible SaaS Implementations </li><ul><li>First generation: Machine for User
  20. 20. Second Generation: VM per User
  21. 21. Third Generation: Using multi-tenancy to share same server/machine/VM across users. </li></ul><li>Efficient implementations of SaaS needs 3 rd generation multi-tenancy </li></ul>
  22. 22. Multi-tenant SOA Platform <ul><li>Data multi-tenancy is great – most of the focus has been there
  23. 23. But we need multi-tenancy in other layers as well. </li><ul><li>E.g. Google apps provides a Servelt as a Service. </li></ul><li>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. </li></ul>
  24. 24. To Understand Multi-tenant SOA platform, you have to first understand Our SOA Platform
  25. 25. WSO2 Carbon Platform
  26. 26. WSO2 Carbon Platform
  27. 27. Our Goal <ul><li>Developing an architecture to provide SOA Container (s)/ Platform as a Service.
  28. 28. Let users run their single tenet apps (Services, Business processes, Web applications, Mediation logic, Rules etc. ) in this multi-tenant environment without any change. </li></ul>
  29. 29. Understanding Multi-tenancy <ul><li>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.
  30. 30. Resource sharing and isolation are a tradeoff.
  31. 31. Furthermore, Chang et al. [4] has proposed three properties for multi-tenancy in addition to isolation: </li><ul><li>Scalable,
  32. 32. Multi-tenant-efficient: same instance hosts multiple tenants
  33. 33. configurable. </li></ul></ul>
  34. 34. Challenges of Multi-tenancy <ul><li>Isolation between tenants
  35. 35. Admin view vs tenants views and programming model, maximum configuration without compromising isolation.
  36. 36. Scalability: multi-tenancy tend to accumulate load so it has to be scalable. </li></ul>
  37. 37. SOA Multi-tenancy <ul><li>We break multi-tenancy at SOA in to three parts (Based on Chang et al.). </li><ul><li>Execution: Business Processes, Workflows and Mashups
  38. 38. Security: ownership and authorization of both data, as well as executions in the framework
  39. 39. Data </li></ul></ul>
  40. 40. Multi-tenancy Architecture
  41. 41. Achieving Tenant Isolation <ul><li>Each Tenant is given a Security Domain
  42. 42. Each domain may have its own User Store and Permissions, thus have a s et of users and permissions enabling users to access resources
  43. 43. Each domain is isolated and do not have access to other domains </li></ul>
  44. 44. Achieving Data Isolation <ul><li>All data access to the Carbon platform is done through Registry interface.
  45. 45. At Multi-tenant environments, system loads with multi-tenant implementation of the registry, which enforces isolation
  46. 46. Multi-tenancy options at Database level </li><ul><li>Separate database
  47. 47. Separate tables
  48. 48. Shared tables ** [We use this] </li></ul></ul>
  49. 49. Achieving Execution Isolation <ul><li>All executions are based on Axis2
  50. 50. Axis2 have stateless executions and keep all state in a Context.
  51. 51. So if we create different context for each tenant, they are isolated. </li></ul>
  52. 52. Achieving Execution Isolation (Contd.)
  53. 53. Extending this to Products
  54. 54. Extending this to Products <ul><li>WSAS (Web Services Application Server) , Registry, Identity Server directly get Multi-tenancy once security, data, and execution,
  55. 55. BPS keeps all the data either in Context or in registry, and each tenet see a specific view.
  56. 56. 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. </li></ul>
  57. 57. Performance
  58. 58. WSO2 Stratos
  59. 59.
  60. 60. AppServer
  61. 61. Open Questions/Challenges <ul><li>S caling Up beyond simple Clustering: Tenant partitioning strategy combined with tenant aware load balancing
  62. 62. Archival Formats that describe applications that uses different parts of the SOA (Services, BPEL, Workflows, Rules, CEP etc).
  63. 63. Bringing in discovery: WS-Discovery based deployment
  64. 64. Monitoring and Managing Stratos Deployment
  65. 65. Making Sessions work with Scalability Solutions
  66. 66. Tenant-aware JDBC driver
  67. 67. Supporting Hybrid Cloud Architectures, and on demand scaling out to Public Cloud.
  68. 68. Incremental deployment and versioning </li></ul>
  69. 69. Conclusion <ul><li>We discussed an architecture to enable multi-tenancy in an SOA platform
  70. 70. We discussed how architecture handle three aspects, Security, data, and execution and how those three aspects can yield a Multi-tenet SOA platform </li></ul>
  71. 71. More Info <ul><li>Corporate website:
  72. 72. Developer portal:
  73. 73. Business development team: [email_address]
  74. 74. [email_address] </li></ul>