“Lock in a position on AWS for my workloads now before the holiday rush!” That’s a Cloud Broker right? Not quite yet. Ok, how about “I’m meeting with a Cloud Broker this Saturday to show me around a few nice cloud service provider units on the Upper East Side Geo-location”. That is a Cloud Broker… well closer but not exactly. Ok, so what is a Cloud Broker and why should I consider one?
Fair question, the terminology has been around for a few years with NIST recognizing it in their reference architecture back in 2011. In the above two examples there is a common attribute of professional services. They are providing their expertise in a dynamic market to simplify a myriad of choices into a select set of results from which you can compare and choose. In a like manner, one aspect of Cloud Brokering is to aggregate the many cloud service provider options into a comparable list of choices.
Easier said than done. Unlike the more mature markets of equities and real estate, there are few common standards across the product lines of cloud service providers. Provisioning a simple two tier application development environment in Amazon Web Services is performed differently than the same task in Microsoft Azure. This difference extends across their respective compute, storage and network resources from how they are provisioned, monitored and charged for. Ideally a Cloud Broker service will mask the differences and assimilate the infrastructure lifecycle management into one interface.
Ok, so what else? Control. With a single interface I have a single point of access. One set of authentication credentials to access multiple provider resources. Once in place I should be able to perform actions like defining governance policies, set spending limits and restricting resource utilizations.
And there is more, Automation. The underlying instrumentation that pulled these disparate cloud service providers together as one lays the groundwork for a new level of automation. Monitoring actions can trigger provisioning reactions. Capacity decisions can be codified into an automated sequence of events to scale infrastructure accordingly. More advance scripting can shift workloads from one service provider to another in the event of service disruption.
Up to this point I’ve strayed a bit describing the characteristics of an advanced multi-cloud management system. As pointed out earlier above there is a professional services aspect. A Cloud Broker’s market is comprised of many cloud service providers with various capabilities, price points, regulatory compliance and service levels. It requires experience in service intermediation and continuous technological familiarity to maintain the necessary expertise required for developing that short list of providers that match a customer’s needs. A Cloud Broker will establish a single point of contact for support at a consolidated price that eliminates “dealing with the many” and fills in the gaps between service providers and the enterprise user’s expectations.
Speaking of the Enterprise, I would expect my Cloud Broker to assist in integrating this new infrastructure as a service into my existing IT Service Management. Plugging it into my Service Request engines that will drive automated approval workflows resulting in an IaaS order fulfillment satisfied through the brokered cloud service.
A Cloud Broker is more than just a toolset for aggregation, automation and integration, but also an in-line consultation to the cloud “as a service” models. Masking the non-standard interoperability complexities behind an integral interface for enterprise usability.
Where is all this leading us? It will turn the front-end process of acquiring compute resources into a simple end user procurement exercise the likes of which we experience today with airline, car and hotel reservation systems. Further down the road, the backend commoditization of compute will fulfill its true definition through standardization and containerization technologies that turn my initial Cloud Broker analogy above into a reality.