Hybrid and Cloud Brokering - The Enterprise Cloud: Best Practices for Transforming Legacy IT (2015)

The Enterprise Cloud: Best Practices for Transforming Legacy IT (2015)

Chapter 8. Hybrid and Cloud Brokering

Key topics in this chapter:

§ What is a cloud broker

§ Key hybrid and brokering terminology

§ Hybrid cloud versus cloud broker

§ Selecting a cloud broker

§ Arbitration and selection of service providers:

§ Spanning multiple cloud providers

§ Systems portability and dynamic allocation to providers

§ Industry standards and the future

§ The challenges of cloud brokering

§ The future of cloud brokering

§ Hybrid and cloud brokering best practices

The evolution of cloud computing has been rapid, focusing first on basic Infrastructure as a Service (IaaS) virtual machines and then Platform as a Service (PaaS) and Software as a Service (SaaS). Leading public cloud providers are now well established, whereas enterprise organizations still work on deploying private and hybrid clouds and evaluating which legacy applications to migrate. Some organizations are already going beyond private hybrid cloud and beginning to consider cloud brokering. As of this writing, there are no true cloud brokers in the industry, but you can expect to see customer adoption and even some public-style cloud brokers in the coming years. In this chapter, I explain what a cloud broker’s role is and the technological challenges it must overcome.

What Is a Cloud Broker

Cloud brokering refers to an organization that serves as a centralized coordinator of cloud services for other organizations, departments, or subagencies. Many IT departments already serve as an IT broker today — providing IT services for their overall organization or procuring or outsourcing the required services to a third party to meet the needs of internal customers within the enterprise organization. A cloud broker is a similar role, taking requirements or orders via an online service catalog and then determining which of multiple cloud providers will receive the provisioning request.

As of this writing, there are no public cloud broker service providers in the industry. Cloud brokering is not something you can purchase from a public cloud provider. Brokering is normally deployed by installing a cloud management system (with specialized brokering capabilities) within an enterprise datacenter or leased facility. There are some specialized systems integrators that concentrate on cloud brokering that are planning to offer a managed community cloud broker service; however, the level of complexity and customization required per tenant or customer is very challenging. This is why there are no “public” cloud broker service providers in the industry.

The National Institute for Standards and Technology (NIST) defines a cloud broker as “An entity that manages the use, performance, and delivery of cloud services, and negotiates relationships between Cloud Providers and Cloud Consumers.” The “entity” in this definition refers to you as an IT organization serving in the broker role for the rest of your users or as a commercial cloud broker which, as I will discuss later, there really are none in the industry at this time.

Following is a summary of the six specific areas in which the cloud broker plays an important role:

Service catalog

Provide a consolidated service catalog for customer ordering of all downstream cloud provider Anything as a Service (XaaS) offerings

Workflow

Facilitate ordering processes such as approvals and notifications within consumer organizations

Provisioning application programming interfaces (APIs)

Manage service provisioning by using API calls to downstream cloud providers

Resource management

Manage all service costs, resource metering, billing or chargeback — consolidated across all cloud providers

Tracking status

Track completion and success of provisioning and availability of services by using APIs with each cloud provider

Reporting

Collect and aggregate all system statuses, statistics, and service-level agreement (SLA) dashboards from downstream XaaS cloud providers into a centralized portal hosted by the broker

Although NIST defines two separate roles for broker — business and technical (NIST Special Publication 500-299) — I have combined these roles for clarity and simplification. Although the broker industry is very new, early adopters and broker providers are finding that a combined broker role is more effective, offers better multiprovider integration, and provides a more unified customer experience.

In a cloud broker environment, the simplified layers of cloud management, described earlier in Chapter 7, become more complex because there is now the expectation of supporting one or more downstream cloud service providers. Figure 8-1 presents a diagram of a cloud broker functional management structure. The cloud broker performs the functions within the boxes at the top and bottom, whereas one or more downstream service providers performs the functions contained in the box in the middle. The box on the bottom, operations and management, is really an encompassing function also performed by the cloud broker.

Cloud broker management functions

Figure 8-1. Cloud broker management functions

The cloud broker must provide APIs and standards so that each XaaS cloud service provider can easily integrate with the overall cloud brokering system. Finally, the cloud broker normally performs some level of overall systems management (shown in the box on the right in Figure 8-1) to at least aggregate system status and performance metrics from the downstream XaaS cloud providers. Individual cloud providers also perform their own internal network and systems-operations management functions at a more detailed level within their own datacenters and server farms (similar to the cloud management functions and architecture shown in Chapter 7).

Key Hybrid and Brokering Terminology

NIST defines three common industry terms that define the processes and functions that a cloud broker must perform in order to have full integration with one or more third-party cloud providers. While I use the NIST terms, I have provided you my definitions and descriptions:

Aggregation

Service aggregation involves the integration and consolidation of data across multiple cloud services. Service catalogs, statistics, resource usage, billing, and service-level management across multiple cloud services and providers is combined into a single management interface and customer experience. The end consumer of the cloud might not be aware that multiple services and/or multiple cloud providers are being used.

The aggregation of IT services is not a new concept. The aggregation of cloud services across multiple public and private cloud providers and XaaS is a new approach used in hybrid clouds. The cloud management system must include aggregation processes and technology across multiple cloud providers to facilitate the hybrid cloud.

There are no industry standards (yet) that readily enable each cloud provider to share their utilization, service catalog, performance, SLA, error/event, or security information with other providers or cloud management platforms. Given the lack of industry standards, aggregation requires implementing a common software tool and data exchange technique between the cloud management platform and all downstream cloud providers. Most hybrid cloud management systems have some form of aggregation in place, but we will see significant improvements in this area with the next-generation clouds. The cloud management platform collects data from all connected cloud providers and presents it in a consolidated fashion via a centralized portal. This aggregation of data provides numerous other reporting capabilities such as overall system status dashboards, system and event tracking, and analytical data for use in service arbitration decisions.

Arbitration

Service arbitrage is the process of determining the best cloud service provider for each workload. As orders for cloud services are placed, usually through a service catalog, a combination of business logic and technical processes determine which cloud provider is the best match to the requirement. Arbitration decisions can be based on many criteria such as provider pricing, SLA guarantee, and geographic location for data sovereignty, or they can be based simply on customer preference. Depending on the decision logic, the broker cloud management platform can provision any given XaaS to the selected cloud provider or span the XaaS offering across multiple cloud providers.

Automated arbitration of services provides a best-fit recommendation to the customer (or cloud operator) as to which cloud provider or XaaS best meets static or policy-driven requirements. When a customer orders a cloud service, the arbitration-logic engine (part of cloud management platform) compares all available cloud providers to present the customer with a list of recommended or ranked services. The arbitration logic can be based on static (hardcoded) rules or on customer policies such as country location, required SLAs, or pricing. More advanced arbitration logic can use historical analytics data to calculate reliability and availability statistics, performance, or other dynamic metrics to determine the recommended cloud provider. In some cases, the cloud management system will give the customer the option to override or manually select the provider.

Upon selection of the cloud provider, the cloud management platform performs a series of background commands to one or more cloud providers — provisioning the ordered cloud services and handling the tracking notifications that come back from each cloud provider’s cloud management and automation system. This type of automated provisioning is very complicated when a single application or XaaS is configured to span multiple cloud providers. For example, configuring web services on one provider with database and application running on another provider — all done seamlessly to the customer but divided up between providers for best performance, flexibility, redundancy, elasticity, cost, and so on.

The arbitration of services, as described here, has focused on hybrid cloud; however, arbitration is a critical feature that will differentiate cloud brokers.

Intermediation

Service intermediation is a technique by which the cloud management system (or provider) centrally controls a specific service that is then distributed to multiple cloud service providers. Key examples of intermediated services include identity management, utilization and performance reporting, and security, with all cloud providers agreeing to use an integrated common service standard so that all providers and systems can easily exchange data.

Intermediation is the means by which the primary cloud management platform or provider can create a standard and manage the methods for any application or service that spans all subordinate cloud providers. Identity management or user authentication is one primary example whereby the primary cloud provider (hybrid cloud or broker) controls and publishes standards and a single system that all cloud providers can agree to use. This intermediation affords true interoperability and exchange of information between cloud providers so that the hybrid or broker provider can have visibility and collect data from all downstream XaaS providers. Without this intermediation, each cloud provider would run its own version or choice of monitoring, provisioning, security, and operational management tools that wouldn’t communicate with other providers or up to the hybrid or broker cloud provider.

Just as with aggregation, there are few industry standards upon which each cloud provider can agree and implement. One standard that is already in place for identity and authentication is Security Assertion Markup Language (SAML). In future cloud deployments, we will see more hybrid clouds, cloud brokers, and integration between cloud providers, so intermediation might not be specifically named as a feature, but it will be a critical background technology.

These three NIST-based terms are business processes and technical methods used to perform cloud brokering. A private cloud management platform and a hybrid cloud would utilize these same techniques to provision services to multiple cloud providers — the difference between hybrid clouds and cloud brokering is less technical and more process-, governance-, and role of the IT provider-based. These differences are described in the following section.

Hybrid Cloud Versus Cloud Broker

Just as in a private or hybrid cloud, the cloud management system is used in a broker scenario to provide customers a service catalog for ordering services and an automated orchestration system for provisioning workloads to multiple cloud service providers. Because cloud brokering by definition involves a variety of cloud service options from multiple cloud providers, the cloud management system must be capable of multiprovider orchestration. This also means that the cloud management system contains the necessary APIs that with which it can communicate and provision workloads for each cloud provider (e.g., Amazon or Microsoft public clouds). These specialized versions of cloud management platforms are called cloud brokering management systems. Cloud brokering management systems have every feature and capability as a “regular” cloud management system described in Chapter 7 but with additional capabilities specialized for managing cloud services across multiple cloud providers.

Key Take-Away

Cloud brokering management systems have every feature and capability as a “regular” cloud management system with additional capabilities specialized for managing services across multiple cloud providers.

Although a hybrid cloud is usually based on a private cloud as the core infrastructure, you can deploy a cloud broker management system without a private cloud involved, depending on your business needs and use case. For example, you can compare a cloud broker to the Expedia online travel service, which functions as a marketplace for numerous suppliers.

Though the cloud brokering industry is not yet mature, there are already some early examples of differences between hybrid clouds and cloud brokering:

§ Cloud brokering management platforms have a more significant focus on service arbitration across numerous providers, whereas a hybrid cloud might only have limited provisioning capabilities (e.g., basic VMs only) to one or two third-party cloud providers.

§ A cloud broker utilizes advanced dynamic-arbitration logic engines to determine the best cloud provider for any given customer order. These advanced arbitration services can use performance, price, analytics, geography, and customer preference data to automatically recommend which cloud provider should be used for any given XaaS workload. A hybrid cloud might have only basic sequential scripting and static hardcoded rules or policies with much less sophistication in the arbitration logic.

§ A hybrid cloud will have its authentication, directory services, management, security, and monitoring tools and standards established based on the private cloud. A cloud broker environment has far more complexity and quantity of providers and management tools that the broker needs to establish as well as published APIs to each cloud provider, while managing intermediated services.

§ A cloud broker might establish and maintain contracts directly with service providers and effectively resell services to end-user customers; whereby in a hybrid cloud, only the private cloud infrastructure owner chooses and establishes agreements with service providers.

The NIST Cloud Broker Architecture

The NIST Cloud Reference Conceptual Model shown in Figure 8-2 articulates the roles of a cloud broker, auditor, carrier, and provider. This diagram, when released by NIST, was one of the first to document the specific role of cloud broker.

The NIST cloud reference model (Source: NIST, www.csrc.nist.gov/groups/SNS/cloud-computing/index.html)

Figure 8-2. The NIST cloud reference model (Source: NIST, www.csrc.nist.gov/groups/SNS/cloud-computing/index.html)

In Figure 8-2, notice the core functions (both business process and technical methodology) are intermediation, aggregation, and arbitrage, as I detailed earlier. In the center of the figure is the cloud provider but what might not be clear in this NIST model is that there would normally be multiple cloud providers in a cloud broker ecosystem. Within the cloud provider functions (shown in the large center box) are all of the XaaS each cloud provider offers to cloud consumers as well as the provider’s computing infrastructure and the internal cloud management system. The cloud auditor is another role that could be used as part of the cloud broker service or executed by a third party to oversee and audit the overall service governance.

Cloud Broker Functional Architecture

To better explain the functions that the cloud broker provides, I have created Figure 8-3 which presents a more detailed model showing all of the primary tasks, workflows, and business logic. The diagram is similar to that shown earlier in Chapter 7 for private cloud management platform architecture, but is unique in that this model supports multiple XaaS cloud service providers managed by a cloud broker. This is a vendor-agnostic sample cloud broker architecture — there are many ways to portray this information and at varying levels of detail.

Notional cloud-broker functional architecture

Figure 8-3. Notional cloud broker functional architecture

Figure 8-3 shows five layers of functionality for a cloud broker; however, the center layer (labeled “Cloud Service Providers”) represents services and functions provided by each downstream integrated XaaS cloud provider — this is equivalent to the Cloud Provider box in the NIST model shown earlier in Figure 8-2. The key functions of the broker are all focused on the centralized portal concept, whereby consumers of the cloud can place orders, provision services to one or more cloud providers, track all billing, SLAs, reporting, assets, configurations, and operations monitoring. The cloud broker initiates service provisioning and collects data from all of the downstream cloud providers; however, the broker is not involved in the day-to-day communications between consumers and the cloud provider’s computer networks. The broker provides the cloud management systems and interoperability between all providers as well as keeping up with enhancements and future revisions of each downstream XaaS provider (and their API).

The Cloud Portal Layer

The Cloud Portal Layer (see the illustration that follows) provides the primary web-based interface with which customers can order services, view reports, and review billing information. Customer executives and project owners use this portal to initially procure cloud services and see the status of their ongoing services.

Image

Figure 8-4. The cloud portal is the primary interface with cloud consumers. Features vary depending on the cloud provider or brand of cloud management platform but the most important functions of the cloud portal are the service catalog, billing, and service actions. Other functions, such as reporting, and notifications/announcements are optional and may or may not be enabled depending on the needs of the cloud provider or enterprise private cloud.

Here’s what you can find in the portal:

Service catalog

The service catalog provides customers with a list and description of available cloud services and pricing for all available options. The services available in the catalog are an aggregation of all downstream integrated XaaS cloud providers. Upon choosing one or more services, the customer processes the order by selecting from one or more preestablished funding sources such as purchase orders, task orders, or encumbered funding documents.

In this architecture, the billing and provisioning system contains the pricing for each service catalog item, each optional service, and the price for every resource, such as virtual machines (VMs), memory, storage, and user licenses. The billing and provisioning system calculates the bills based on fixed pricing per service or variable pricing based on actual resource utilization. The invoices or bills can be sent to the customer by the orchestration system or from within the billing system, depending on customer requirements and the capabilities of the selected cloud management system. The cloud portal displays only a viewable report of the billing data, invoice history, utilization, or other ad hoc reports.

The primary purpose of the service catalog is to display the descriptions of each cloud service along with pricing. The descriptions and actual pricing of each service item available to customers can be programmed into the cloud portal itself, but the NIST Cloud Reference Conceptual Model calls for this data to be held within the provisioning and billing system. The orchestration system synchronizes all of this data into the service catalog so that it only needs to be configured and managed in one place. The advantage of holding the descriptions and service pricing within the billing system layer is that it can better handle all pro-rating, billing periods, and variable-priced metered-resource charges. Because this data must be tightly integrated with the provisioning and metered-resource systems, the architecture calls for the service catalog data to be pulled from the billing system and synchronized up into the service catalog.

To maintain a consistent ordering and tracking process for all services and across all customers, even manual orders placed by the provider on behalf of a customer should still be performed within the cloud portal. Manual orders placed outside of the cloud portal might not be tracked, billed, and shown to the customers correctly.

Billing

As services are consumed and billing occurs, the customer can track all invoices (or chargeback reports) and remaining budget balances via the portal. In an environment that has multiple downstream XaaS cloud providers with a central cloud broker, billing might occur between each provider and the customer directly, without the broker’s involvement. The cloud broker provides a series of reports and dashboard views for customers to see real-time system status, utilization, and performance information of all aggregated downstream providers. This provides the customer with a centralized cloud management system managed by the broker, although each downstream provider is still ultimately responsible for meeting its SLAs, contractual obligations, and reporting statistics up to the cloud broker’s dashboard. Within enterprise organizations, billing and invoicing might not be required; however, chargeback accounting for the cost of services can still be calculated to determine utilization by department. This is often useful for planning and budgeting purposes even if your organization does not directly charge for your brokered cloud services.

The billing system is heavily reliant upon the resources ordered and consumed based on utilization; therefore, this reference architecture calls for the billing to be generated as part of the provisioning and metered resource tracking layers at the XaaS cloud provider level. The invoices or billing data is then captured by the orchestration system, and sent to the cloud portal system for viewing by customers.

It is important to understand that billing is an integrated part of each cloud provider’s provisioning system and cannot easily be separated. The integration of billing within each XaaS cloud provider’s system makes it possible to track both fixed-price and variable-priced services. Variable pricing occurs for any service that is configured to allow metered pricing based on storage, processors, or other resource utilization per billing period. Variable pricing can also occur, for example, when a customer upgrades its services in the middle of a billing period, and the price is pro-rated automatically by the system. To accommodate all of the possible scenarios, this architecture calls for the billing system to be very tightly integrated with the provisioning system. The resulting invoices or actual bills generated can be linked to the cloud broker for reporting purposes, or directly billed from the cloud service provider to the customer, depending on the type of contract.

Service actions

Service actions, within the cloud portal, are where the cloud customer can view or change an existing service subscription. A subscription might be one or more VMs or a particular application that has been ordered through the service catalog. After a subscription is active, customers can go into the cloud portal and add or change the subscription, adding additional VMs for example.

In addition to adding or removing services within a subscription, the cloud portal allows customers to pause, restart, or terminate a subscription. Terminating a subscription stops all billing, and all computing resources are cleared. Pausing a subscription simply stops the computing resources or applications but does not delete the data. This allows the customer to restart the subscription and compute resources whenever it needs them again. Depending on the cloud provider and portal capabilities, there might be other features within the subscription that can be turned on, such as taking VM snapshots, restoring a snapshot, rebooting a VM, and adding additional disk space.

The Orchestration Layer

The orchestration layer (see Figure 8-5) provides all logic, workflow, and integration between other layers of the cloud architecture. By using orchestration for most of the customization to meet customer needs, the higher and lower layers can be independently managed and upgraded. The orchestration system contains customized code and scripts and has the ability to interface and interact with multiple downstream XaaS cloud provider-provisioning systems. The layers architecture, and specifically the orchestration layer, is intended to hide the complexity of potentially dozens of private, public, hybrid, internal, and future unknown clouds, providers, and provisioning systems. The customer-facing cloud portal and other layers of the architecture should not experience any impact or need changing when a new provisioning engine is added or when something is changed, upgraded, or removed.

orchestration_layer_image

Figure 8-5. The primary functions within the orchestration layer include synchronization (aggregation) of the service catalog and reports that are pulled from all of the cloud service providers. This level of orchestration also handles any approval workflows of orders the customers place via the cloud portal layer. After an order is fully approved, the orchestrator uses API calls to initiate the appropriate cloud provider and the provisioning of cloud services — this includes the arbitration logic.

Approval workflow

Depending on the customer’s preference, the cloud portal layer sends all customer orders to the orchestration layer to handle workflow approval rules. All new orders trigger an email to one or more predefined approvers within the customer’s organization; the approvers then click the link contained within the email to launch the cloud portal and approve or deny orders. Upon approval, the orchestration system sends the necessary commands into the provisioning and billing system to launch the new service.

You can create or customize more complex workflows within the orchestration system without without affecting the higher level cloud portal or provisioning systems. This can include multilevel approval workflows, timed reminders of pending approvals, and inclusion of additional customer roles (e.g., procurement).

Ordering

The orchestration system receives the request from the cloud portal system whenever a new service is ordered, terminated, or changed. It contains the necessary coding and scripts to call APIs within the lower-layer provisioning and billing systems. In a broker environment with multiple downstream XaaS cloud service providers, new orders and requests are transmitted via standardized API calls to the downstream provider’s internal cloud management system. The orchestration system also detects the completion of the provisioning process to complete the overall workflow. These completion tasks include updating configuration, asset, and management systems, as well as updates back to the cloud portal status, reports, and dashboards.

Service catalog synchronization

The orchestration system pulls all current and changed services offering descriptions and pricing from downstream XaaS cloud providers and then sends this information to the broker-managed centralized service catalog, keeping it perpetually up to date. This synchronization can be scheduled to occur on a recurring basis, or whenever a change is detected; this is part of the API specification between the cloud broker and each downstream provider.

Billing and reporting synchronization

The Orchestration system captures billing, service, and resource utilization from the provisioning layer (and downstream service providers) and updates this information in the cloud portal for customers to view. The primary goal is to show customers their account balances and utilization, even if the actual billing is sent directly from each XaaS cloud provider; this arrangement depends on the governing contracts.

Centralized programming logic (including arbitration)

The Orchestration system is the primary location for all custom coding and scripts within the cloud architecture. The purpose of this is to keep the other components of the system as stock as possible, to allow for a wide selection of software options in each layer, aid in the ability to independently upgrade software with each layer, and centralize the “brains” and workflows of the overall system into the Orchestration system.

Within this centralized orchestration engine is where arbitration logic occurs. As described earlier, the cloud broker must determine which cloud provider is the best fit for each service catalog order. Sometimes, the cloud provider has already been chosen based on customer preference or based on a intentional hardcoded service catalog item that specifically indicated the cloud provider by name/brand. In an ideal dynamic scenario, the arbitration will use pricing, SLA terms, past performance, latency measurements, geographic location, or other metrics — or customer preferences — to make an automated decision on which cloud provider to send each service catalog order.

Integration with downstream XaaS cloud service providers

The orchestration layer, or modules within this layer, contains standardized API calls by which it integrates one or more downstream XaaS cloud service providers. The cloud broker assumes that there will be multiple cloud service providers contracted by the customer, with future as-yet-unknown providers to be integrated. Most cloud providers utilize different APIs (proprietary or industry-standard), so the orchestrator has a library of modules to support each provider and any unique capabilities of each.

The Provisioning Layer

The provisioning layer in this architecture provides three distinct functions that, depending on the selected cloud management system, can be separate software products. In a brokered cloud ecosystem, each downstream XaaS cloud service provider has its own cloud management tools that perform these or similar functions within its environments, interacting with the cloud broker at both higher and lower layers of this functional architecture.

These three functions are order processing and billing, control panels, and provisioning. It is preferred that all three of these functions be highly integrated or part of the same software system; otherwise, the level of complexity and integration that must be done can take millions of development dollars and years to complete. This is the most-often overestimated problem in the cloud management industry at this time, so preintegration of these functions is critical to success. In a cloud brokering model in which there are multiple XaaS cloud service providers, each of these providers has its own cloud management system, similar to the functions shown in Figure 8-6.

provisioning_layer_image

Figure 8-6. Provisioning layer (cloud service providers)

This layer is specific to each individual cloud service provider. The previous cloud portal and orchestration layers were hosted and operated by the cloud broker, which fed customer orders and provisioning requests, via APIs, into each layer — this is the cloud management system that each cloud provider owns and operates. Every cloud provider will have its own unique cloud management system, but to communicate with the broker, only the agreed-upon APIs can be used.

Many of the functions within this layer, and described in the list that follows, are similar to functions that the cloud broker performs, but again, these are very specific to the cloud provider and are also specific to the XaaS or applications that the cloud provider is hosting:

Order processing and billing

This functional area handles the definition and management of customers, subscriptions, and one or more cloud services ordered within each subscription. As customers place orders for services at the cloud broker level, these orders are then passed into this layer for the cloud provider to now process the order, start billing, and provision the actual compute and applications resources.

Depending on the cloud service that was ordered and the contract terms between the broker, provider, and customer, the billing might be a fixed price per billing period or variably priced, based on actual usage. The billing functional area handles all calculation of pro-rated billing, resource utilization metering, and generating an invoice at the end of each period. You can configure billing periods to be daily, weekly, monthly, quarterly, or yearly, and automatically renew until the customer cancels a subscription. During the initial order, the customer can also select a specific “end date” for its service from the service catalog, instead of a perpetual subscription.

The broker’s orchestration system synchronizes all billing activity, invoice history, and account balances with the cloud portal system. This hides the complexity of individual downstream cloud service provider billing systems.

Control panels

The control panel functionality provides both the provider and customers with multiple configurable roles-based access to a web portal. Through the portal or control panel, the provider or customer systems administrators — depending on their assigned role — can perform administrative tasks on their cloud services. This can include managing VMs, email mailboxes, user accounts, and wireless mobile devices. All infrastructure, software, platform, workplace, and even customer-owned applications hosted in the cloud are managed through this single control panel. Providing customers with the ability to manage their account and applications greatly reduces the number of support tickets that would otherwise need to be handled by the cloud provider.

This self-service control panel is a critical area that needs to be carefully evaluated when selecting control panel software; many cloud management systems and vendors provide little or no self-service administrative functionality. For every application or function that needs to be configured, the control panel should provide that ability to the customer. Without this detailed level of control, the customer would need to submit support tickets for routine administrative chores, costing a great deal in labor and time and going against the basic principles of an automated, on-demand, cloud service.

There is also an end-user control panel role. You can configure this to provide end users with limited abilities to update such things as their names, mailing addresses, and email account settings. You can turn off this end-user control panel functionality if the customer doesn’t want it.

In a cloud broker environment, there could be multiple control panels hosted by one or more of the downstream XaaS cloud service providers. Because there are multiple providers, the control panels for day-to-day administration are unique to each provider’s service offering. It is often unrealistic for the cloud broker to re-create all of the control panel functionality for each downstream provider; hence the likelihood of multiple self-service control panels. One method for achieving a truly integrated, single self-service control panel is to purchase all of the XaaS offerings from the same downstream provider as well as those of the broker.

Provisioning and application management

This functional area (see Figure 8-7) is where the interaction with the actual server farms and applications occurs. The provisioning system uses the APIs to call into each application to create, for example, new VMs, user mailboxes, Blackberry accounts, or Microsoft SharePoint sites. There are typically multiple modules within the provisioning system that the cloud software vendor has preconfigured for many of the top commercial off-the-shelf (COTS) products. The software vendor maintains this code and future upgrades as each COTS manufacturer releases new revisions. Because of this modular approach, upgraded modules do not break any other functional areas or layer in this architecture.

Beyond just COTS applications, the provisioning system must be extensible to create modules for customer-unique applications, other cloud providers’ software systems, and future applications that might need to be integrated. With all of these systems plugged into the overall provisioning system — and, by extension, the control panels — both the provider and customers benefit from managing everything from a single cloud management system. All applications and services utilize the overall billing, resource metering, reporting, and service catalog systems.

In a cloud broker environment, these API calls would communicate provisioning requests to downstream XaaS providers rather than remain within a single cloud broker’s management system.

provisioning_and_application_mgmt

Figure 8-7. Orchestration layer

Integration with systems management

The orchestration system integrates with the systems management layer. The orchestration system updates the asset, configuration, and management system databases each time a new customer or service is ordered and provisioning is completed. This keeps the network, security, and application monitoring and management functions always updated with the latest VMs, applications, customers, and users that have been brought online.

The Systems Management Layer

The systems management layer consists of all the network, server, security, and application management tools (Figure 8-8).

sys_mngmnt

Figure 8-8. Systems management layer

In a cloud broker environment, each individual cloud service provider has its own systems-management layer. Each is also responsible for providing status, performance, billing, and other information to the cloud broker through standardized APIs — this is the aggregation function that the broker performs. The cloud broker provides at least an overall view of the cloud environment, system status, performance metrics, and SLAs. Here are some areas in this layer:

Datacenter management

This functional area contains numerous datacenter management systems such as power, HVAC, physical security, power distribution units, communications circuits, and anything else related to the physical datacenters, including redundancy and ongoing management of these facilities.

Configuration and asset management

This functional area holds the configuration information for every physical or virtual server, application, and other computer or software asset in the datacenter. Specifically, in a cloud environment, the automated provisioning of VMs, storage allocation, and applications mean that these configuration and asset databases should be updated in as close to real time as possible. Equally important is the automated updating of these databases whenever a system or application is changed or disabled. This reference architecture calls for a fully automated update to these systems, handled by the orchestration system. This information is also available to customers via the cloud portal system for reporting; customers want visibility into their cloud environment, so an accurate and up-to-date asset and configuration database is a must to provide this transparency.

Security management

Similar to configuration and asset management, the automated updating of the security systems is critical. There should be little or no delay from the point at which a new VM is ordered and launched until an initial security scan is performed. The VM should also become part of the overall network as a fully monitored node. Disabling users and service termination must also be synchronized across the cloud in as near real time as possible.

Event and performance management

This functional area handles the monitoring of the network, servers, and applications for both status and troubleshooting purposes but also for performance management. By managing the performance of VMs and applications running in the cloud, customers can be automatically informed when a VM or application is reaching its maximum processor or memory thresholds. Depending on the service offering that the customer orders, the cloud system can automatically increase resources for the VM or just advise the customer of the recommended upgrade in services.

Although individual cloud service providers perform their own datacenter, network, security, event, and performance management, it is the broker’s responsibility to aggregate all of this data. Cloud consumers are not aware of, nor have the ability to access, each individual cloud provider’s data, so the aggregation, reporting, and dashboard views provided by the broker are critical for customers to have visibility into the overall cloud ecosystem.

Governance

Governance is a significant part of a successful cloud brokering solution. There are several standards, processes, and coordinating activities that either the cloud broker or the end customer must perform. Often, large organizations and government customers need and want to be the centralized IT provider of cloud services to their departments or subagencies; therefore, these agencies need to take on many of the governance functions. I caution large customers who do not have the necessary personnel, expertise, or desire to take on this level of governance to consider assigning this responsibility to an experienced third-party contractor.

Specific essential governance functions include the following:

Security accreditation

The accreditation of the cloud broker and downstream XaaS providers can be performed by the customer or a third-party independent organization, but the standards that need to be met must come from the customer or parent organization in coordination with the cloud broker, given that the broker ultimately has responsibilities to ensure security, operations, monitoring, and reporting.

Operational procedures

As the normal operation of server farms, storage, network, and applications will be transferred to the cloud broker and XaaS providers, the level of involvement by the end consumers or organizations will significantly change. The customer must determine what level of interaction in network, security, and operational monitoring and events it wants to assume so that the cloud broker can provide this level of visibility into the unified portal.

Contracts and procurement

How cloud services will be acquired contractually through the procurement process is something the customer or parent organization must determine. The cloud broker can provide a service catalog and workflow process, but this needs to be customized and approved by the customer to meet regulatory or internal standards. The customer must also determine if the broker is contractually or legally liable for all downstream XaaS providers (essentially making the broker a reseller of the other provider services) or if the customer will contract with each downstream XaaS provider themselves; therefore the broker is only a coordinator and aggregator rather than fully responsible for subordinate providers.

SLAs

The customer should specify the SLA to be met by the cloud broker and downstream XaaS providers. Normally, these SLA standards are published and part of the contractual obligations as each cloud provider is evaluated. Set an SLA standard so that individual procurements or subagencies that purchase services do not individually set or attempt to control individual SLAs. Having multiple levels of service is possible, but individual SLAs for every subagency or consumer can become difficult to manage.

Who exactly tracks and enforces the SLA can vary depending on whether you, the customer, have chosen and established contracts with each XaaS cloud provider or if you have left it to a hired cloud broker to form those contractual relationships. If you hire a managed cloud broker as a service provider, it is often best to allow the broker to negotiate its own contracts and enforce all terms and SLAs with each downstream XaaS provider. You as the customer can influence which XaaS cloud providers are chosen, but if you maintain the contract to these XaaS providers, the broker has no legal authority to enforce the SLA on your behalf.

Selection of XaaS cloud providers

Normally, you as the customer evaluate and select the managed cloud broker service provider or contract with a systems integrator to implement a broker capability within your organization. Then, evaluating and selecting each downstream XaaS cloud service provider can be done by either party — the selected broker or you, the customer. If you are hiring a managed broker service, you might want to allow the broker to take responsibility to select their cloud providers (essentially, their business partners that they then manage and coordinate). If you are operating your own cloud-brokering system, you might want to select the cloud service providers, in which case you directly negotiate the contracts and service terms with each provider as well as own the ongoing business relationship.

Data Portability

Customers considering cloud brokers normally ask for the ability to move data from one XaaS provider to another. Maybe the individual provider is not meeting the desired SLA, has had technical difficulties, or has changed terms or pricing; all things from which the consuming organization wants to be protected. Although they might not have worded the requirement this way, the real need is for data and system portability — the ability to move applications and data from one provider to another.

Complete and automated portability between providers has traditionally been difficult; this is both a technical and a business challenge at a time when the industry had few standards and proven methodologies. More recently, several industry standards — with the blessing and inclusion in NIST publications — are now beginning to be widely accepted and implemented.

Standards for IaaS application interoperability, VM, and data portability come from the Open Cloud Computing Interface (OCCI) specification, which was established by the Distributed Management Task Force (DMTF). The VM portability specification Open Virtualization Format (OVF)from DMTF is still progressing as a leading pseudo standard. The Topology Orchestration Service for Applications (TOSCA) from OASIS is also maturing standards relating to IaaS and PaaS for portability of workloads — this is arguably the industry’s leading standards organization working on true automated lifecycle management and portability of services between cloud providers.

Moving the more advanced PaaS and SaaS platforms and applications represents a more significant challenge than just moving basic VMs. Data hosted at one provider might need to be converted into a different database format, re-indexed, or adopt a new data structure, for example. The ultimate objective would be fully automated portability of systems and data between cloud providers, acheiving true interpretability, arbitration, and dynamic workload distribution across multiple cloud providers — this is the standard toward which TOSCA is working.

Key Take-Away

The ability for a cloud consumer, or even a cloud broker, to just “push a button” and automatically port applications and data to another provider is difficult at this time. The broker is the party in the cloud ecosystem with the incentive, mandate, and ability to be the interoperability enabler between providers. Upcoming industry standards such as TOSCA will greatly accelerate the capability for automated portability between providers.

Some industry groups are attempting to become the standard for cloud-based portability and interoperability, but we are still a long way from having cloud providers all adopt the same standards, much less agree with one another on true interoperability. Some of the current “open” cloud standards are still not fully complete in capabilities, to say nothing of ubiquitous acceptance. There are also numerous software companies with new or soon-to-be-released products that aim to improve workload portability between cloud providers. I predict this specialized category of software will be a fast moving hot topic in the next two to three years. My concern with the current software tools proclaiming to have solved this problem is that they are very specific solutions that might claim to be open source or universally useful, but in reality, they require their brand of software application engine be utilized on both the source and destination cloud providers, which is really not an agnostic industry-wide solution to the problem.

A technique that is recently gaining popularity is application containers (discussed in Chapter 4). Using application containers, portability is achieved by moving the containers (such as the open source product Docker) from one VM to another — even across cloud providers. As long as both the source and destination compute resource is running the Docker application engine, the container will run the same application on the new system, without being recompiled or modified. This doesn’t necessarily move the associated application data, but there are many other techniques for porting this between systems or providers. This is just one technique to show an example; however, there are significant limitations (not to mention each application container requires that you use only that software vendor’s underlying application engine), so application containers is not going to resolve the industry-wide portability concern.

One way to get a level of portability between cloud providers today is to use the cloud broker to do the heavy lifting. The broker will utilize a combination of available industry standards as they become available as well as custom programming to try to integrate with the multiple downstream cloud providers. This can be as simple as porting a VM image between providers, to complex multilevel applications and databases, which requires more significant programming of the migration technique. Truly, the broker is the only party in the cloud ecosystem with the incentive, mandate, and ability to be the interoperability enabler between providers. Asking downstream providers to “work together,” or wait for sufficient standards to mature is not a plan for success. Even when standards do come along, become mature, and are widely adopted, they will be able to handle only simple tasks such as file and VM portability. Complex application stacks will never be as easy as “push a button” without significant custom programming by the broker — for every porting request.

Evaluating and Selecting a Cloud Broker

As I mentioned earlier, there are no public cloud broker service providers in the industry at this time. Existing public cloud providers are focused on keeping customers managed within their domain of service offerings and have no financial incentive to make it easy to integrate (or broker) with other cloud providers. Brokering is deployed by installing a cloud broker management system within your own datacenter or leased facility. There are some specialized systems integrators that concentrate on cloud brokering that are planning to offer a managed-community cloud broker service; however, the level of complexity and customization required per tenant or customer is very challenging.

There are a few large commercial and government organizations that have begun to deploy a full cloud brokering system, and they, too, are encountering significant challenges in business processes, technical processes, and industry standards. Many of these are explained throughout this chapter.

Key Take-Away

There are no true commercial cloud broker offerings in the industry at this time. Early cloud brokering attempts by some commercial and government organizations are encountering challenges in business process, technical methodology, and limited industry standards for multiprovider integration and portability.

As you begin to assess your potential use case for cloud brokering and evaluating cloud management platforms, here are some basic capabilities by which you should evaluate a potential cloud broker platform or provider:

§ Extensibility of the system through standards and APIs so that multiple independent cloud providers can easily integrate their offerings. Open standards such as OpenStack might be a good start for provisioning and integration using APIs, but it still lacks many of the advanced cloud brokering capabilities, multiprovider billing, security, and operational management.

§ Dashboards and reporting systems that centralize all customer views and data from the downstream cloud providers.

§ An aggregated billing and metering system to provide a single system of tracking usage and costs across all downstream cloud providers.

§ An aggregated service catalog by which customers can easily order all services from any provider from a single interface.

§ An approval workflow system that routes all customer orders to one or more designated approvers within the customer’s organization before money is spent.

And here are some questions you need to answer before making your decision:

§ Has the cloud broker already created a library of preintegrated modules for the top industry cloud providers? This option could provide better integration and faster deployment of your cloud service, because the broker has already done the integration, coordination, and licensing to other third-party providers.

§ Does the cloud broker utilize any existing cloud service interoperability standards, and what is its plan to keep up with open standards, participate in industry standards creation, and update its systems to remain compatible with proprietary cloud provider APIs?

§ Will the cloud broker contract directly with your organization or government agency? Is the broker management platform hosted by the provider, or can it be implemented at the customer’s premises if desired? Must I, as the customer, manage the cloud broker management system and providers or is this available as a managed service offering?

§ Can the broker provide assistance evaluating and integrating new downstream cloud providers? Will the cloud broker be capable of configuring some data portability or interoperability between downstream cloud providers to compensate for today’s lack of sufficient interoperability standards?

This last question brings up a key consideration: should the cloud broker you select also be allowed to bid on or function as one of the downstream XaaS cloud providers? Some cloud service providers or cloud broker management software vendors are also XaaS cloud providers. Given their expertise in this particular type of multiprovider service ecosystem, this might represent an advantage to you as a customer. Some organizations might consider this an unfair advantage, whereas others will realize that there is a benefit to having some services operated by the same provider, such as better integration, faster deployment of new services and enhancements, and more consistent portal interface and self-service capabilities.

Challenges of Cloud Brokering

I’ve stated before that cloud computing as an industry still in its adolescence. Extending that metaphor, cloud brokering is in the infancy phase. As of this writing, there are no commercial cloud brokers in the industry, but many large commercial and government agencies are planning and piloting systems — learning how to best create, contract with, or become a cloud broker.

Some of the challenges of cloud brokering that the industry has learned include the following:

§ Each downstream XaaS cloud service provider uses an internal cloud management system, service catalog, orchestration, provisioning, reporting, operations systems and processes. The broker must determine which functions need to be integrated and aggregated at the broker level, which functions are best left to each cloud provider, and how or what to present in a unified customer experience. Terms like aggregation and intermediation are used in the industry, but few detailed use cases and real-world examples exist.

§ How will the broker show multiple XaaS providers offering similar services, and how are unique offerings distinguished to the end consumer? Depending on the contractual relationship between the broker, customer, and each XaaS provider, the broker might not be responsible for marketing each downstream XaaS, so there is a level at which each individual XaaS provider must interact with the broker as well as the consumer. If the broker is fully responsible for all brokered services and each XaaS provider, the customer might never see, know about, or need to work with individual XaaS providers.

§ The largest cloud service providers offer multiple deployment models, public, private, and virtual private, but some cannot or refuse to comply with certain government standards (such as financial audit or unique compliance regulations) and therefore partner or sell through other vendors. The broker must coordinate with multiple types of cloud providers and resellers, and even legacy customer datacenters that must be integrated into the cloud broker system.

§ The investment and technical sophistication required to become a true broker is significant. The broker must have the investment, expertise, and a library of preintegrated XaaS connectors to downstream providers. There will likely be only a few dominant mature cloud brokers in the industry — others being systems integrators deploying brokering platform software for individual or dedicated customers. Brokers must also spend a significant amount of time and money maintaining and monitoring their integration and connections to each XaaS provider as new features are enabled, new providers join, and integration APIs mature in the future.

§ Meeting customer requirements to customize is also a challenge because the broker has a necessary goal to use the same integration and connector tools for multiple customers and XaaS providers. A custom, unique broker system for a single customer is always possible but will often be cost prohibitive to the end consumer.

§ Brokering is the newest role in cloud computing. No mature models or providers are on the market yet, so there will be a limited number of cloud-broker management platforms, and tens of millions of dollars invested by a broker just to create an initial offering.

§ Many large commercial and government organizations have solicited requests for information or proposals seeking cloud brokering, but few of these show a true understanding of brokering. Many of these RFI/RFPs ask multiple competing cloud providers to “just get along” without standards or ask systems integrators to build a cloud broker platform costing tens of millions of dollars with little or no commitment by the customer, which represents huge, often unreasonable, risk to the systems integrator.

§ The ability to provide a customer-owned and operated cloud broker solution versus that of a vendor has both initial investment and ongoing management cost considerations. Some cloud brokers can only be the host and operator and do not want to develop code or manage on-premises implementations for customers.

§ There is no “move” button to automatically migrate data and services between cloud providers. The type of XaaS matters; moving a VM is relatively easy, but moving applications, data structures, and networking is not easily automated. Lack of portability standards means the broker might need to create a combination of open source and proprietary code to facilitate service migration between downstream XaaS providers. As open source systems or industry standards mature, brokers will need to constantly adjust their systems.

§ Should the cloud broker invest in the creation of a library of preintegrated service connectors to downstream XaaS providers? Or, should it allow customers to pick their own XaaS provider and try to integrate these independent providers, one at a time, using industry standards if they exist or the proprietary API that each XaaS provider uses?

§ Customers concerned with vendor lock-in at the cloud service provider level can look to a cloud broker model. Customer lock-in at the cloud broker level is still a concern, but early analysis indicates that trying to use multiple cloud brokers will present significant (possibly insurmountable at this time) issues — a single, well-chosen cloud broker service or an internally deployed broker software platform is recommended.

§ Procurement challenges:

§ Will the customer procure a single broker service and then multiple XaaS cloud providers through a single contract with broker or multiple contracts to each of the downstream XaaS providers?

§ Is there a procurement process (e.g., a purchase order) for every micro-transaction purchased in a cloud service catalog? How can each transaction from the service catalog be actively or passively approved without contract or procurement personnel involved on every order?

§ How are variable-service costs (e.g., expanding storage and VMs) handled? Alternatively, do you fix costs, and therefore disable automatic expansion?

§ How will chargebacks to consuming subagencies be tracked? Will subagencies submit their own procurements, or submit to a parent organization before going to cloud provider or broker?

§ Contractual issues:

§ Should procurements of XaaS to cloud providers go through the broker? Alternatively, if contracts are issued to multiple downstream XaaS cloud service providers, it becomes more difficult to ensure integration and avoid unique characteristics.

§ Is the broker allowed to also provide one or more of the XaaS cloud services, or is it prohibited from also being a cloud service provider?

§ A broker is more likely to have better integration and faster deployment of XaaS compared to a third-party provider that has to integrate with the broker’s system

§ A broker might need to provide interoperability, portability, and advisory services to the customer as a function of being the broker, so a conflict of interest is possible; this broker might not be allowed to provide all XaaS

§ Security accreditation:

§ Will consumers of cloud services accept the security accreditation of the parent organization? Will a government standard for cloud security such as FedRAMP apply and be sufficient for cloud brokering technologies and broker/provider relationships?

§ Can traditional security processes change to precertify VM and platform templates so that they can be automatically deployed 24-7-365 without human intervention?

§ What level of visibility, monitoring and shared management is possible between the customer and broker all the way down to the individual cloud service providers?

§ Will multiple levels of security, particularly in government clouds, be allowed? Can the same cloud broker system provision and manage XaaS at multiple levels within FISMA and DIACAP?

§ SLAs:

§ How will SLAs be established?

§ How are they managed, aggregated, and reported across multiple cloud providers?

§ Who enforces the SLAs: a hired cloud broker or the end customer?

§ Will consuming agencies agree to use the same SLAs that are essentially prenegotiated with the cloud service providers of XaaS?

The Future of Hybrid and Cloud Brokering

Hybrid clouds will become the most common form of cloud model in the industry. Customers of the cloud already want combinations of public, private, and legacy datacenter cloud enablement, so eventually the hybrid cloud will be the norm. Techniques for hybrid clouds and cloud brokering are very similar, differing primarily in the role, governance, arbitration, and level of integration between clouds and enterprise datacenters.

Key Take-Away

Techniques for hybrid clouds and cloud brokering are very similar, differing primarily in the role, governance, arbitration, and level of integration between clouds and enterprise datacenters.

Hybrid cloud will soon become the so prevalent in private and public clouds — with optional integration back to on-premises datacenters — that the line between internal private clouds, public cloud providers, and legacy datacenters is already blurring. Although there are clear technical, operational, and governance differences with the cloud broker role, this, too, will merge into the hybrid cloud model as currently defined.

As hybrid clouds and the cloud broker role matures over the next two to five years, here are some key areas that will evolve and become more sophisticated:

Portability

Significant new standards need to be created, vetted, tested, and matured over the next few years to enable true system and data portability between multiple cloud providers. Along with improved standards, the sophistication and automated movement of XaaS workloads and data between cloud providers will evolve. Future hybrid clouds and brokers will be able to shift services between datacenters and cloud providers to achieve maximum availability, scalability, and lowest cost — all of this with zero outages or customer impact.

API standards

Standards by which a cloud broker and multiple downstream cloud providers integrate will need significant improvement. Currently, there are some standards or open source systems such as OpenStack, but none of these completely cover every aspect of provisioning, reporting, portability, and operational management standard APIs. As APIs and portability standards are created and eventually adopted by cloud brokers and XaaS cloud service providers, hybrid and cloud brokers must continuously update their software systems.

Preintegration of XaaS providers

Many hybrid providers and cloud brokers will not wait until contracted by a customer to begin creating a library of preintegrated connectors to downstream XaaS providers. The larger cloud brokers will proactively create relationships (e.g., resell or white label) multiple downstream XaaS providers. As stated earlier, many public cloud providers will also launch hybrid services to improve integration back to existing enterprise datacenters.

Software-defined datacenters and networking

Achieving true dynamic arbitration and portability of services between cloud providers will require more adoption and maturity in the areas of virtual networking, IP addressing, DNS, and virtual local area networks (such as software-defined datacenters and software-defined networks). If the broker controls all aspects of the virtual networking and addressing, moving cloud services from one provider to another can be performed without affecting the customers — this is the ultimate goal but not a reality today.

Dynamic arbitration logic

Future cloud brokering technology, services, and cloud management systems will shift from today’s mostly static-rules logic to more dynamic learning engines for arbitration. This means that statistics on utilization, performance, SLAs, network latency, and even security and pricing factors will be continuously analyzed to determine which of many XaaS cloud providers should be used for any given workload. This dynamic method of automated decision making can still have some customer-provided influence, policies, or choices within the calculations with regard to which cloud providers to provision cloud services. Providers that are faster, cheaper, and more reliable will receive more new customers and workload; automatically moving workloads between providers with little or no customer service disruption. Cloud brokers will be able to utilize this advanced dynamic arbitration logic and portability to shift workloads in order to ensure SLA adherence, performance, reliability, and price. Imagine the cloud broker automatically selecting and shifting workloads between multiple providers almost as automated as a network traffic load balancer.

Hybrid and Cloud Brokering Best Practices

Based on lessons learned and experience from across the cloud industry, you should consider the following best practices for your organization’s planning.

Hybrid versus Brokering

Many organizations misuse the term “brokering.” Hybrid clouds typically begin with a private cloud for most services, automation, and operations with the added ability to provision to one or more XaaS public cloud service providers. Brokering is an IT service marketplace provider role, which uses more advanced aggregation, arbitration, and intermediation technologies across numerous XaaS cloud providers, often without a private cloud infrastructure. Specific differentiators between hybrid clouds and cloud brokering include:

§ Techniques for hybrid clouds and cloud brokering are very similar, differing primarily in the role, governance, arbitration, and level of integration between clouds and enterprise datacenters.

§ Cloud brokering management platforms have a more significant focus on service arbitration across numerous providers, whereas a hybrid cloud might only have limited statically scripted provisioning capabilities to one or two third-party cloud providers.

§ A cloud broker utilizes advanced dynamic-arbitration logic engines to determine the best cloud provider for any given customer order. These advanced arbitration services can use performance, price, analytics, geography, and customer preference data to automatically recommend which cloud provider should be used for any given XaaS workload. A hybrid cloud might have only basic and static, hardcoded rules or policies with much less sophistication in the arbitration logic.

§ A hybrid cloud will have its authentication, directory services, management, security, and monitoring tools and standards established based on the private cloud operator. A cloud broker environment has far more complexity and quantity of providers and management tools that the broker needs to establish as well as publish APIs to each cloud provider, while managing and aggregating these intermediated services.

Brokering Role

Determine if your organization wants to own and operate the brokering process and technology, or if you want to outsource this to a cloud brokering service provider. You’ll need to consider the following:

§ Organizations that want to function as the broker must perform the governance, set standards, coordinate procurements, promote and support client-organizations, and continuously upgrade the cloud brokering platform software. Organizations also evaluate, select, and contract with each downstream XaaS cloud provider based on end-user needs.

§ Outsourcing the cloud brokering management requires much less involvement and operations by the customers and consumers of the cloud services. The cloud broker handles all integration and contracts with each downstream provider. The cloud broker manages the entire environment with some input from the customer on desired policies and governance issues.

Hybrid and Cloud Brokering Platforms

You should evaluate a potential hybrid or cloud broker platform or provider using the following criteria:

§ Extensibility of the system through standards and APIs so that multiple independent cloud providers can easily integrate their offerings. Open standards such as OpenStack might be a good start for provisioning and integration using APIs, but it still lacks many of the advanced cloud brokering capabilities, multiprovider billing, security, and operational management.

§ Dashboards and reporting systems that centralize all customer views and data from the downstream cloud providers.

§ A billing and metering system to provide a single system of tracking usage and costs across all downstream cloud providers.

§ A service catalog by which customers can easily order all services from a single interface.

§ An approval workflow system that routes all customer orders to one or more designated approvers within the customer’s organization before money is spent.

And here are some questions you need to answer before making your decision:

§ Has the cloud broker already created preintegrated API modules with popular downstream cloud service providers? This option could provide better integration and faster deployment of your cloud service, because the broker has already done the integration, coordination, and licensing to other third-party providers.

§ Does the cloud broker utilize any existing cloud service interoperability standards, and what is its plan to keep up with standards, participate in standards creation, and update its systems to remain open or proprietary?

§ Will the cloud broker contract directly with your organization or government agency? Is the broker management platform hosted solely by the provider, or can it be implemented at the customer’s premises if desired? A cloud broker might also have designed its cloud management system to only be deployed and run from the cloud provider’s network, not a dedicated on-premises installation at a customer-specified facility.

§ Can the broker provide assistance evaluating and integrating new downstream cloud providers? Will the cloud broker be capable of configuring some data portability or interoperability between downstream cloud providers to compensate for today’s lack of sufficient interoperability standards?

Broker Governance

Understand that governance is a significant part of a successful cloud brokering solution:

§ The cloud broker management platform can be hosted by a provider, or implemented at a customer-specified facility.

§ There are several standards, processes, and coordinating activities that the cloud broker or the end customer must perform. Often, large organizations and government customers need and want to be the centralized IT provider of cloud to their subagencies or consumers; therefore, these agencies need to take on many of the governance functions.

§ Specific governance functions that need to be performed include security accreditation, operational procedures, contracts and procurement, SLAs, and selection of XaaS cloud service providers.

Service Portability

Customers need to understand that porting of cloud services or data from one provider to another is not as simple as “pushing a button.”

§ The process and technology standards are not mature enough in the industry to make porting an automated process. A cloud brokering provider is best suited to establish the necessary integration APIs and processes to facilitate portability — potentially charging customers for the migration as there is still some level of manual configuration and testing/QA required.

§ In an ideal scenario — possibly sometime in the future — a cloud broker could move VMs or other application workloads between XaaS providers with zero downtime or customer impact. This future capability requires significant maturity of industry standards and software-defined networking to automate the porting.