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.
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:
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.
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).
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:
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.
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.
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 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.
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.
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.
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 (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.
Here’s what you can find in the portal:
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.
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, 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 (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.
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).
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.
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.
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:
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.
The systems management layer consists of all the network, server, security, and application management tools (Figure 8-8).
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:
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 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:
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.
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.
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.
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.
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:
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.
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:
Based on lessons learned and experience from across the cloud industry, you should consider the following best practices for your organization’s planning.
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.
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.
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?
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.
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.
18.119.167.173