The Cloud is often as new to the Cloud Service Providers (CSPs) as much as it is new to organizations thinking of moving to the Cloud. Many of these CSPs are managed service providers making the obvious shift to the Cloud. After all, they have the infrastructure, the knowledgeable people, the right process and procedures already in place. It should be simple for them to provide a Cloud offering, especially a Private Cloud. Other CSP wannabes are brand new companies, often licensing tools from one set of partners and infrastructure from anther set. They usually have some magic piece either in terms of market specialization or a nifty management tool. Other CSPs are legacy companies taking this as the next logical step to support and expand their IT dollar share in their existing huge customer base. The potential market for the Cloud is bringing out all kinds of contenders. Every week new Cloud companies form, “old” ones are bought, merge, or just disappear. Today, there are hundreds of CSPs in the US alone. In a couple of years, I predict there will only be a few dozen.
In the software development world, the standard story is that you get software developed quickly, cheaply, or with high quality. You can get any two attributes. You can’t get all three.
In the Cloud, it is not that simple. There are more like six attributes:
- Price (What does it cost?)
- Availability (How much can you count on it being there for you?)
- Performance (How quickly can you get your transactions processed?)
- Agility (How quickly will it expand or contract to meet your immediate needs?)
- Control (How much control to you have over what is happening to your data and software?)
- Security (Can you sleep at night? This includes data security as well as the survivability of the CSP itself.)
In the general case, there really is not much relationship among these attributes. The Cloud is not a product; it is a concept. The Cloud is implemented in almost as many different ways as there are Cloud Service Providers. You must understand the requirements of a particular workload first. Then you can determine the appropriate set of CSPs. Only then can you determine how these six attributes are related for that workload.
I have talked about moving a workload to the Cloud as a ten-step process:
- Understand your business needs.
- Select the workload.
- Determine the real requirements in the areas of availability, performance, agility, control and security.
- Determine what kind of a Cloud Solution you need (Infrastructure as a Service, Platform as a Service, or Software as a Service; and whether it should be a Public, Private, Community or Hybrid Cloud)
- Select the candidate CSPs.
- Submit the requirements and evaluate the responses.
- Negotiate the contract.
- Plan the migration, both into the Cloud and back out again when that becomes necessary.
- Migrate the workload to the Cloud, test, and go live.
- Measure and review.
It is critical that you know what your organization is trying to accomplish in moving to the Cloud. It usually involves lowering costs, increasing agility, or decreasing the aggravation of running an IT infrastructure. The order of these is important, as it should influence decisions as your move through the process. Sometimes there are other, more hidden, objectives. I worked on one project where the real objective was that the IT director for the subsidiary of a major international company wanted to be the first one to successfully take a workload to the Cloud. He hoped to use that prestige to move up into the parent company. That added a fourth, and most important, criterion: time to implementation. There may be other compelling events that put a time constraint on the migration: hardware replacement plan, software license renewal, new product introduction, merger or acquisition. If you do not implement a solution that meets the most important of these goals you will fail, even if the resulting solution works as needed.
Over a year ago I talked about selecting the first application to move to the Cloud. After the first one, you will have a better feel for what should be next within your own organization.
Often the hardest part of moving to the Cloud is determining what your requirements really are in the Cloud. Different workloads will have different requirements. The key areas are usually:
I plan to have a blog on each generating the requirements on each of these in the near future, but there are a couple of important points to consider in general.
Most CSPs have published Service Level Agreements (SLAs) on availability and performance. However, they are almost always not talking in the same terms that you are thinking. In most cases, these differences of viewpoint make it difficult to compare the seemingly same SLA across multiple CSPs. As one person muttered, they are apples and watermelons. As you create your own requirements, document exactly how you are measuring them. For example, you may measure response time as the time between when one of your customers enters a request and the customer receives an acknowledgement that the request has been processed. Your CSP will measure response time as the time between the request reaching the edge of the CSP’s facility and the response leaving the CSP’s facility. At a minimum, that leaves the Internet transit time in both directions out of the measurement. Depending on the location of the CSP’s datacenter and its band-pass capacity, there could be a significant difference between the two measurements.
The last word:
Moving to the Cloud is sometimes a matter of compromise. I’ll trade, for example, a loss of control for a substantial cost decrease, or I’ll trade paying a little more for increased agility along with disaster recovery capabilities. The critical part is to keep track of the priorities, and make sure that what you end up with is “good enough” in all the important areas.
This is much like politics. You may have issues with each candidate, but you will never find a candidate that you agree with on every point (unless you are running). I find it helps to make a list of my really important issues, prioritize them, and then rate each candidate on those issues. See which one comes out with the best “score,” then see if you can live with pushing that lever. But if you don’t vote, you can’t complain.
Keep your sense of humor.