Executive Summary

Hybrid cloud and federation to Amazon’s AWS has long been a feature of Nimbula Director and a core part of Nimbula’s strategy. Nimbula Director specifically provides a single interface for self-service access to public and private resources that unifies workflows, permissions, audit, all the while protecting corporate assets residing in public cloud from misuse by those who no longer require access to them. The recent news and discussion on API compatibility is interesting to be sure, but practically speaking, is much less important than the actual hybrid cloud functionality provided by IaaS platforms.

Introduction

The recent announcement between Eucalyptus and Amazon about their API compatibility has confirmed the adoption of hybrid clouds. But does API compatibility really provide enterprise ready hybrid cloud on its own?

Having a single API is helpful to anyone integrating software on top of private and public cloud – although supporting a few REST APIs in a modular fashion is not terribly challenging for most programmers. But what does API compatibility do in terms of helping enterprises manage multiple clouds end to end – the authorization model, audit capabilities, credential management, etc…?

This post describes Nimbula’s view on what is required for enterprise hybrid cloud and how we meet these needs with Nimbula Director and have been doing so since we released version 1.0 in March of 2011.

What Is Needed In A Cloud API For The Enterprise

An obvious question is why does Nimbula have a different API from AWS in the first place? Isn’t AWS the de facto standard in IaaS APIs? The answer is that Nimbula chooses to not constrain its capabilities based on the feature set of a single cloud provider. Nimbula’s API exposes our differentiated functionality – functionality that we believe is required for adoption of cloud throughout an enterprise. Some of this functionality includes:

An enterprise identity and authorization system
Nimbula Director offers a multi-tenancy model where each tenant has an administrator that can manage the tenant’s users and groups. Groups are hierarchical collections of users defined so that permissions need not be assigned on a user by user basis. Each action on each object can be delegated or not to any user or group inside or outside the tenant as collaboration requires. Furthermore, the system is flexible enough to allow multiple layers of delegation (e.g. from cloud admin to tenant admin to team lead to end user). This provides security and flexibility in a way that closely matches enterprise needs.

Quality of service tagging of equipment and workloads
Nimbula Director allows tagging of compute and storage equipment based on its capabilities. For example, cloud administrators can tag some servers as “>2GHz CPU” or some storage as “DR protected”. These tags can then be made accessible to various tenants, users, and groups via the permissions system. In this way, tenants of the cloud can decide who can use what type of equipment based on the known needs and value of the work of the end users. This keeps down costs as less critical work can be pushed to less capable equipment without sacrificing performance for critical work which can be directed to more capable equipment.

Quotas & accounting
Users and groups can be given permission to charge their work against one or more accounts and draw against tenant, personal, or project quotas depending on what they are working on with each provisioning activity. The separation of permissions, billing, and budgeting and the management of all three at a fine grained level allows for real enterprise management of cloud activity and resources. It is also crucial for making self-service IT work within the bounds of enterprise accounting practices.

Flexible networking model
While Nimbula Director offers a flat layer 3 network option with an extremely robust set of network services like self-service firewall, NAT, and DNS, enterprise and government customers sometimes need layer 2 networking as well. Nimbula Director allows the allocation and deallocation of layer 2 networks to tenants via the permissions system. End users can use one or more of these layer 2 networks with their instances as needed.

Cross-cloud orchestration
Nimbula Director offers the ability to define, launch, monitor, and heal an application that spans multiple sites and clouds. This includes management of instances, storage volumes, persistent IP’s, and network security rules between the various locations.

Hybrid cloud requirements

Given a private cloud with one API and one set of capabilities and a public cloud with another, how do customers rationalize the two to get a seamless experience across both while getting the proper benefits from each? At Nimbula, we believe there are four key requirements, all of which are implemented by Nimbula Director.

The basic implementation mechanism for all four requirements is the layering of our enterprise cloud API and our authorization and permission system over the public cloud API and proxying commands from our API to our federation engine, to the public cloud.

Keeping public cloud credentials from end users

The end users of an enterprise hybrid cloud should never have access to the credentials of the public cloud. When an end user leaves their employer, or simply switches to a team that is not authorized for public cloud, they should no longer be able to access the enterprises’ public cloud resources.

Nimbula Director manages this by giving the enterprise cloud admin the ability to setup the credentials to the public cloud and determine which tenants, users, and groups are allowed to indirectly leverage those credentials. When end users use the public cloud, they do so by proxying all requests through the Nimbula Director API and federation engine. In this way, they do not own the public cloud resources, the enterprise does. The end users use only the resources allowed to them by Nimbula Director’s enterprise grade permissions system and only for as long as the business allows.

Single security model

In an enterprise hybrid cloud model, there is a need to restrict which cloud users can use the public cloud and which cannot. The cloud and tenant administrators need to be able to restrict access to specific users and groups, adding them when they are on projects requiring public resources and removing them when that access is no longer required. This security model must be unified across public and private resources to keep the process simple and secure.

Nimbula Director’s authorization system overlays on top of public cloud sites and objects so that end users are granted access to public and private resources in exactly the same way. Administrators can use Nimbula Director’s permissions system to achieve the benefits of its granularity, flexibility, and selective collaboration for public and private cloud resources.

Single audit trail

In enterprise hybrid cloud, there should be one way across public and private sites to see who has permissions on what and who granted those permissions, who has provisioned which resources, and what calls have been made with what results.

Nimbula Director, by virtue of proxying all public and private commands through its API is able to provide this single point of audit to enterprise customers.

Single set of end user workflows

End users should have a single way to access cloud resources, be they public or private. They should be able to use the same workflows for maintaining and managing images, launching and deprovisioning instances, and managing public IPs and storage resources across providers.

Nimbula Director, by virtue of proxying all public and private commands through its API is able to provide this single set of workflows to enterprise end users. It is only a matter of changing a single flag in a command to direct the work to a different site or provider.

Conclusion

Nimbula believes that we provide the most complete hybrid cloud story of any IaaS platform provider. Our more enterprise focused functionality and API along with our ability to proxy those capabilities over public clouds like AWS make for a complete enterprise hybrid cloud story that can be taken advantage of today. API compatibility is nice and makes for great press releases, but it’s all about the functionality and whether your cloud has it or not – APIs can be rationalized with simple shims, but platform functionality does not materialize without support from the underlying platform. When mapping out your hybrid cloud strategy, make sure to look for what will support your enterprise business needs in the long term rather than focusing on short term convenience.

Cloud computing is just a few years old, but already has given rise to two separate approaches and architectures; one public, like Amazon’s Web services, the other private, usually inside a corporate data center. Computer users assigned to business units are attracted to the direct access and easy provisioning of the public cloud, since servers can be up and running in a few minutes. IT organizations, on the other hand, value the security and control they associate with private clouds, and worry about the proliferation of public cloud instances and its potential impact on corporate data and security policies. It’s a familiar tug-of-war.

Successful businesses have lately come to realize that both public and private clouds have advantages, and want to make able to use both of them when appropriate. Consider Intuit, the software company does the load testing for its online TurboTax program on servers at Amazon; because real customer data is not being used, there are no regulatory or privacy issues. However, once the software is made available to the public it runs on Intuit’s on-premises machines, as one would expect for information of such a sensitive nature.

Being able to move between public and private clouds in this manner requires the right kind of cloud management software, a true “Cloud Operating System” that doesn’t take a one-size-fits-all approach to cloud architecture. Instead, it must make use of, when appropriate, the growing number of cloud technologies the marketplace is accepting.

In a properly designed Cloud Operating System, an application runs in either the public or the private cloud depending on the application itself, in connection with company policies. These policies might involve, for example, the kinds of data the application uses, or the extent to which the application is mission-critical to the organization.

The actual placement of an individual application’s workload in either the public or private cloud should occur automatically and transparently to end users. Be they in IT or in business units, users should concern themselves only with choosing the proper policy for the workload. Cloud management software should then take over, determining where precisely in the public-private cloud ecosystem the program will run.

This means that to be effective a Cloud Operating System software needs to shield users from the multitude of different command systems they currently need to master to move between public and private clouds. Instead the software must present a unified user experience, with the same authorization, the access control and interfaces regardless of the workload’s final destination. Users can focus on their workload needs using credentials set up centrally by IT. That protects the enterprise from employees disclosing their credentials to others, or worse, taking them with them when they leave the organization.

A Cloud Operating System must also give users a painless way to move data and applications back and forth between public and private clouds. That’s a seemingly straightforward task, but one whose current complexity routinely leads to lengthy and unexpected delays in what IT workers had assumed was going to be a straightforward migration process.

So how might this hybrid public-private blend architectures play out in an enterprise? Traditional mission-critical ERP programs are less likely to migrate to new cloud infrastructures, just yet. That’s because these programs have strict requirements for stability and fault tolerance and their data is subject to stringent regulatory and compliance regimes. In addition, the programs themselves do not require the constant changing and updating that can occur so easily in a cloud environment. ERP customers are much more concerned about keeping the programs running stably than they are with making daily adjustments to the underlying infrastructure. While mission-critical workloads won’t be the first ones that IT will move to cloud infrastructures, they will clearly be candidates for the private cloud in the second phase of cloud adoption.

By contrast, programs built on new generations of Web-based development environments, such as Ruby on Rails, are perfect candidates for internal clouds right away. Whether you are in a development and test environment or beginning work with a new Platform as a Service or Software as a Service offering, a Cloud Operating System technologies will make possible a new level of agility and flexibility into your organization. You can scale your infrastructure as fast as you can stack racks of hardware without having to bother with the lengthy server provisioning cycles once associated with IT deployment.

Of course, you can also use third party cloud resources like Amazon to complement your own infrastructure when doing so makes sense. Intuit used the cloud for testing; some companies move to the cloud to meet seasonal demands, or to run one of the many commercial SaaS offering becoming available. Cloud management software can transform the public cloud from a rogue resource snuck in the back door by business units trying to circumvent IT and make it instead a viable business tool, properly integrated into an enterprise’s systems.

There are a few more things that IT managers need to be aware of when choosing cloud management software besides its ability to handle both public and private clouds. Has the software been designed from the ground up to deal with the complexities of today’s computing environments or are those features bolted-on as an afterthought to software initially designed simply to set up virtual machines? How much does it automate the time-consuming, repetitive manual tasks often associated with creating and configuring virtual machines? And can it scale up as effortlessly as modern IT operations are discovering they need to?

IT managers will need to deal with those issues, too, as they make a decision about cloud management software. But at the very least, they need to make sure that when they ask a cloud management vendor if they are public or private, the answer they hear back is “Yes.”