Gartner’s Sid Nag on Cloud Strategy, Multicloud Costs and Generative AI

Cloud strategy is changing direction: instead of selecting a cloud model and then adapting the business to it, organizations increasingly start with a business outcome and decide which mix of cloud services can deliver it. That shift, described by Gartner vice president analyst Sid Nag, reflects cloud’s evolution from a technology disruptor to a platform for application modernization and new business models.

It also makes cloud decisions more complicated. A workload may run on one provider while using analytics, AI, or other services from another. Some data or applications may stay in a company’s own facilities. Each choice brings tradeoffs in skills, connectivity, data movement, cost, and control.

Nag works in Gartner’s technology and service provider group, where his research covers cloud services and technologies from vendor, provider, and buyer perspectives. His areas of focus include multicloud, hybrid cloud, migration, networking, market trends, product strategy, and hyperscale edge computing. He also contributes to Gartner’s cloud market share and forecast research.

Business goals now shape cloud choices

Nag describes cloud’s development in several stages: first as a mature technology that disrupted existing approaches, then as a way to enable capabilities, and later as a facilitator of innovation. He sees it now disrupting business itself. “It used to be that your cloud models drove business outcomes — now your business outcomes are driving cloud models,” he said.

The practical consequence is that cloud architecture has to follow the work an organization needs to do. A company might choose a service for its application development tools, another for a specialized analytics capability, and a third for an AI model. Cloud is no longer one destination that settles every infrastructure decision; it is a set of options to assemble around specific workloads and outcomes.

Nag said generative AI will add to this shift by enabling applications with richer content and by helping teams build and maintain software. He expects AI services to be spread across cloud infrastructure platforms and software. In his view, that will make cloud more central to how organizations run applications.

The article reports a change in perceptions of cloud’s necessity: it says 50% of people previously thought cloud was necessary, while more than 90% now think cloud applications will be needed. No survey details are provided, so the figures indicate the scale of the reported shift but do not, on their own, explain how respondents were selected or how the question was framed.

That expansion comes with a workforce constraint. Nag identified the pace of technical change and the shortage of employees with the skills to operate cloud environments as major challenges. Some organizations lack the staff and resources to keep up. Moving workloads to cloud services can reduce the need to build and maintain every layer in-house, but teams still need enough expertise to choose services, set controls, and connect systems.

Cloud first means evaluating the option early

Nag defines a cloud-first approach as considering cloud services first when planning IT services or operations, then choosing another approach where it fits better. The point is to make cloud part of the initial decision, rather than treating it as a later migration target or assuming that every workload belongs there.

The financial case often comes down to how infrastructure is paid for and shared. Building and running a company’s own data centers requires dedicated equipment, facilities, power, and space. Cloud providers spread infrastructure across multiple clients, allowing customers to access shared resources rather than own and operate all of the hardware themselves. That changes spending from a capital investment model toward operating costs.

Shared infrastructure can also provide access to development tools, software development kits, programming languages, databases, and platform services that would be difficult for one organization to assemble and maintain alone. For teams modernizing applications, those services can reduce the time and effort required to build a suitable environment. Nag’s argument is that the provider’s scale can make these resources more accessible than recreating them within an organization.

That economic logic doesn’t remove the need to evaluate each workload. Cloud services have different capabilities and prices, and the costs of operating them can rise when teams provision resources without coordination. A cloud-first decision should therefore account for application requirements, staff capacity, service dependencies, and the cost of running the system over time.

Cost control needs governance and workload changes

Cloud spending is rising, according to the forecast figures cited in the interview. Gartner’s Worldwide public cloud services end-user spending forecast, published in December 2023, projected spending of $820 billion in 2025, up from $667 billion in 2024. The interview attributes the growth both to infrastructure use and to organizations using cloud platforms to modernize applications and workloads.

For Nag, controlling that spending starts with rules about who can provision resources. If every end user can create cloud instances without oversight, capacity can accumulate and costs can grow without a clear owner. Organizations need governance and an agreed approach to resource use so teams can access what they need while someone remains accountable for the bill.

Multicloud environments add another layer. Providers package compute, storage, and networking differently, and pricing can vary by provider and region. Nag noted that an equivalent instance can cost less in one region than another, depending on the provider’s regional footprint. A team comparing services needs to look beyond the headline compute price and understand how its full workload will use each provider’s resources.

He also pointed to an abstracted management layer as a way to work across providers with different service combinations. Such a layer can help an organization obtain and manage resources across its cloud environment. It doesn’t erase differences between providers, but it can give teams a more consistent way to coordinate infrastructure choices.

Application modernization is another part of cost management. Nag argues that updating applications can help them run more efficiently, which may reduce the resources they consume. The savings depend on the workload and the quality of the changes, but the broader point is that moving an unchanged application to cloud infrastructure does not automatically deliver the full efficiency benefit.

Hybrid cloud depends on connecting systems

Keeping some workloads on premises can make sense when an organization has particular data residency or security requirements. In some cases, an application can run in the cloud while its data stays within the organization’s own environment. Other systems may remain on premises while cloud applications use or exchange information with them.

Nag cautions against treating the desire to retain control as sufficient reason to keep every system in-house. He said some decisions are driven by concerns about losing control, a limited understanding of cloud’s advantages, or employees’ interest in protecting existing roles. Each workload still needs a reasoned assessment of its technical and operational requirements.

The difficult work in a hybrid cloud setup is often making the parts work together. Applications and data can span environments, so teams need suitable connections and staff who understand how to operate the combined system. Nag said those skills can be difficult to find and expensive to hire.

The interview says 65% of organizations are employing a third party, such as a global systems integrator, to help deploy hybrid environments. That figure suggests outside expertise is a common response to the skills and complexity gap. It also means organizations need to account for external support as part of the operating model, alongside automation and internal capabilities.

Multicloud is driven by specialized services

Nag’s main example of multicloud is a workload that has one main provider but relies on specialized services elsewhere. An application might run primarily on Amazon’s cloud, use Microsoft Power BI for analytics, and draw on Google’s generative AI capabilities. In that scenario, the organization selects each service for a particular capability rather than standardizing every function on one provider.

That flexibility creates technical dependencies. The application and external services have to communicate, which requires a networking and connectivity design. Data may also need to be shared across providers, calling for a federated approach that allows the systems to work with the information they need.

Data egress is a direct cost to watch. Providers may charge when data moves out of their environment, with costs tied to the amount transferred or the network capacity used. A service that looks attractive on its own may become more expensive when the application repeatedly sends large volumes of data between providers. Teams should map those flows when deciding where each component runs.

Multicloud is therefore most useful when the value of a specialized service justifies the added integration and operating work. An organization needs to know which provider is responsible for each part of the workload, how services exchange data, and how charges accumulate across the full path. That design work is part of selecting best-fit capabilities.

Generative AI and edge computing extend cloud reach

Nag sees generative AI as a way to make applications more capable and to support development and maintenance. AI tools may help developers produce software faster and make applications more efficient, while cloud platforms supply the infrastructure and services on which those workloads run. The interview does not quantify those effects, so the practical gains will depend on the task, the tools, and the way teams incorporate them.

Edge computing addresses a different constraint: distance between users and regional cloud data centers. It moves selected cloud capabilities closer to users, which can reduce the need for every request to travel back to a distant region. That matters where network connections are limited or where latency affects how an application performs.

Edge platforms may not offer the same features as a central cloud region, so organizations have to check which functions are available at each location. Nag’s description points to a distributed model: run suitable operations near users, while relying on regional infrastructure for capabilities that edge sites do not provide.

The broader direction is a cloud model shaped around the application’s requirements: central services where shared infrastructure and breadth matter, edge resources where proximity helps, and multiple providers where specialized tools justify the extra connections. Nag’s core advice is implicit in his description of the shift: begin with the business outcome, then account for skills, governance, data movement, and cost before choosing where each part should run.