Choosing A Cloud Software Partner - Page 3

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.