- Companies often can use help in what to look for in a cloud service provider.
- These are our top three items.
Before moving into cloud service provider selection, it is important to establish some of the following selection principles.
Our References for This Article
If you want to see our references for this article and other related Brightwork articles, see this link.
Lack of Financial Bias Notice: The vast majority of content available on the Internet about Oracle is marketing fiddle-faddle published by Oracle, Oracle partners, or media entities paid by Oracle to run their marketing on the media website. Each one of these entities tries to hide its financial bias from readers. The article below is very different.
- First, it is published by a research entity.
- Second, no one paid for this article to be written, and it is not pretending to inform you while being rigged to sell you software or consulting services. Unlike nearly every other article you will find from Google on this topic, it has had no input from any company's marketing or sales department.
How Companies Tend to Approach Cloud Migration
Customers often approach cloud migration with an inappropriate framework, which is right from the beginning of the evaluation process. Normally, they compare cloud service providers to each other (AWS versus Azure versus GCP).
This is a natural approach, but it is not an approach that will lead to the best outcome.
How We Recommend Setting the Framework for Selection
- In our view, the best framework is to compare each service provider to their own IT.
- Essentially, cloud adoption means that customers outsource IT service management. This is a viable option only if the service provider is more efficient than the customer’s own IT. If not, customers end up with less agility, less availability, and higher TCO.
Let us move to the three primary selection criteria.
If a company moves to the cloud, they expect their business agility to increase and certainly not to decrease. We know a few customers who recently migrated to a cloud services provider in the US. Their support tickets are now measured in days instead of the hours it previously took their own internal IT staff after moving their applications.
Because problem tickets and change requests are handled internally on the provider side by multiple teams (product support and hosting operations), the operations teams have no product expertise and vice versa. Moreover, each team has its own set of SLAs. Each customer request triggers multiple internal change requests involving multiple teams operating in different locations and time zones.
Consider release management. When the service provider applies a patch or upgrade, it gets applied by the operations group to all customers on the same application version. This causes days of downtime.
Because each customer has a specific configuration and extension environment, these changes are not tracked by the hosting service provider.
- In the past, application owners and administrators had to coordinate change management with their own IT, who tracked all changes into their ITSM databases.
- When customer IT released a patch or upgrade, they knew exactly each specific application environment’s status, and they incorporated the latest changes into their release packages.
Another scenario is increased downtime compared to the customer’s own IT service level agreement (SLA).
Because some cloud service providers have a dependency on their colocation facility provider, this means that customers have to deal with multiple sources of planned and unplanned downtime. We covered this in detail in the article The Problem with the Oracle Cloud and Colocation.
Moreover, customers have to deal with multiple SLAs instead of one SLA with their own internal IT.
Companies love using the term “one throat to choke.” However, whose throat do you choke for a 24-hour production outage?
Customers often compare the TCO of different cloud providers to each other.
As we stated earlier, this is not the most helpful framework.
- Because customers want lower TCO than their own in-house IT.
- If a customer’s IT has a lower TCO than a specific provider, they end up spending more, not less.
- A cloud service provider can deliver lower TCO than a customer’s in-house IT in specific scenarios. Customers should verify these scenarios as they plan their cloud migration journey.
Let’s look at some examples.
Example 1: Self-service (Automation) Versus Manual Service Provisioning
Service providers vary vastly in their service delivery capabilities. On one end, customers need to open a ticket to provision an instance or increase the attached storage volume capacity. In this case, the work is performed manually by teams that support hundreds or thousands of customers across dozens of time zones, and the cost of labor increases with every new customer onboarded.
Example 2: The Cost of Labor Has to be Transferred to Customers.
On the other end, there are providers with mature self-service and automation capabilities. This means that less manual labor is needed for most customer requests. For example, with AWS CloudFormation, a customer can create an entire data center (or VPC) using a single script file including all the resources needed across all regions and accounts. Labour-intensive service providers have higher TCO due to the increased cost of labor. Moreover, labour-intensive service providers have lower agility due to manual work and rework introduced by human errors.
Example 3: Right-Sizing Infrastructure Versus Rehosting (Lift and Shift)
Customers often assume, incorrectly, that the cost of cloud infrastructure must be lower than their in-house IT. In some cases, cloud infrastructure TCO can be much higher than on-premises for the same workload. The first factor is scale. If the service provider operates at scale, they can command the highest volume discounts from manufacturers, and they can pass part of these cost savings on to customers. Niche providers lack the economies of scale and the associated cost savings.
The second factor is infrastructure technology. Some service providers operate a single-tenant dedicated infrastructure where customers have to commit to a multi-year contract. In this case, customers end up with the same over-provisioned infrastructure footprint they had on their own premises, and their TCO will surely increase, not decrease, at least by the cost of the migration.
The hardware refresh cycle for most companies is 3-5 years. When they procure infrastructure, they have to plan for maximum capacity projected over 5 years of user and data growth. Invariably, they end up with over-provisioned in-house infrastructure with all the associated capital and operational expenses. This, of course, is one of the major benefits of cloud service providers.
Cloud service providers capable of rightsizing customer workloads elastically can provide significant TCO gains anywhere between 30% to 60%.
This issue with over-provisioning was covered in our book How to Understand On-Premises Proprietary Servers and Server Vendors, hardware vendors make their money selling servers, and they have overstuffed customers with servers. They have done little to enable their customers to improve the efficiency of their previous purchases? There is a little incentive as it would simply reduce the number of servers they could sell.
Agility, availability, and TCO are the three most important criteria to apply when selecting cloud service providers. Our approach pushes against the comparison between service providers in the initial phase of selection. Instead, customers should benchmark cloud services against their own IT. If multiple providers are found to offer higher agility, availability, and lower TCO than the customer’s own IT, then we can move to compare service providers against one another.