September 16, 2014 | Written by: Manish Gupta
Share this post:
During a recent client engagement, a banking client put forth a requirement that, as they reorganize their IT environment by setting up a hybrid cloud, the new model should allow for contestability of public cloud services. They desired the ability to switch to those services which are superior (or “best of breed”) from a functional and non-functional perspective. What they ultimately wanted was to create an advanced cloud broker capability.
An introduction to cloud brokerage can be obtained from a host of material on the Internet; I recommend a quick read of a post by Maciej Sztukiewicz. The purpose of my series of posts is to share my thoughts on the challenges that would be faced by a broker in trying to support contestability of services in an enterprise environment. In such a situation, the broker would need to provide two things:
– The ability to migrate a workload or application from one service provider to another
– The ability to manage a workload across the different service providers that collectively provide the overall service (note I am talking about “managed” enterprise workloads)
In the first part of my series, I’ll define what I mean by a workload or application stack and a management stack. In subsequent posts, I’ll discuss a variety of application stacks on which consumers can run their workloads and the challenges associated with each option, and I’ll examine the challenges of creating a management stack due to the various options available today. I’ll also discuss the factors that can affect the migration and management of a workload onto a target cloud so as to support service contestability, and will conclude by providing an architectural overview.
Application (or workload) stacks and management stacks
An application (also called a workload) consists of application software and data, as well as a configuration associated with each that configures their respective runtime (see subsequent figure). The runtime may be obtained directly from the operating system (OS), the containers, specialized middleware or a database.
View of a typical application (or workload) stack
Depending on what a cloud service provider offers out-of-the-box as its service, the workload that runs on it may be comprised differently. For example, a service provider may allow running a guest OS on a virtual machine as part of the service. In this case the workload would comprise the application software, data, middleware, databases and the guest OS, in addition to the custom configuration for each of the stack elements. One could package the application using the format espoused by the service provider and then deploy the application using the deployment tool, most likely to be obtained from that provider. Some sample formats are TOSCA, HOT and AMI. A cloud consumer could have multiple workloads and each might use a different packaging.
If the cloud provider allows only the choice of running the middleware or a database, then the guest OS would not be part of the workload on that cloud.
Enterprise business critical workloads typically require managed services—for example, incident, problem or change processes; patch and security compliance; service level agreement (SLA) management; monitoring and event management; backup and recovery and a host of other services. The management services consist of three key components: tools, processes, and people (see the preceding figure). Together, this is what we call the management stack.
– The tools component consists of any management tools or services used to manage an application stack, such as an application performance monitoring tool like IBM Tivoli Composite Application Manager for Application Diagnostics (ITCAM) or a monitoring software as a service (SaaS) like IBM Service Engage.
– The processes component corresponds to the processes that are followed by an IT department to manage the IT, such as an incident management process for handling incidents that correspond to events generated by the IT environment.
– The people component corresponds to the skilled people who are required to use the management tools and provide management services for the application stack.
The management stack may come partially from the service provider that hosts the workload stack. For example, the service provider in the above example could offer an availability SLA up to the hypervisor. However, above the hypervisor, the management responsibility may lie with the consumer. The consumer would then be responsible for extending the management stack to provide an end-to-end managed service. This might involve contracting one or more management service providers to provide a portion of the management stack extension while keeping the rest in house.
In the next blog posts, we will look at the variety and nature of application stacks that cloud consumers can construct and more.
What are your thoughts on cloud brokerage? Leave a message below to join the conversation.