No, we’re not talking about the series of Keanu Reeves movies. That’s far beyond our scope. We’re talking about cloud models and delivery channels.
It’s a useful exercise to map models against channels to look at how their advantages (and disadvantages) complement each other for your purposes. So let’s start with a few working definitions.
Most of the discussion of the relative merits of different cloud options revolves around which model of cloud is best for a given situation.
*Public cloud: This is what most consumers are talking about when they discuss the cloud—the cloud of Google Apps and OneDrive. On an enterprise scale, though, it takes on a different shade of meaning. In a public cloud, your applications and data exist on infrastructure that is shared with other users. These clouds are very scalable because workloads can be moved among thousands of physical machines in a data centre, and the pay-for-use pricing can be attractively low, while shifting CAPEX to OPEX. On the downside, though, are security risks, data sovereignty issues—is my data actually in the country? If not, is that a regulatory problem?—and the fact that, at peak usage times, you may be competing for resources with other customers.
* Private cloud: Your applications and data don’t share a physical machine with other customers. There obvious control and data sovereignty advantages, but depending on the delivery channel (as we’ll see below), it can be expensive.
* Hybrid cloud: Some workload is executed in a private cloud (or enterprise data centre) and integrated with workloads running in a public cloud. By distributing applications and data, you can play to the strengths of each model—the data sovereignty advantages of a private cloud with the scalability of a public cloud.
The cloud discussion usually begins with the public-versus-private dilemma. But there’s still the delivery channel to be considered. Like the models above, each channel has advantages and disadvantages. But there are grey areas between them.
*Cloud vendors: Consider these offerings more or less synonymous with the public cloud. They offer ease-of-use and low price, but aside from the disadvantages mentioned above, they often run on proprietary platforms that make it difficult to repatriate or migrate workloads.
*Vendor clouds: This category includes cloud offerings from the major hardware and software players. These vary widely in capabilities, complexity and cost, so it’s hard to make a blanket statement about pros and cons.
* Service providers: Managed services providers are partners of the vendors above, sometimes more than one of them. There’s also a good chance they’re a partner of yours as well, so you can leverage the existing relationship. Customization and negotiability—especially with respect to service level agreements—are key advantages.
* On-premise: Just as the name implies, the hardware is in your shop. You build it—or have someone build it for you—you run it, you maintain it. There’s absolute control, over both the workloads and the architecture, but staffing and maintaining it can be expensive and mitigate some of the advantages of the cloud in general. There is, of course, the option of having an MSP run and maintain your on-prem cloud. This has an added advantage in a hybrid environment, since the same MSP can run private and public clouds.
MAPPING THE MATRIX
Now arrange models and channels in a matrix, with models on the vertical axis and channels on the horizontal.
|Cloud vendor||Vendor cloud||Service provider||On-premise|
(Cloud vendor offerings can’t be private, and an on-premise cloud naturally isn’t public.)
In each box of the matrix, you can meld the advantages and disadvantages of the model and the channel into a single value statement: For example, a private service provider cloud offers customization, negotiable SLAs, and possibly a pre-existing relationship, with security and data sovereignty advantages, on dedicated hardware. See if you can find the best value statement to suit your applications. In the case of a hybrid cloud, you might find more than one value statement is useful, depending on the number and nature of applications.