The number of cloud inquiries from outsourcing clients continues to grow quickly. Many clients want to know how they can cut costs, reduce deployment time or tap into new capabilities that they struggle to implement with their traditional on-premises platforms. As expected, many of these inquiries focus on brand-name public cloud players like Amazon Web Services, Workday and Microsoft Online Services.
When talking with customers, the first question I usually ask is, “What does your deployment model look like today?” I have found that the clients that outsource more services will generally have a tougher time adopting public cloud services than clients that outsource less.
There’s a pretty simple reason why. When clients outsource, they typically source a good amount of the “arms and legs” capability needed to execute technology-related change. This change could be anything from patching an operating system to designing a new security architecture. While shifting capability to a provider works well in outsourcing, it often breaks down in a cloud deployment model.
The public cloud, in general, requires buyers to do more of the work. This is one of the key reasons many public cloud services have such attractive pricing. A significant portion of the labor component of the service – which is typically one of the most expensive parts of any service – is passed to the buyer (note: this pricing discrepancy is more pronounced in infrastructure services than software services).
Take a look at the tables below. The first shows a fairly typical journey for an IT organization that has not yet embraced sourcing. They generally start with everything on premises, then move to a co-location deployment model when they are looking for a more robust data center capability. They then realize they want out of the hardware business altogether and begin migrating services to the cloud:
In this model, responsibility is continually shifting from the client to the provider as more workloads move to the public cloud. Responsibility does not move from the provider back to the client.
Contrast this with a typical sourcing customer that has outsourced both infrastructure and ADM:
The orange boxes highlight the functions that are insourced when moving from an outsourcing model to a public cloud model. The challenge with this is that for many outsourcing customers, the capability to manage an operating system, architect security or configure applications lies with the outsourcing provider, not in-house. Therefore, many outsourcing customers are unable to adopt public cloud to the degree they’d like to, unless they want to make a change to their sourcing model.
Given that many customers have outsourced for cost savings in the first place, bringing on new headcount internally in order to stand up public cloud services is often not a viable financial (or political) option.
An alternative approach is to collaborate with your outsourcing partners to identify workloads that are appropriate for deployment to a public cloud. Many leading service providers are integrating hybrid-cloud orchestration layers into their services, which makes managing workloads, security and interfaces between private and public clouds easier. While this does mean that revenue moves away from the sourcing provider to the cloud provider, many leading providers are (somewhat reluctantly) embracing this reality, understanding that if they don’t work with customers to create hybrid environments today, they’ll not only lose individual workloads, they’ll lose the e ntire business tomorrow.
So, if you’re evaluating public cloud services, remember to look closely at your existing deployment model first. Public cloud shifts a significant amount of responsibility to you, the buyer, but can also provide some amazing benefits for the right workloads.
3
No comments yet.