Choosing A Cloud Software Partner - Page 2

Identity, Permissions and Delegation

Clouds need to understand who each user is, what groups they belong to and what customer or tenant their work is billed to. Each operation on each object needs to check the identity of the actor against the permissions system to make sure that the operation is allowed. Delegation then needs to be possible – from cloud admin to customer admin to end users and groups, and possibly between separate end users and groups. Without a strong concept of identity, permissions and delegation, your cloud will only scale to a single tenant and will never fully interoperate well with other clouds, thereby limiting the long-term benefit you derive from the system. Like scale and automation, this is a core design choice.

If cloud vendors do not have proper permissions systems for their objects or are lacking a way to delegate permissions through multiple levels, they are not thinking like a cloud vendor. The result will be trouble down the road as end users wind up having to place tickets to acquire permissions driving a heavyweight approval process where the owner of the resource and the end user’s management team need to be consulted.

Openness and Choice

Openness and choice mean that you have:

• Independence at each layer: Your different cloud components are not locked in from end to end. A choice at one layer does not dictate a choice at another unrelated area.
  • Your choice of end-user self-service workflow management should never dictate your hypervisor or other core infrastructure component.
  • Equally importantly, your private cloud software should never dictate the choice of public clouds to which can federate. Your end-user provisioning interface should work on your private cloud infrastructure, any public cloud using the same cloud software, and even any public cloud that uses competing or homegrown cloud software. Having to present different interfaces to your end users for clouds using different cloud infrastructure components is not open.
• Complete and open APIs: Your cloud vendor should have extensive APIs. At the very least the APIs should cover everything provided in the UI. This will allow customized workflows at both the infrastructure level and the end-user level.
• Extensible components: Your cloud vendor should use open and extensible components where possible.  Open source, where anyone can insert code at any point, is the extreme example of this principle. In non-open source systems, there are ways to introduce more controlled, but still extremely flexible extensibility models.  For example, major components can be general purpose enough that customers can add in other ecosystem products readily, as with the Linux domain 0 model for hypervisors. Alternately, APIs can be made to be robust and complete enough so that most conceivable useful integrations are possible such as the case with Windows APIs. This makes a big difference as you try to augment your cloud with best of breed 3rd party cloud management products.
• Standards: Your cloud vendor should take advantage of open standards where possible where those standards do not unduly constrain innovation.

Without openness and choice you risk vendor lock-in and the high cost that comes from not being able to have a meaningful option to replace an infrastructure component. Technology lock-in slows down the rate at which you get new features you request from your vendor. A limited ecosystem and an inability to augment your cloud with the latest and greatest offerings from companies both new and established or from the open source community further limits your ability to improve your cloud over time. Lastly, limited choice in public clouds to which you can federate may force you into a cloud with the wrong feature set or that is too expensive.