Cloud Hosting

When it comes tomanaging a multi-cloud world, matching your workloads to the best cloud hosting platforms is one of thebiggest challenges. Rational decision making often gives way to an emotional exercise, where beliefs, biases, and other human behaviors set the stage for a less-than-optimal hosting strategy.

If you use themodel described below, as our team did, you'll increase your chances of establishing a fact-based, data-driven hosting strategy that's easier to define and execute, while avoiding any perceptions of bias in your recommendation.

[ Enterprise Service Managementbrings innovation to the enterprise. Learn more in TechBeacon's new ESM guide. Plus: Get the 2019 Forrester Wave for ESM. ]

As Cloud CTO at Micro Focus, I was asked to helpbuild a model that we could apply with as little prejudice as possible. So our teamestablished a set of core principles that enabled us to build a balanced model that we can consistently use to evaluate the placement of specific workloads as well as for our overall hosting strategy.

It could work for you, too. The core principles are:

While your hosting decision model should support placement decisions for multiple workload types, there is almost no end to the number of workload types you could define. That's why you need to introduce a usability challenge into the model.

In this, less is more. We narrowedour list to three core workload types: development and rapid prototyping, traditional production, and cloud-native production.

Development and rapid prototyping workloads include everything development and testing teams might require from a hosting provider to develop and test their code.

Traditional production workloads are those that rely on the base infrastructure-as-a-service (IaaS) set of resources and have no cloud software-as-a-service (SaaS) requirements. You can deploy them in almost any public or private cloud environment.

Cloud-native production includes cutting-edge, cloud-reliant workloads that make moderateto heavy use of cloud concepts and/or rely on cloud platform-as-a-service (PaaS) offerings.

[ Learn how to transform your IT with AIOps in TechBeacon's guide. Plus: Download the analyst paper on how AI is changing the role of IT. ]

While building our model, we analyzed many KPIs from our body of research, picked up a set of KPIs that formed the model core, and then categorized those into five dimensions.

Building a model with dimensions helps us to have logical KPI groupings and to establish a scoring system per dimension. In this way, we can easily evaluate a hostingenvironment based on how well it scores in each dimension, instead of comparing each and every KPI across hosting options.

Figure 1: The five dimensions of a hosting assessment model. (GTM is "go-to market" strategy.)Source: Micro Focus

Heres a high-level view of the models five dimensions, along with a few KPIsfor each.

Thisdimension establishes the hosting environment's security and complianceposture, allowing you to weigh how secure and compliant each one is.

These KPIs evaluate employee background checks, physical access, access logs, and how cryptographic keys are being managed. The KPIs should evaluate support for ISO27001 or GDPR to assess complianceposture.

Comparing hosting providers on cost can be a futile exercise if you're focused on migrating a large data center, which is too big and has many variables, or if you're comparing compute or storage units, which is too granular.

The hosting decision model introducesthe concept of application comparison. For every workload type you pick, you need a poster-child application that you can model in each environment you're evaluating. Calculate the infrastructure cost for hosting that application from the bottom up, and then compare between providers.

Account for your labor costs for each application, since that can be different for each environment. For example, a private cloud has infrastructure support requirements that don't exist with public cloud. A best practice is to use labor per compute unit (virtual server), then multiply by number of servers within the application model.

Finally, if you wish to gaininsight intohow each environmentmight affect your organization's earnings, your cost model should have an earnings before interest, taxes, and amortization (EBITDA) impact, expressed as a percentage.

Here you evaluate the potential support each environment provider offers. This may highlight whether the environment provider will be able to deliver the level of support you need to properly rely on the provider for hosting services, as per your expected service-level agreement (SLA).

Some of your KPIs should measure the provided support level and the number of dedicated technical resources the hosting service provider will assign to you.

Since some workloads will be hosted with an environment provider to drive business, you should establish what potential business leverage a provider could deliver. This could be a critical insight that guides your hosting decision.

KPIs might includeanestablished joint go-to-market strategy, the amount of market development funds the hosting entity will provide, and how many joint and aligned global system integrators or regional system integrators are available.

Assessing environment resilience and performance is a key factor in meeting internal and customer SLAs, so properly evaluatingthese criteriais critically important.

To obtain such metrics you might need to rely on your previous experience to calculate anaverage number of incidents, mean-time-to-repair, or theperformance and availability of sample applications. However, you could also obtain publicly accessible information abouthosting providers to calculate the KPIs.

Some KPIssuch as whether the hosting entity supports demand elasticity, zero-downtime upgrades, and support for multi-zone availabilitymay be readily available from the provider's marketing literature.

Now that you have identified your model's dimensions and supported workload types, you can determine which workload types best align with your various dimensions.

For example, development and rapid prototyping might lean more toward hosting environments that optimize for cost, while traditional production might be better suited to environments that optimize for quality of service and security.

You can introduce this bias into your model with a weighting scheme where positivelybiased dimensions receivea higher weighted score than do other dimensions for a given workload type. See the images below for specific examples.

Once you have defined your model, it's time to populate its dimensions and KPIs with data for the cloud hosting platforms of choice. For this exercise, you need to gather data from yourexperience in hosting workloads,industry benchmarks, and any self-assessments made public by the hosting environment providers.

For balanced KPI results, you need between four and six months of data to counter any seasonality and other biaseswithin the datasets. Remove outliersby using the median instead of the average.

Once you have calculated the KPIs, assign a score between 0 and 10 to each dimension. Since each KPI is likely to have a different impact on the overall dimension score, apply your weighting logic as you calculate the dimension score.

The outcome of this phase is your cloud assessment model for each cloud-hosting option. Each should have a score for every dimension, as well as detailed KPI scores within those dimensions.

This gives you a standard lens through which to differentiate your cloud hosting options.

Using the weighting schemeyou created for each workload,evaluate each cloud hosting provider for each workload type. Do this by using the cloud hosting dimension score with the workload weight for each dimension, normalized between zero and 10.

You've now created an overall score for each combination of workload type and cloud-hosting platform. The higher the score for a specific workload type, the more aligned that cloud hosting platform is for that workload.

By establishing this baseline, you'llprovidea hosting decision recommendation that matches workload types with the right cloud hosting platform.

There are cases, however, that might impose additional requirements that cut across your recommendation results. For example, if a government or geographical presence is required, then your recommended cloud hosting platform must support that.

The lesson here: Build your overall cloud hosting strategy on your model's output while allowing for a certain percentage of cases that will go out of bounds.

Matching your workloads to the right cloud hosting platforms need not become an emotional exercise. Follow the steps above and you'll have a much more rational, data-driven basis for making those decisions while avoiding any perceptionof bias.

[ Learn how robotic process automation (RPA) can pay offif you first tackle underlying problems. See TechBeacon's guide. Plus: Get the white paper on enterprise requirements. ]

More:
How to match your IT workloads to the right cloud - TechBeacon