There are two primary actors in a cloud deployment, the customer of the cloud (Tenant) and the provider of the cloud (Provider). They represent a standard client / server relationship requiring a strong contract and visible performance against that contract.
I believe that there are a set of key capabilities required in order to maximize the adoption [by Tenants] of [Provider] cloud infrastructure. They are detailed as follows.
- Flexibity
- The cloud is dynamic in nature; tenant boundaries shift to meet business needs and locations change in response to overall workloads to meet contractual SL0s and to manage availability
- Virtualization is required to support this operational model
- Agility
- The speed of contracting for services verses the capital budget, procurement, and deployment lifecycle to purchase the capacity will have a significant advantage in responding to the speed of business.
- Elasticity
- Empowerment to expand and contract capabilities as and when business requirements change and opportunities arise.
- Economy [of Scale]
- Simply shifting infrastructure from Customer to Cloud Provider will not provide Economies of Scale.
- Cloud Providers must be able to pool and share their infrastructure resources in order to achieve Economies of Scale for their Customers.
- Multi-Tenancy is the Key to saving of massive amounts of capital and maintenance costs trough sharing of pooled resources via cloud operating systems.
- Trust [and trusted]
- Multi-Tenancy yields cost savings, but Customers will NOT adopt Cloud Services unless they can be assured that the Cloud environment provides a higher level of granularity of visibility and control than their existing infrastructure
- Trusted Multi-Tenancy is the Key to Cloud adoption.
These capabilities follow with a set of Tenant requirements (expectations):
- Improved Control of and Visibility into the Environment
- Self-service using web-based controls
- Improved visibility of both function and expense
- Transparency in operations and comp liane
- Isolation from other tenants; must ensure
- Privacy
- protect data in use amp; data at rest
- Non-interference
- ensure their SLOs are met, regardless of other tenant workloads
- Privacy
- Security
- Identity
- Single Sign-On (SSO) federated from Enterprise to SP
- Ability to control access to shared resources (data path, control path, and key management/escrow)
- Identity
- Improved performance to expense ratio (shared capital)
- Reliability
- Operational agility (contract/expand)
As we distill the functional requirements, an architectural taxonomy of affected entities naturally emerges:
Then we must evaluate our core architectural tenets of trusted multi-tenancy (please excuse the pun):
- Make customer-visible units of resources logical not physical
- Known MT properties/capabilities on any layer directly exposed to customers
- Put those logical objects into containers [nested] with recursive delegated administration capabilities @ the container layer
- Separates the implementation of a resource from its contract
- Provides a common point of mediation and aggregation
- Hierarchical (Layered) relationships must be supported on the data path and the control path
- Implement out-of-band monitoring of management activity
- Verify actual state of system remains in compliance throughout management / state changes across tenancies
- Out-of-band monitoring must be done at the container boundary for the container to support multi-tenancy
- Multi-Tenant correlation (actual vs. expected) becomes critical to GRC
And lastly we believe that these further distill into a set of discrete design factors and principles that help to create a matrix of critical requirements:
provided under copyright © EMC Corporation, 2012, All Rights Reserved
I hope that this discussion of Trusted Multi-Tenancy helps to clarify the complexity of the Tenant / Provider relationship as well as the complexity of the infrastructure required to fulfill Tenant service requirements in a cloud setting.
I want to thank the EMC team including Jeff Nick, John Field, Tom McSweeney, the RSA team at large as well as the 30+ members of our working group for the work that precluded this blog. – Dan
