I’ve been having some great discussions with customers recently that led to this interesting title. Too many customers are looking for “THE Cloud” (as in the one and only technical solution) and want to know how to compare one cloud against another. Because they are looking for a technical solution and not a business solution, many are looking for something that is just out of reach.
Why is “THE Cloud” so elusive? One simple word: workload. Let’s take a few examples. The first two examples come straight from my previous post about DevOps and software generations. The third example comes from a discussion of public vs. private I had with a customer today.
The first example I’ll present is your traditional “enterprise legacy” workload. When you think virtualization, you probably are thinking of this workload architecture. Take some servers, networking, storage and virtualization from your favorite vendors and run the “old stuff” on it. This could be Exchange, SAP, Oracle, etc. This production workload tends to be critical to your business, not public facing, and runs in a more or less steady state. The workload is pretty constant and even if it isn’t, tends to be predictable. Because of this, you may not have a need to “go faster”, you just need it to work. Reliability at the infrastructure layer is more important than agility & scalability. This workload may not need to be “moved to the cloud” but it can benefit from management in a cloud-like way if architected properly. This is the old reliable. As Rodney put it once upon a time, it may not be sexy but it drives most business today.
The second example is Netflix. Just kidding. What I mean by this example is a workload that follows the Netflix model but it can be either private or public. This is a production workload that tends be very elastic, follows a DevOps process, and the underlying architecture is VERY different (object storage, software defined networking, commodity servers, etc.). Because Agility & scalability at the infrastructure layer is more important than Reliability, the management style also tends to be very different from the previous example. This is a persistent application built for one purpose (typically to generate revenue in some way) that is always changing to go faster. This is the thoroughbred racehorse.
The third common example I see is a test & development environment in a public cloud. This is a non-persistent application that only needs to serve a purpose for a limited time but will be destroyed or recycled after use. This environment is non-production, and benefits from fast provisioning and decommissioning over reliability. The application doesn’t need agility or scalability as much as it needs to be set up and torn down quickly. I know I mentioned a great use case on the Cloudcast (.net) podcast back in November after the Amazon AWS conference. I spoke to a user that would spin up hundreds to thousands of AWS instances for scale testing and then would destroy them when complete. This type of environment was too large to purchase and host on premise and was only used a few times a year. By moving the test and development to the cloud, the company was able to achieve something that was impossible before. This is The Flash.
As you can see, different workloads have different characteristics, different operations and management needs, and different infrastructures to support them. What if you combined some or all of the examples? This is how the Hybrid Cloud model became popular. A hybrid cloud is two or more unique clouds stood up under the same management point.
When evaluating cloud solutions, always start with your workload, determine the requirments to support your operations and business process, THEN evaluate products against your unique needs. Your goal here is cover as much “solutions area” as possible with the least amount of products to keep the operations as simple as possible.
