September 26, 2014 | Written by: Manish Gupta
Share this post:
This is the final post of a five-part series on cloud brokerage. In previous posts, I’ve explained application and management stacks, looked at ways to migrate from one stack to another, and specified some challenges that may occur during migration. In this post I’ll provide a concise summary to wrap up the series.
A consumer may decide to choose one or more application stacks to host their overall application suite for a variety of business reasons, including:
• Improving speed-to-market
• Reducing costs
• Precluding vendor lock-in
• Attaining a better service level
• Improving geographic presence
Some examples of real scenarios in a hybrid cloud include:
• Utilizing a public cloud (like IBM SoftLayer) for workloads that are less critical for business (like development or tests for upcoming new projects) and keeping the highly- critical ones on a private cloud
• Using cloud for disaster recovery
• Creating cloud native workloads (including systems of engagement and insight) on clouds like IBM Bluemix with databases on a private cloud on IBM SoftLayer
• Keeping systems of record in a private cloud environment while moving the traditional systems of engagement to clouds like IBM Cloud Managed Services.
More complete and detailed accounts of these examples are available here.
With the number of players in the cloud arena growing by the day, consumers have a lot of choices regarding the best method to run their workload. The workload could comprise multiple application stacks (as discussed in the first post of this series) or any single variant thereof. Our discussion in earlier sections can be summarized in the following figure.
Cloud brokerage components to support contestability
In addition to the basic components of aggregation, integration and customization, a cloud broker needs to provide added value by supporting migration (or workload mobility) from one service provider to another. Further, a broker needs to support managed services for the workload.
Composing a managed stack may lend itself to managed service contestability. Coming to a decision about service migration necessitates an analysis of risk and security when choosing a particular service provider for either the application or management stack.
New opportunities to choose a new application or management stack will be created using the analytics and optimization module that will look across the providers and current stacks for such opportunities.
And finally, all this can be possible by keeping service models of candidate services along with interoperability and interconnectivity models.
A cloud broker cannot create these models on its own. It only needs to provide a framework and allow the community to create these models, which is a topic for a future blog post.
I hope this series has been helpful. If you’d like to continue the conversation, please leave a message below.