September 25, 2014 | Written by: Manish Gupta
Share this post:
According to Gartner, one role of an IT department is to be a cloud services broker (CSB) for sourcing external services. However, I personally believe that a full-fledged CSB also requires dynamicity in decision making, experience managing IT for others, technology to aggregate IT capabilities from the market and various other considerations that go beyond the capabilities of a typical IT department.
This is the fourth post in my series about cloud brokerage, and I’ll be looking into the factors that can affect the migration and management of a workload onto a target cloud so as to support service contestability. In previous posts I have discussed application and workload stacks, management stacks, and some challenges that you may encounter with these stacks.
Migration from one application or management stack to another
In the second and third parts of this series, I noted that a cloud consumer faces a couple of difficult decisions or challenges when choosing a service: namely, whether to place all applications on the same cloud or to distribute them over multiple clouds, and which of the variety of different packaging formats for the application and middleware stack will best suit the consumer’s needs.
These challenges would be passed on to a specialized cloud broker if the job is outsourced. This also creates an opportunity for one cloud broker to excel with respect to another. A cloud broker can play a key role in brokering cloud services for application stacks as well as for management stacks. A management stack can be changed independent of the application stack. However, any a change in the application stack requires reconsideration of the management stack.
Some key factors that influence the decision of a cloud broker
A cloud broker is expected to evaluate any change in the application stack with respect to the key factors shown in the preceding figure. These factors should be considered in light of the consumer’s functional and non-functional requirements (the latter may include regulations such as residency for data and the management stack). A cloud broker should also provide decision-making tools (for example, Pareto analysis-based tools) that will rapidly allow a consumer to clearly see tradeoffs in various parameters, which can facilitate quick decision-making.
The following paragraphs present key parameters that need to be considered.
The broker is expected to maintain relationships with multiple vendors on behalf of the consumer and to understand the consumer’s constraints for vendor selection. For example, a consumer might bar a particular vendor from providing any services or might require some level of experience or financial health from the vendor. Different consumers can weigh different factors differently, and customization should be allowed by the tools that help to evaluate the pros and cons. This is true, in general, for all subsequent factors listed here.
Security and risk posture
When deciding whether to change the application stack of a consumer, it is important for the broker to consider whether the security and risk posture of the new target state could potentially be worse than the current one. The broker needs to communicate the current and target level of security and risk posture to the consumer so that they understand the pros and cons.
For example, perhaps the application to be migrated requires PCI Data Security Standard (PCI DSS) compliance, which may not be available in the target environment. However, the consumer’s application may come up for transformation in a month’s time, after which the application will no longer be constrained to run in a PCI DSS compliant environment. This means that the broker should try to understand the consumer’s and service provider’s roadmaps in order to plan the right time to perform the migration.
The application stack and the delivery model offered by a CSB should also be modeled. I call it the service model, and this is what allows one to query all the capabilities and aspects of a service provider, including whether they conform to a particular security standard or not.
Performance and availability
The target application stack should not adversely affect the performance, latency or availability of the application to be migrated once the new environment is integrated with the rest of the client’s environment. The broker needs to ensure that the CPU speeds, storage input/output operations per second (IOPS) and downtime actually seen on this application stack (based on earlier experiences of the same or other clients) are commensurate with the non-functional requirements of the client as well as the current specs on the existing stack. The service models should support querying of performance and availability to help ascertain if the client’s non-functional requirements can be met.
Stack type and interconnectivity
If the target stack type is the same or similar to the source stack type, then the issue boils down to understanding how and when to migrate an application while minimizing the application downtime. There are several tools and services (such as CloudVelox or AppZero) that claim non-disruptive approaches to performing migration. A cloud broker needs to interface with such migration providers to clearly map the prerequisites for migration to be as non-disruptive as possible and to know which source and target cloud pairs are supported.
If the target stack type is different (for example, from infrastructure as a service (IaaS) to middleware or database as a service (MaaS or DaaS), or from software as a service (SaaS) to IaaS in the first post in this series) then the situation is very different. In the first situation, the application stack becomes “thinner” while in the second case it becomes “thicker.” The migration technology employed (like AppZero) might be able to “strip” the application and data off the current environment and move it to the target MaaS or DaaS environment. If the target environment is a SaaS, then it is important to understand the functional equivalence between the current business application and the SaaS application to ensure that the client’s functional requirements are met.
We believe that functional equivalence between the business applications running on IaaS and MaaS or DaaS models need to be well understood (thus models of the application need to exist!) to aid in identifying which SaaS can replace the existing services. Moving to a SaaS model will entail customization and migration of data, which should be part of the services provided by the broker.
It is tougher if the migration happens to be from an existing SaaS model to a MaaS, DaaS or IaaS model. Either the broker has to know if there is software functionally equivalent to the current SaaS model being used, or the consumer has to provide an application package (replete with the required software) to create an alternate environment on a target MaaS, DaaS or IaaS.
Migration overhead will definitely be reduced if consumers follow standardized application packaging formats such as TOSCA (from OASIS) or HOT (from OpenStack). Using container technology (such as Docker) to run the applications and software should also help simplify migration.
Also, the task of interconnectivity between the target environment and the remaining environment of the consumer has to be established, if it is required. We expect that a broker will host a variety of interconnectivity providers that will be responsible for setting up connectivity between the new location and other locations. These could include provisioning and configuring network service functions such as VPN, WAN, firewalls, load balancers, DNS setup, LDAP and so forth. The cloud broker will identify the appropriate providers and orchestrate these activities.
A decision to migrate to a target application stack hinges on being able to replicate the management stack. The target cloud provider may or may not provide the same quality and functionality of native management as is used in the existing environment. The outsourced and in-house management stack may not interoperate with the new target cloud.
The cloud broker needs to have models of the capabilities (including management capabilities) of the cloud stack provider and any third party service management providers. This should allow determination of interoperability between the various management stack components, and hence compose a management stack with all its components consistent with and covering the requirements of the consumer. Again, a broker should allow comparison of the new management stack with respect to the existing management stack to help make decisions. As the management stack may be sourced from multiple entities it is also expected from the broker to adjudicate and govern the overall end-to-end service level for the consumer.
In my next post I will summarize my thoughts on cloud broker requirements to support service contestability.
What are your thoughts on or experience with cloud brokerage? Leave a comment below to join the conversation.