Why is Nimbula making this move?
Over the last year, a number of our customers and prospects have been asking us if we can provide them our enterprise ready cloud platform on top of an open core model and we are responding to that demand. The requirement for an open core model comes down to the following four value propositions.

• Open source: An open source base guarantees no vendor with a great idea is prevented from quickly getting started and competing on level footing.
• Community: The community model and massive vendor and developer participation guarantee fast introduction of new functionality.
• Extensibility: API-driven extensibility guarantees that the cloud can be extended to any network or storage system and can be well managed by any external software. A customer’s cloud will not stall waiting on one vendor to release a particular feature or integration.
• Choice: Most importantly, the proliferation of compliant distributions gives the customers what they most need, choice of the right provider with the future ability to replace that provider at any time – delivering them the right infrastructure at the right price over the long term.

With multiple open source cloud offerings, we chose OpenStack because we have been very impressed with the continued rate of growth of the project and community. The developer base, vendor commitment, product features, and most importantly customer traction have grown remarkably well in only a short time. Furthermore, as we have spoken with key OpenStack participants in the last few months, we have found significant mutual interest. While we are looking to meet the open core demand, many in the OpenStack community has shown interest in our capabilities and differentiators and have wanted to see that technology work to advance OpenStack.

Product Strategy
Nimbula’s product strategy is four-fold

• Nimbula Director becomes an OpenStack cloud: Nimbula will continue to build, deliver, and support Nimbula Director as a complete packaged cloud platform solution. In the short term, we will be adding OpenStack APIs over Nimbula Director so that we meet the customer demand of OpenStack compatibility and so that our customers can leverage the OpenStack solutions ecosystem. While there are a growing number of OpenStack distributions, Nimbula Director will continue to distinguish itself in scale, reliability, operational excellence, a modern cloud networking model, and an authorization system that models real business practices.
• Contribute: Nimbula has strong IP developed over the past few years that can be of use by the OpenStack project. We will start working right away with the OpenStack development community to identify and contribute code to improve OpenStack’s scalability, reliability, and security.
• Merge: Over time, Nimbula Director will move from just having OpenStack APIs to ultimately sharing much of the core code. This will prevent duplication of efforts and will ensure quicker pickup of new OpenStack functionality into Nimbula Director as it releases.
• Componentize: To the extent that Nimbula has functionality that we and the community decide is not part of the core of the cloud, Nimbula will separate out that functionality into modules for delivery both as part of Nimbula Director, but also as stand alone software that can work with other OpenStack distributions.

Customer Impact
While Nimbula will work as aggressively as possible to be a part of  OpenStack, our strongest commitment is to our existing customers. There will at no point be a regression in functionality or a let down on producing an enterprise ready cloud product. Nimbula Director continues to be Nimbula’s only product and we will make sure that the introduction of OpenStack APIs, functionality, and eventually code is non-disruptive and dealt with as just a part of the product upgrade process.

Closing
In closing, we at Nimbula would like to thank our customers for getting us where we are today and the OpenStack community for their warm and gracious welcome. We are proud to have had the support we’ve had from individuals, vendors, and the OpenStack Foundation itself. We are extremely excited about this new chapter and look forward to being a major contributor to OpenStack and its continued technology growth and market success.

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.

We have worked with a number of customers over the past few months and as they have purchased and deployed our software, here are the points they mentioned as important to them.

• Easy infrastructure cloud deployment: visit the nimbula.com website, download software, load it and it works! No need to speak with someone in sales or go through a gatekeeper. Some of our customers came out to us when they were ready to place their order and only had a few questions left. They ran the evaluation and bake-off against other platforms on their own, referring to our extensive technical documentation! Who else gives you such an easy and direct access with a complete high quality set of documentation?
• Complete end-to-end automation, right from installation to deployment: Nimbula Director’s API has enabled our customers to automate a great number of things and gain precious time. We decided early on to put more effort in a complete API than a shiny UI. Our customers have valued that choice and it has been great hearing from them: one of them, using their Nimbula Director private cloud for development and testing of new applications claims close to 90% time savings for one test suite alone.
• Solid security model: Nimbula Director delivers a security model that allows for very secure collaboration between tenants. A recent project in the Government space with a very security conscious customer helped us validate our model and demonstrate our claims.
• No hardware shopping list: Nimbula Director works on commodity hardware and you do not need to purchase specific equipment to get a good experience and be able to deploy it. We harden the operating system and hypervisor (shipped as part of our software) to bring out the best possible performance and security on any hardware platform. As a matter of fact, one of our customers shared the hardware they had bought and I could not recognize any of the names: pure commodity white box vendors.

Now back to the debate: Open is clearly important and I believe that means more than just Open Source. Open is also about platforms which have openness to extensibility and manageability. It is about giving a choice to the customer: use our software as long as we provide you with a great product and customer service. If you are unsatisfied or think another platform is better, you should be free to migrate and not be locked into our software. I do not think the debate is about open source or not. It is about value to customers in the long run.

But let’s not dwell on it because while debates are good and generate noise and buzz, there is much work to do. We want to keep our head down and focus on what we do best: innovate and deliver a great software experience that works out of the box. We are focused on strong core guiding principles for our development, our co-founder speaks best of them.

So don’t take my word on our software quality, give it a spin!

These are all tough things to tackle, and we consciously set the bar high, but we believe we have made great progress in all of these areas, and if you pull back the covers on Nimbula Director, there are features and capabilities that can be traced back directly to these principles.  Let’s take a look at some of them.

Building for scale and reliability requires both an architecture that is designed from the ground up to achieve this – neither can be retro-fitted to a system that does not have the inherent capability to scale.  Nimbula has built a self-healing distributed control plane that can scale with the size of the cloud, and which automatically recovers from failure, with no operator intervention.

Multi-tenancy is not just about ensuring that different users can launch virtual machines.  It is about ensuring that the right individuals in different organizations have the correct rights to access and share appropriate objects in the cloud, and it is about ensuring that dynamic networks can be created that protect different users’ traffic from one another.  Nimbula Director offers a very rich, innovative and scalable permissions system that allows user admins to control user actions, and object owners to manage object access.  We also allow virtual machine images to be versioned with a mechanism we call image lists so that when executable images are shared the underlying detail of versioning and bug fixes can be hidden from virtual machine users.

Our network security infrastructure allows virtual machines to dynamically join or leave layer 3 network security domains – which we call security lists – in a manner that is completely independent of the topology of the underlying network.  This is critical in large cloud deployments where logical, and not physical network architecture matters.

All of this, the management of permissions, the establishment of network security domains, the association of virtual machines to image lists – in fact every feature in Nimbula Director – is accessible through our API.  The entire system is built to allow self-service.

As mentioned, we also recognize that customers will want to place workloads in many different clouds.  Nimbula Director provides a number of capabilities to allow customers to forget about the seams between these clouds – the ultimate goal is a world that looks like one cloud.  Today we provide identity that spans multiple Nimbula Director installations, and the ability to launch workloads across those, whilst preserving customer permissions and access control to objects.  We also extend this to the placement of workloads in non-Nimbula infrastructure – currently we extend the identity and permissions mechanism to allow control over workloads in Amazon’s EC2.

Customers will deploy many different types of applications on the clouds that they use.  These applications may be the Web 2.0 scale-out fault-tolerant type of applications that are perfectly suited to the cloud, or they may be more traditional enterprise applications that have been around for many years.  They may also be applications that were developed on a platform for the cloud, like CloudFoundry.  As we expand the capabilities of Nimbula Director we are continually making sure that we address the needs of a growing range of application types.  Web 2.0 type applications need the core services only: secure networks, scale, self-service and so on.  More traditional applications require further support, particularly when the application’s executable code and data are intertwined.  In this case the capability to boot images from persistent storage, and to snapshot them, become critical.  In addition, the ability for the cloud infrastructure to monitor and restart applications for high availability also becomes desirable, which we support through an innovative new construct called orchestrations that allow complete applications to be specified, launched and managed by the system throughout their lifecycle.

Of course, we realize we cannot build all of the features necessary to address all of the applications in the world, so it is important to ensure that capabilities exist for other developers to add this seamlessly to the system, whether it is database services, messaging services, big data processing or others.  To this end we have built a Service VM infrastructure which allows virtual machines that provide these services to be launched and managed securely in the cloud, whilst having their APIs integrated to the Nimbula Director API in a way that makes it seamless for users to integrate with both the cloud and services built for it.  This is ground-breaking, in that it allows an ecosystem of developers to enhance the services that applications can access in the cloud in a way that is completely integrated with the cloud itself.

As we continue to build out Nimbula Director we will continue to use the guiding principles to help us innovate in ways that serve our customers and allow them to build large, scalable, secure and reliable clouds.

The elasticity and mobility of resources coupled with the huge amount of data flowing in, out and within a cloud pose a significant challenge for digital forensics. Digital forensics  was originally used as a synonym for computer forensics but has expanded to cover investigation systems capable of storing digital data, which now includes the cloud. The cloud in particular poses some specific challenges for digital forensics. Waldo Delport and MS Olivier in their paper present the process for conducting digital forensics. A presentation based on their paper is available online. An instance or a group of instances would need to analyzed for a particular investigation. The process of analyzing these “crime” domains presents challenges some of which are listed below:

• Identification of the location of a instance or a group of instances
• Blocking and isolating traffic for a particular instance before the start of the investigation process
• Guaranteeing non-contamination of the instance
• Separation, i.e. data unrelated to the incident is not part of the isolation. 

Isolation of these resources during operations and during the forensics process in the event of a investigation is important. This isolation is necessitated due to the inherent multi-tenant and sharing of resources available in the cloud. It is required to maintain a successful isolation of a instance and to provide Confidentiality, Integrity and Availability (CIA) of the resources at all times. The data collected from the instances for forensics is not part of this blog post though Nimbula Director provides all the necessary data from the infrastructure for analysis.

Nimbula Director provides the following mechanisms to aid digital forensics: 

It provides a scalable and unique identification mechanisms for instances from the nodes across the clouds.

• It provides the security mechanisms to blocking and isolating traffic. Nimbula Director has a highly scalable and distributed role based network policy mechanism. Security policies are defined and access between VMs is defined in terms of these policies, called security lists. In a cloud environment, where dynamic resource provisioning can see instances launched or terminated frequently, assigning an instance to one or more security lists enables cloud administrators or auditors to isolate instances at the behest of a API.
• The role based and resource based object permissions systems unique to Nimbula Director enables cloud administrators to manage ownership of the instances and guarantee isolation in cases of audits
• To extend the isolation of an instance or set of instances, Nimbula Director supports the ability to snapshot instances and tag nodes. A particular set of instances which are under the investigation can be isolated by moving instances under investigation to isolated areas or by moving other instances to other nodes.
• All critical events and configuration changes are logged to enable postmortem of specific instances.

Nimbula Director supports these advanced mechanisms using RESTful APIs which makes it easier for cloud administrators or cloud auditors to develop digital forensics auditing and data collection mechanisms in a programmatic way and enable automation for digital forensics. 

1. Cloud 101
    – What is cloud
    – What value should cloud provide
    – Public, private, and hybrid cloud
    – Starting on a cloud project
2. Application taxonomy, what belongs in the cloud, and why
3. What you should look for in cloud infrastructure software
4. Evaluating different approaches to cloud infrastructure software

The concepts section describes architectural design points you should ask vendors about to make sure that the they are thinking like a true cloud provider and not simply cloud-washing older technology to try to be relevant in a new world. Keep in mind that these concepts are about infrastructure management in general, not just compute. You should think about the storage, network, and power aspects of your cloud in the same way.

The specific functionality section lists cloud features to check for.  If too many of these are missing, the cloud value proposition will not be delivered.

Core Concepts and Philosophy

Scale

In a cloud, scale is the key to long-term success. The number of nodes and instances, simultaneous connections to the management system, the networking and security features, etc. all need to scale. For each and every exciting and valuable feature a cloud vendor touts, you need to ask, “Can I have tens of thousands of those? What is the experience at that scale? When, if ever, does the scale impact the end user and how they do their work?”

While one can deploy a small-scale cloud, if a cloud is successful, it will become a single pool of capacity for an entire organization or even multiple organizations. In fact, the larger clouds scale, the more cost savings and value they generate since you start to see the benefits of  “the law of large numbers”. If you do not build for scale from the very beginning, you will hit a wall and need to create separately managed clouds. This will force end users to decide what workloads go on what clouds, thus the frictionless self-service model is broken. Furthermore, capex benefits will be lost as you are forced to overprovision each cloud fragment rather than benefiting from a single pool hosting many applications with offsetting resource consumption curves.

For example, in a non-cloud deployment, the datacenter management system is used by datacenter admins only. If it can only deal with tens of simultaneous connections and is limited to one or two nodes, there is no problem since the administrative team is relatively small. However, in a cloud, since a large number of end users drive the management system directly via self-service workflows, the management system requires a whole new level of scale.

Automation

Automation is the key for allowing end users to do their own work and also for lowering datacenter operation costs. Make sure there is a proper degree of automation for both application lifecycle operations and infrastructure operations.

The core principle for end user operations is that no end user task should ever trigger work on the datacenter administrator side, not even a single mouse click approval. There is still a high degree of control and protection required, but these controls must be implemented as up front policies where the right groups of people delegate the right privileges to the right consumers. Furthermore, there need to be audit trails so that one can show that the policies constrained people to the proper activities. However, none of this changes the fact that manual approval processes by central admins on regular daily end user operations cannot work in a cloud model.

The core principle for datacenter operations is that the cloud should be self-discovering, self-organizing, self-monitoring, and self-healing. Anyone that sells you a complete zero-touch datacenter today is certainly exaggerating, but you should check the features they have to make sure this philosophy is followed where technically feasible. Where manual intervention is needed, make sure that this intervention is required only for infrequent up front tasks and never for frequent operations that happen on a frequent basis.

As an example, initial cloud configuration and network setup may be items that require significant up front planning and hours to days of setup, but regularly growing the cloud deployment by adding nodes must require no more time and effort than it takes to rack the systems and plug them in.

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.

Key Functionality

When evaluating the base functionality described here, make sure to bring in the philosophies above for each. Make sure that every feature below is implemented with scale, automation, permissions and delegation, and openness in mind.

In the spirit of openness, it is key to recognize that it is not required, nor even desirable, for all the features here to come from the cloud software vendor. Cloud software vendors should be able to present you with an ecosystem that helps fulfill the requirements below.

Self-Service Developer and Deployment Workflows

• This is the core of the concept of cloud. End users need a way to do the following on their own:
• Manage their images, update, and version them.
• Publish images to a selected community for use in deployment workflows.
• Deploy images and configure the following runtime parameters:
  • The number of instances
  • The images used
  • The placement policy
  • The network connectivity
  • The application configuration
  • The resource allocation
  • The storage to mount
• Scale applications up and down and retire them when their usefulness has ended.

Reliability and Scale of the Management System

With cloud, when we think about the management system, we’re not just talking about basic monitoring. We’re also talking about the whole datacenter control system – how workloads are deployed, managed, and retired. In a non-cloud datacenter, the management system is for datacenter admins only. If it can only deal with tens of simultaneous connections and is limited to one or two nodes creating a single point of failure compromising reliability, there is no problem since the administrative team is relatively small. However, in a true cloud, with end users driving the management system directly in self-service workflows, a whole new level of scale is required.

The management system of a cloud needs to be able to scale to handle thousands of simultaneous connections.  Furthermore, it can never be down. It needs to be self-monitoring and self-healing. When and if a management node is lost, the remaining management nodes need to continue operation, and the lost management node needs to be replaced from the remaining equipment in the cloud so that the degraded state is resolved. All of this needs to happen automatically without impact to the end user or intervention on the part of the administrator.

Multi-Tenancy and Networking

For clouds to be of use to anything more than the smallest organizations, robust and secure multi-tenancy separation is required. This involves a great deal of network functionality.

Some customers will require traditional separation at layer 2 like VLANs. Those networks need to be managed flexibly and securely.

• The cloud needs to allow for the layer 2 network to be exposed to large sets of nodes without difficult configuration.
• The cloud needs to make sure that there is a security system governing access to each layer 2 network so that only the right workloads from the right customers are placed on a given network.
• The Layer-2 network should provide the equivalent of a broadcast domain and support all traffic types (unicast, muliticast and broadcast). It should also support IPv6 and any other layer 3 protocol, not just IPv4.

Other customers, who do not want to be limited to the scale and manageability of layer 2 networks and that do not need a broadcast domain may choose to have a more modern and flexible large flat cloud network with an integrated distributed firewall providing the isolation between customers’ workloads. This distributed firewall service needs:

• To have a central configuration repository that ultimately informs the separation between workloads created by different customers as well as between workloads within individual customers.
• To be configurable by the infrastructure administrator, the individual customer administrators, and even the end users who need to control access to their own work product within their organizations.
• To have its configuration be independent of workloads and IPs – adding and removing workloads must not cause reconfiguration of the distributed firewall service.
• To execute in a distributed manner that avoids network bottlenecks.
• To be independent of server, building, network vendor, network topology, and even geography.

Storage Management

Like compute, storage needs to be aggregated into large pools for access by end users so that they are hidden from the details of the different storage devices and what objects are placed on what storage device.

Unlike compute, there are widely varying capabilities and prices for different storage devices, so some aggregation system is needed to create pools with different service levels where customers can decide the capabilities they need and are wiling to pay for to store their storage objects. This customer decision then drives automated pool selection and ultimately, device selection.

Like with all other cloud resources, the end-user created storage objects need to be created through self-service workflows without administrator interaction, but must also be governed by a robust permission and delegation system governing which storage can be used by which users.

The storage objects created by end-users in those pools need to be managed independently of the instances that mount and access them. This way, creating, updating or deleting workloads does not affect the core information the customer needs to preserve over time. Workloads that create data can be killed, redeployed from an updated template and reattached to storage without impact to the storage object itself. Also, storage objects should be able to be cloned or snapshotted for use by future instances or for rollback processes without any interaction with the running instance accessing it.

Billing and Chargeback

Core to the economic model of cloud is the ability to have end customers either pay for their usage or at the very least to understand their impact on datacenter costs. To that end, there needs to be complete metering APIs and a chargeback or showback system for the cloud.

Hands-Off Infrastructure Management

Management of the physical infrastructure should be as low touch as possible. This includes many aspects:

• Installation of the nodes: Node installation becomes a frequent operation in a big, fast-growing, and/or mature cloud where parts need to be replaced regularly. Manually installing or configuring servers will be too expensive and error-prone in this world. The only proper experience is for the servers to be racked and connected, then powered on – and nothing else. The cloud needs to auto-discover the server, install it, and make it ready to accept workloads.
• Intelligent workload placement: Workloads should be automatically, and without administrator involvement, placed such that they are:
  • Loosely packed enough that bottlenecks and performance problems are not generated as dealing with those problems reactively will be problematic at scale.
  • Tightly packed enough that hardware, power, and cooling are not wasted.
  • Strategically placed so that related workloads cohabitate for enhanced inter-workload communication and that redundant workloads are separated to eliminate single points of failure for the service.
  • Placed based on constraints such as the requirement to be on a node with GPUs or a node that is certified PCI compliant.
• Capacity tracking: There needs to be cloud-wide tracking of resources so that the datacenter operators are aware of cloud capacity and when they need to acquire more hardware.
• Isolating and retiring equipment: All systems should have a lifetime and a health status associated with them (due to length of maintenance contract, expected lifetime of component parts, and/or length of lease). When that lifetime is exceeded or when the part is failing or has failed, it is automatically isolated from the cloud and flagged for replacement. The cloud should be aware of datacenter layout so that administrators never have a problem locating the equipment at replacement time.
• Managing planned and unplanned downtimes within the datacenter: If you generally deploy cloud-ready applications (see last article in this series), most datacenter events should be transparent to the end users of the services. Scale-out applications can be scaled up to repopulate lost instances and chunks of huge compute jobs can be automatically respun. However, downtimes associated with persistent data need to be managed as well as compute or network downtimes that affect any of your more monolithic applications. The datacenter should recover whatever it can on its own, and for what it can’t, end users need to be alerted to upcoming planned downtime or recent unplanned downtime and made capable of adjusting their workload deployments accordingly.

Federation Across Clouds

To provide a single interface for all end-users, a cloud must hide distinctions between different datacenters, geographies and providers. There should be one end-user experience for deploying to anywhere in the cloud – public, private, or hybrid. While end users, due to compliance reasons, may need to dictate placement policy in terms of location or provider, it should be a policy component of their work within a single experience – it is not acceptable for there to be a private cloud experience and completely separate public cloud experience.

It is critical that the choice of public clouds to federate to is not forced by the cloud software provider, that would be too limiting. By not allowing the customer to pick the best possible provider at the right cost, cloud deployment will become unnecessarily expensive.

Federation features need to be as follows:

• From a single user interface, resources can be deployed and managed across multiple sites and providers.
• Each site and provider can be allowed or denied on a per customer or per user/group basis.
• When accessing public clouds that are tied to shared credential and billing information, like private keys and credit card numbers, the end user must have that information hidden from them. They don’t need to know it and they must not be able to take it with them when they change jobs or roles.
• Identity is preserved across sites and providers so that:
  • Users are permitted access to resources at each site according to their specific permissions.
  • Bills from public cloud providers can be itemized by department, user, and project.
• There needs to be a single audit trail showing who did what activity in what clouds.

When a cloud management system follows these rules, multiple sites within an organization can be managed as one. Furthermore, hybrid cloud becomes a reality with public cloud becoming a viable part of the IT toolkit, not a bootleg process hidden from the visibility of those most trained and responsible for keeping services safe and secure.

Conclusion

Enterprise IT departments and service providers have no shortage of choices today for cloud infrastructure software. But, for an organization doing a significant deployment, the list of requirements above can help separate the serious contenders from less mature or well thought through products.

When writing RFP’s don’t just fall back on the same enterprise management or virtualization platform requirements or you will wind up with the same old infrastructure. Start with your traditional requirements, but make sure to add in critical new requirements around what is really needed to take the next step and have a real cloud today!

1. Cloud 101
- What is cloud
- What value should cloud provide
- Public, private, and hybrid cloud
- Starting on a cloud project
2. Application taxonomy, what belongs in the cloud, and why
3. What you should look for in cloud infrastructure software
4. Evaluating different approaches to cloud infrastructure software

Cloud is obviously a serious transformation for your datacenter, but that transformation does not need to be far off or futuristic. If you pick the right applications owned by the right users with the right needs and if you partner with the right cloud software provider, cloud and its many benefits are achievable today.

When first deploying a cloud, it is critical to choose the right applications to move to the cloud initially. Given that cloud is about allowing business units to manage their own computing needs, it follows that the ideal place for cloud is where the business units:

• Expect self-service.
• Are tolerant of incorporating provisioning logic into their day-to-day work.
• Have variable compute needs for the tasks that generate the need for frequent provisioning and de-provisioning activities.
• Have multiple tasks that cause context switching in the customers’ work, with different tasks acquiring and yielding compute resources over time.
• Have workloads that, even at maximum interaction, do not cause complex resource contention issues on shared resources so that as much or as little can be deployed as necessary with little if any forethought or calculation.

If you break down the types of workloads in a datacenter, you get three major types:

• Traditional, monolithic, and stateful client/server apps – things like Exchange Servers and traditional databases
• Scale-out load balanced apps with disposable stateless instances
• Batch type computing jobs that can be decomposed into small chunks of compute and storage and distributed across a pool – things like Hadoop, Monte Carlo simulations, business analytics, and media processing and conversion

For each class of application, there are dev/test deployments and production deployments. This gives us a simple six-way classification of what runs in a datacenter that we can use to select our cloud candidates.

The following chart shows which workloads are good for early cloud adoption and what should be dealt with later on in the process. Beneath the chart is some explanation and justification for this assessment.

(Gray represents near-term opportunity and orange represents something that should be sent to the cloud later on)

Scale-out Load Balanced Apps with Disposable Instances

This type of application does not rely on any one instance of software being able to grow to use tremendous amounts of compute resource. Rather it assumes that each instance can only do so much and that additional power will be supplied by adding more instances. For this sort of application to work the data and other application state must be driven out of the application itself to another location.This allows instances to be created and destroyed with no data loss or outage to the end user. The worst problem caused by failure of an instance is the need for the end user to retry their operation. When the operation is retried, it finds a live instance and completes without difficulty.

Generally, the application requires greater or lesser instances over time as load grows and shrinks. This creates a need for dynamism in the deployment with low turn-around time on provisioning operations. As load grows, the application must respond in a short period of time. Either the application administrator or some auto-scaling management system needs to be able to make the required changes without a ticket to the infrastructure team. When load is high, new instances must be spawned to handle the increased demands. When load drops, instances should be deleted to reclaim compute resources for more useful activity. Because the instances are stateless, without sufficient load that needs to be serviced, no instance has an inherent reason to remain persistently deployed.

Scale-out applications are also a great fit with the datacenter operations models required to manage a massive cloud.  Cloud scale datacenters need to assume that any piece of equipment can break at any time with the application being resilient and able to hide the failure from the end user. Scale-out applications accomplish this by spreading many instances across nodes, datacenters, or even geographies. This makes it much simpler for the infrastructure to be managed – failures become a capacity issue which can be managed in aggregate on a periodic basis, not end-user outage issues that need to be addressed immediately and individually.

More generally, this type of application is the way of the future in general. Due to current systems architectures, we are seeing more and more cheaper cores distributed across many commodity nodes rather than the massive scaling up of individual servers. The only way to really get applications to scale is to build for many smaller instances teaming up together. Some programming infrastructures take this to a logical conclusion. Node.js, a language increasingly used for scale-out web applications, refuses to give a program access to more than one core regardless of how many cores are in a system. Should the developer need more power, they need to increase the number of node.js application instances.

Scale-out applications and cloud are such a good match because they have the same goals – elastically, scale up and down in response to load using only the resources actually needed, distributing applications across hosts and sites to better tolerate systems outages without end user impact and better conformation to modern system architecture.

Batch Applications

Batch applications are decomposable to smaller compute and storage packages. They are good in both test/dev and production for similar reasons as the scale-out applications. As jobs are launched, the number of instances depends on how fine grained you can chunk the job. Given different sizes of data sets for separate runs, the number of instances needed for each run will vary. Therefore, statically provisioning instances doesn’t make sense. Furthermore, there are likely to be completely different applications in such an environment that will need to run at different times. Clouds are perfect for repurposing an infrastructure, ramping up one application while ramping down another without having to do a massive retooling of the physical infrastructure. Like with the last case, the infrastructure administrators should not decide how many and when to deploy instances. Activity needs to be driven by the business that is actually running the jobs and deriving benefit from the output.

Traditional IT Applications

Traditional IT applications, vertically scaled, stateful and monolithic are not good for clouds in their production deployments. These applications tend to be custom built for a particular load in mind, deployed once, expected to have each instance stay running persistently, and are only touched for upgrade. These types of applications are not a natural fit for the cloud paradigm. They do not accommodate dynamic scaling by simply adding more instances. As a result there is a reduced need for end-user self-service.  Also, since they are monolithic, any performance or availability problem must be addressed in the one or two instances that make up the application with a deep understanding of the impact of the underlying infrastructure. As a result, the burden of management remains on the infrastructure administrator and cannot shift the application administrator. This breaks the operational model of cloud where the datacenter administrator needs to be removed from the details of the running of applications.

However, traditional IT applications are very well suited to cloud when the service is development, integration, and testing of the applications. For this function, application owners need to deploy new instances of server software, update them, make new templates, try out their work and iterate. Furthermore, mass numbers of clients will need to be deployed for load and scale testing. The development and testing process generates the dynamism in workload resource needs as well as the requirement for self-service on the part of the IT developer that make a cloud an ideal solution.

Pick the Right Applications and Move to Cloud Today!

Too many times cloud is pitched as an evolutionary technology. In many cases, this is because the vendor making this pitch is already managing a legacy application stack for the customer and sees no reason for a radical shift.

Since these legacy applications do not accommodate elasticity and do not tolerate the more unpredictable availability of any single server that the cloud datacenter operations model implies, true clouds are limited in the benefits they can provide and cause a loss of SLA that is unacceptable to the end users of the legacy applications.

Of course, legacy applications will not go away any time soon and we acknowledge that it takes tremendous time and effort to move to a new programming paradigm. But, the technology is here today and the benefits have been made obvious – scale, resiliency, efficiency. The success stories of companies like Netflix and Zynga are well known. All that is needed is the will to move in that direction.

For enterprises and service providers that leverage modern applications development process, cloud is not an evolution at all – cloud is the best and most obvious way forward for development, testing and mass deployment of their applications.

Pick your target applications and get started today!

1. Cloud 101

• What is cloud
• What value should cloud provide
• Public, private, and hybrid cloud
• Starting on a cloud project

2. Application taxonomy, what belongs in the cloud, and why
3. What you should look for in cloud infrastructure software
4. Evaluating different approaches to cloud infrastructure software

What Is Cloud?

Cloud is fundamentally about creating a dynamic computing infrastructure that enables end users to service and manage themselves in a process that is frictionless and instantaneous, but also secure and controlled. Resources are allocated in a very fine-grained fashion and can be relinquished at any time. Usage and chargeback is measured per customer, per resource utilization, and per unit of time, not by physical piece of equipment.

Cloud is not an incremental step on top of virtualization. While virtualization is a key enabler of cloud, the motivation, focus, target applications, and evaluation criteria are very different.

For clouds to be useful and cost effective, they must also have the properties of being very scalable and smooth to manage at the infrastructure level. The idea is to remove as much as possible from the day-to-day operations from the datacenter IT team and to scale that group’s reach and efficiency. The primary responsibility of the datacenter managers should be scaling the cloud in response to growth in demand. They should be able to look at utilization in aggregate and plan and deploy space, power, networking, and servers in as much of a just in time manner as possible. They should no longer need to focus on project specific deployment activity – that is handled by a combination of the end users’ self-service activities and automated responses from the cloud itself.

Private clouds represent the transformation of an IT datacenter into a large self-service pool of resources for internal customers to use. Public clouds open up that service to external organizations to purchase. Hybrid cloud refers to when one organization uses a private cloud for some of its work and a public cloud for other work; and where there is continuity between the public and private cloud utilization. In hybrid clouds, identity, policy and user interface are common, thereby blurring the distinction between public and private to the end user. This series discusses cloud in general with public, private and hybrid being implementation decisions for specific projects. We will introduce distinctions between these cloud types only where necessary.

Cloud Business Value

The end result of cloud to the business is two-fold. Primarily, cloud enables end users to service their own IT needs in a frictionless manner, making the business much more agile – as business units and individuals can innovate quickly and execute on new ideas immediately before they become stale. A secondary but still crucial benefit is that the cost of IT and its value become intimately tied together with a high degree of transparency. Costs are minimized and associated with end user organizations and business units. Let’s dive into the cost analysis in a bit more detail.

Capex is completely eliminated for any work that can be adequately served by a public cloud. For work that needs to be done inside an organization in a private cloud, capex expenditures become just-in time and are always justified by current and projected usage. The capex, plus operating expenses, is totaled and a per unit of time per resource cost is calculated. That cost is then shown back or actually billed to the different business units. This enables the business units to make sound and informed decisions on what to deploy and not to deploy based on the value of the work they are doing. This sort of calculus is always best decided by the business unit, not IT, as they are responsible for their own P&L. In this way, capex is reduced because the business unit is incentivized to only use what they need to drive the most value to the organization.

Opex costs like power, cooling and real estate are reduced as a function of consolidating the datacenters, pooling servers, reducing wasted capacity and incentivizing end users to make lower cost requests as just described above, but they will still remain a substantial cost.

However, the administrative expense component of datacenter opex can be brought much closer to zero through infrastructure automation. The provisioning of workloads and other opex that formerly belonged to central IT is moved to the business units, not as an IT operation, but as a part of the normal flow of the day to day activities they do to get their jobs done. This relieves the business from much of its opex and/or allows the business to reallocate IT staff to more value generating activity.

Besides value to the business as a whole, cloud provides another set of benefits to the IT team specifically which should motivate IT leaders to drive the cloud discussion inside their organizations. Simply stated, cloud can make IT loved again. Historically, IT brought in technology innovations that improved the lives of their internal customers – PC’s, networks, databases, client/server applications, e-mail, mobile computing, virtualization, etc. Now, services like Amazon’s AWS have set a new expectation of IT systems responsiveness. Fairly, or unfairly, end users are coming to expect instantaneous gratification of their IT desires without the need for planning, budgeting or security audits. As a result, they are becoming impatient with IT. They wonder why IT costs so much and takes so long to deliver. By implementing a good private cloud, IT can deliver a finite set of resources in an on-demand manner without compromising security or compliance. Hybrid clouds allow IT to extend their services to handle bursts of unplanned activity that the private cloud does not have the capacity to meet. By enabling offload to public cloud while simultaneously adopting policies and controls of who can do what in public clouds, IT can introduce public cloud as another tool in the IT toolkit without abdicating their traditional responsibility for the safety of data and applications. This will prevent the skunkworks use of public clouds that too many companies see when lines of business tries to circumvent IT. Clouds can make IT the hero again.

Getting Started With Your Cloud

Now that we know what cloud is and what we should expect from it here is a proposed journey to have the easiest onramp and highest value result.

Segregate Applications

First, you need to find the right applications for cloud. As we will describe in the next article in this series, the best fits are:

• Scale-out load balanced applications with stateless instances
• Batch processing applications
• Test and dev for the above two and for more traditional IT applications

As for legacy stateful IT applications deployed in production, non-cloud solutions will suffice. In many cases server virtualization will help – it can lower capex and increase service levels. Well known solutions from VMware, Microsoft, Citrix, RedHat and others can help here.

Make sure you know which end customers and which workloads are the best early cloud candidates according to the ease with which they can move to cloud and the extent to which cloud provides them with real value.

Incrementally Add Projects to the Cloud

Don’t try to boil the ocean – pick the ideal project to start with and add more challenging projects as you experience success. Plan subsequent projects incorporating knowledge gained from previous projects.

Pick a Project Based on End-User Needs and Application Type

Within the applicable projects, pick one that has a burning pain, eager customers, small enough scale to experiment, but large enough scale to be a meaningful test and that aims for results that can be measured – in terms of cost, speed to get results, lowered administration time, etc.

Pick a Private/Public/Hybrid Strategy for This Project

In a later article we will emphasize the need for your cloud software to support public, private and hybrid clouds. Assuming you have chosen a software partner that accommodates this choice, you need to make a decision for this particular project.

Choose public cloud if your project:

• Has highly variable needs without other projects that are able to statistically offset it.
• Is not expected to persist for an extended period of time and does not justify its own dedicated infrastructure.
• Does not have significant needs for privacy, security, or regulatory compliance, unless there is a public cloud provider that specializes in delivering the right assurances for a project of this specific nature.

Choose private cloud if:

• A single project or a sum of a few projects is expected to have flat or steadily growing compute needs.  Avoid projects that spike heavily and drop sharply unless they can be statistically offset by other projects that peak at different times.
• Is it either a long-lived project or a short-lived project that, upon completion, will be replaced by projects of equal or greater resource needs.
• Has significant needs for privacy, security, or regulatory compliance that can not be met by general-purpose or even specialty public cloud providers.

Choose hybrid cloud if the project can be meaningfully segmented into parts that have the private characteristics and other parts that have the public characteristics. Placing the right work in the right place will give you the best balance of cost, security, flexibility and return on investment.

Deploy Project

Deploying the project includes the following steps:

• Engaging with the end user customer base to explain and sell the project.
• Collaborate on end goals, desired metrics, and a timeframe for evaluation.
• Acquiring, deploying and configuring physical infrastructure (if you chose private or hybrid cloud).
• Choosing the cloud management software and deploying it.
• Training the end-users and their management team on the self-service workflows – both for the delegation or rights and for the actual execution of work.

Evaluate

At regular points in the project, measure the results to the end user customer base and review with the customers. The goals need to be quantifiable and should be set at the beginning of the project. Goals may be around project completion time, time it takes to do specific tasks, overall cost or utilization of the infrastructure, etc. If the results are not what were expected, adjust the deployment to try to meet the goals. This can involve reconfiguring HW or SW, redoubling on customer training or adding in custom automation developed internally or from contractors.

At this point, it is also good to engage with the HW and SW providers to make sure they can identify any errors in deployment or deviation from best practices that are hampering the results. At this time, you will also have a better idea of your needs and will be in a position to make stronger and more prioritized feature requests.

Bring in Least Needful Applications for Sake of Conformity of Process, Service Levels, etc.

Only after you have had success in the ideal cloud use cases should you bring in the less applicable workloads. Though it may be harder to do so and the benefits may be less, over the long haul your IT department will benefit from a common infrastructure layer for datacenter management and a common end-user interface for deploying workloads, tracking their status and measuring their cost.