For years, cloud service providers (CSPs) have invested billions of research and development dollars to develop a formidable set of core cloud services. Although the services vary by CSP, the investment in R&D has produced secure, robust, and reliable platforms that run the gamut from data and analytics to IoT and security. Users of CSPs benefit from these investments by developing software on top of these services.
Organizations that minimize the time it takes for an idea to become a production capability (“time to live”) realize the greatest cloud potential. A key factor in minimizing time to live is using native CSP-specific services. This rich ecosystem of services can help companies scale applications, manage data, and implement complex analytics at lower cost and higher speed.
Many companies, however, are not taking advantage of the full range of these CSP-specific services to capture significantly more value from cloud. There are many reasons for this, from a lack of talent that knows how best to use these services to legacy operating models that impede businesses from using them. One reason that looms large for many businesses is fear of being locked into a specific CSP. As a hedge against this issue, many companies have turned to containerization, in the belief that it allows applications to be more easily moved from one CSP to another (see sidebar “A note on containerization”).
Containers are an important utensil in the cloud tool kit. But, like too much of any good thing, overreliance on them has significant downsides, not least of which is that companies miss out on many of the benefits offered by CSP-specific services. Furthermore, containers have their own hidden costs and complexities that companies often fail to appreciate. In our experience, the benefits offered by CSP-specific services far outweigh the value of a major containerization strategy.
Would you like to learn more about Cloud by McKinsey?
CSP-specific services: Understand the value
When they are effectively configured, CSP-specific services give companies immediate leverage to scale and accelerate their applications. And because CSPs’ business model depends on how much value they can generate for customers on the cloud, they dedicate resources and capabilities to their services that few other companies can—or would want to—match.
For example, when it comes to compute capabilities, using services such as AWS Lambda, Azure Functions, and Google Cloud Functions to provide infrastructure abstraction allows application teams to focus their energies on core business logic. Options for database services include Google Spanner, Azure Cosmos DB, and AWS DynamoDB, while Azure Power Apps, Google Cloud Workflows, and AWS Step Functions all provide workflow capabilities.1 Creating cloud-agnostic solutions in containers precludes the use of these types of services.
CSPs are also able to “preintegrate” multiple services for interoperability, data, and security in standardized, auditable ways. That’s because they use highly standardized infrastructure architectures for the hundreds of resilient, massively dense services they offer: API proxies, message queuing, load balancing, eventing, logging, databases, and so on.
The following are additional benefits of CSP-specific services:
- Performance transparency. All major cloud platforms contain integrated instrumentation that allows operational teams and developers to isolate code that performs poorly or is expensive to run. This transparency and reporting capability reduces the (often dreaded) code-tuning cycle for developers. Although standards are emerging in Kubernetes and other container systems, adopting and enforcing a consistent approach to performance remains challenging in a container environment.
- Lower costs. Because CSP-specific services are built for thousands of customers, the cost to develop and maintain them are spread across the subscriber base. This results in robust services that are far less expensive—and often far better—than operating your own services with your own purpose-built containers. Taking advantage of these lower costs requires effective FinOps capabilities.
- Developer productivity. Successful companies buy commodities and build differentiation. In the cloud, commodities such as message queues and load balancers are typically provided as part of a CSP package. This reality frees developers to focus on applications, which improves productivity and expands the pool of available talent.
Containerization: Understand the trade-offs
We often hear executives lauding containerization as the silver bullet enabling businesses to migrate to cloud without fear of vendor lock-in. Containers do have some compelling advantages:
- Portability between operating systems. With containers, code can be moved relatively quickly and easily from one CSP to another with only limited changes to code and configurations and no loss of functionality.
- Control over dependencies. Developers have complete control over the dependencies and libraries they use in their code, enabling them to take advantage of specific APIs and functionality. There is no risk that CSP changes or upgrades will require code to be refactored.
- Consistency for developers. Developers can use containers to replicate actual production environments on their local machines and be confident that the code will run in exactly the same way when deployed.
- Greater scalability. By using the host operating system’s overhead procedures and computational cycles, containers can provide more scalability than other deployment methods.
However, in our work helping leading organizations migrate to the cloud, we’ve found that using containers as the only option can pose significant problems. As one technology leader at a Fortune 500 financial institution recently told us, “We’ve made no real progress with our technology strategy in three years, because we’ve been working on being cloud agnostic.” Following are some of the most common and costly issues triggered by using containers exclusively.
Delays and diverted resources
Moving all code into your own containers and then shifting them to the cloud is time-consuming to execute and maintain, and it creates its own complexities. Some companies, for example, will turn to Kubernetes as a container solution. However, there are different kinds of Kubernetes—such as Cloud Native Computing Foundation (CNCF) Kubernetes, proprietary multicloud Kubernetes, CSP-specific Kubernetes, and managed Kubernetes—each of which has a different impact on the cloud experience that must be managed.
Managing containers also diverts resources into container-related activities that don’t add business value. Software developers using containers, for example, need to build and maintain an exponential mesh of integrations between a range of applications, a hugely complex task that provides no material business benefits and that CSPs readily provide. When your team spends time applying security patches to containers rather than building new data-driven business-intelligence dashboards, for example, the net effect can be weeks of lost opportunity every year. One financial services company that took this approach found that its cloud migration took five times longer than planned.
As a rule of thumb, if developers spend more than, say, 10 to 20 percent of their coding time on container configuration, failover, security, or other infrastructure issues, it makes more sense to tackle these issues via CSP services instead, so that valuable time and skills can be reserved for functionality that serves the business.
Costs of ownership
Containers give you control over your applications at a detailed level, but integrating multiple containers throughout an enterprise is a major endeavor. For one, containers incur their own development, operations, and maintenance costs, which can sometimes be significant. Building and operating complex capabilities such as cross-region availability, backup, and retention can carry high hidden costs, with companies running containers sometimes paying twice as much as they would for equivalent services provided as part of a CSP package.
Most of the known costs of containers are for compute and memory resources, storage, networking, or data transfer. In our experience, replicating the infrastructure needed to support commodity applications (for example, messaging and load balancing) in a container can add 40 to 100 percent to application costs on top of the actual infrastructure run costs.
One large manufacturer chose to implement a load balancer as a container in a Kubernetes cluster. But without the economies of scale for handling concurrent connections that a CSP could have provided, it found it was paying ten times as much in compute and network costs. Similarly, a healthcare payer that adopted a container-based approach had to hire twice as many people as expected to manage it, on top of the extra compute, storage, and network costs.
Security difficulties
Containers can be less secure than virtual machines. The guidance from the Federal Information Security Modernization Act (FISMA), for instance, is to use virtual machines (VMs) in preference to containers.2 Since containers provide an abstraction layer over the operating system, standardized infrastructure capabilities must be brought into container environments, making dependency management difficult to support. By contrast, CSP-specific solutions often have robust security options built in.
Container-vendor lock-in
Several vendors offer portable containers, but choosing their software inevitably introduces an element of lock-in. The provider of one of the most popular technologies used in building containers recently changed its licensing terms to require large organizations to buy individual subscriptions for all staff using certain products.3 For those enterprises, this seemingly small change could mean tens or hundreds of thousands of dollars of additional expenses.
Cloud foundations: Ten commandments for faster—and more profitable—cloud migrations
Building for cloud portability
Committing to the services provided by a CSP needn’t mean sacrificing flexibility. The smart solution is to choose the CSP-specific services that best meet your needs while remaining “cloud portable”—that is, retaining the ability to move your systems and workloads to another provider if circumstances change. Being “cloud portable” means maintaining a continuous view of which CSP-specific services you are using and what it would cost to switch vendors if you had to. With this in mind, companies can take a variety of approaches to portability:
- Using containers for third-party applications. Creating container clusters to host commercial off-the-shelf (COTS) or third-party applications can be an effective way to use containers in a cloud infrastructure. Many vendors already bundle their software in containers and design their application platforms to allow different subcomponents to scale horizontally within a container cluster. Since these vendors can’t predict which CSPs their customers will use, they take on the burden of providing all the necessary capabilities, engineering, and operational capacity, and factor it into their licensing models.
Building a multicloud, three-tier, serverless app with Terraform
One popular application pattern for using CSP-specific services is a multicloud, three-tier, serverless architecture (exhibit). This consists of an API entry point, serverless functions for business logic, and a combination of object storage for files and a relational database for application information. With this approach, the application can be deployed to AWS, Azure, or Google Cloud simply by supplying Terraform with a single variable specifying the desired CSP. This is sometimes referred to as “polymorphic” infrastructure as code.
- Using infrastructure as code (IaC) to access services from any CSP. Companies can use IaC to automate the selection of useful services at deployment time based on simple variables in the infrastructure code. This allows for a hybrid strategy that combines the advantages of multicloud with the power of CSP-specific services (see sidebar “Building a multicloud, three-tier, serverless app with Terraform”).
- Using a highly standardized abstraction layer. Most CSPs have proprietary IaC tools specific to their cloud environment. Using a standardized IaC abstraction layer such as Terraform to codify infrastructure deployments makes it easier to manage any changes that CSPs make in their services or to switch from one CSP variant of an infrastructure service to a different one without heavy modification.
- Splitting operations between clouds. Segmenting workloads and placing them on different clouds sends a clear message that you have relationships with multiple CSPs. Workloads can be segmented by business unit, functional domain, country, or technology layer, with developers aligned to each workload/cloud combination. The principle of using the CSP-specific services that best support your needs still holds, of course. Supporting multiple clouds may require a larger developer workforce, but analysis will reveal whether the additional talent cost is outweighed by the developer time saved.
It’s worth noting that CSPs are aware of customer concerns about vendor lock-in and have invested in services that make it easier for clients to export their code, logic, and data to other services in a structured way. With cloud portability a selling point to attract new customers and additional workloads, CSPs can be expected to continue innovating in this area.
Strategic flexibility on cloud is undoubtedly worth pursuing, but using containers indiscriminately is not the way to achieve it. Rather, the answer lies in a thoughtful selection of the CSP-specific services that best suit a company’s context and needs, informed by a clear view of the costs and trade-offs involved. With the right approach, businesses can mitigate lock-in concerns while still taking advantage of CSP-specific benefits that can deliver enormous value.
