For years, enterprise infrastructure strategy was often framed as a relatively simple choice: keep workloads on-premises or move them to the cloud.
That conversation has changed.
AI, increasingly specialized compute requirements, growing data volumes, application modernization and evolving approaches to infrastructure management have created far more options for where and how enterprise workloads can run.
That doesn’t mean CIOs need to become infrastructure engineers. It does mean that workload placement deserves a more nuanced conversation.
The objective shouldn’t be to identify one infrastructure model that works for everything. It should be to understand what a particular workload requires—and then determine which environment can best meet those requirements across performance, security, reliability, operational complexity and cost.
This workload-driven approach is increasingly reflected in industry practice. The FinOps Foundation’s Architecting & Workload Placement framework calls for evaluating workload placement across technology environments based on business value as well as performance, scalability, security, reliability, regulatory and operational requirements.¹
Here are eight questions worth bringing into the conversation.
1. What does this workload actually require?
Before discussing where a workload should run, start with what it needs to accomplish.
That includes obvious considerations such as compute, memory and storage, but the discussion should go further:
- How sensitive is the application to latency?
- How much network bandwidth does it require?
- Does demand remain relatively consistent or fluctuate significantly?
- What are its availability and recovery requirements?
- Are there geographic or data-location considerations?
- What dependencies exist between this workload and other applications or systems?
- How quickly will its requirements change?
The goal is to establish the workload’s requirements and constraints before evaluating where it should run. That includes not only resource requirements, but factors such as security, reliability, regulatory requirements, performance, scalability, operational considerations and cost.¹
This is why infrastructure decisions should begin with the workload—not the platform.
2. Does the workload require specialized compute?
The rapid growth of AI has made GPU infrastructure a much larger part of the enterprise technology conversation. But GPU and CPU infrastructure solve different types of problems.
GPUs are designed to perform many calculations in parallel, making them particularly effective for compute-intensive workloads such as machine learning.² CPUs remain well suited to a broad range of general-purpose enterprise computing tasks.
That distinction matters because the question isn’t simply whether an organization has an AI initiative.
It is which workloads actually benefit from specialized compute.
AI training, AI inference, analytics, rendering, high-performance computing and conventional enterprise applications can have very different infrastructure requirements. Treating all of them as variations of the same compute problem can lead to unnecessary cost, inadequate performance or both.
For CIOs, the strategic question is therefore not, “Do we need GPUs?”
It is, “Which workloads require them, at what scale, and for how long?”
3. Are we paying for flexibility the workload doesn’t need?
Flexibility has tremendous value. But not every workload needs the same degree of it.
An application with unpredictable demand may benefit substantially from an infrastructure model that can rapidly scale resources up and down. A stable production workload with relatively predictable consumption may present a very different economic equation.
The same principle applies to performance, availability and resiliency. Each can justify additional infrastructure investment when the workload and business requirements demand it. The objective is to understand those requirements and compare the value and tradeoffs of the available placement options.¹
The better question is not simply:
“What does this infrastructure cost?”
It is:
“What capabilities are we paying for, and how much value does this particular workload receive from them?”
That distinction becomes increasingly important as infrastructure environments become more diverse.
4. What are the real performance requirements?
Infrastructure specifications are useful. Application performance is what ultimately matters.
Storage is a good example. Capacity alone doesn’t tell you whether a storage architecture is appropriate. Throughput, latency and the workload’s read/write patterns may be equally important.
The same is true of networking and compute.
A workload that performs adequately under normal conditions may behave very differently during peak demand. Applications sharing infrastructure may also compete for available resources, creating performance issues that aren’t obvious from an architecture diagram.
This makes baselining important.
Before changing platforms, organizations should understand how the existing workload behaves today: what resources it consumes, when it reaches peak demand, where bottlenecks occur and what level of performance the business actually requires.
Otherwise, an organization risks comparing infrastructure without first establishing what “good” needs to look like.
5. How much isolation does the workload require?
Not every workload has the same tolerance for shared infrastructure.
For some applications, multi-tenant infrastructure provides an entirely appropriate combination of scalability, efficiency and economics. Other workloads may benefit from greater resource isolation because of performance sensitivity, security requirements, application architecture or organizational policies.
This shouldn’t become an ideological debate between shared and dedicated infrastructure.
Instead, determine the appropriate level of isolation based on the workload.
Ask:
- Can competing workloads materially affect performance?
- Are predictable resources important?
- Does the application have particular security or compliance requirements?
- Does the organization need greater control over the underlying environment?
The answers may be different from one workload to the next—which is precisely the point.
6. How portable is the environment?
Workload placement isn’t only about where an application runs today. CIOs should also consider how difficult it would be to change that decision later.
Infrastructure as Code (IaC) is one approach that can make infrastructure deployment more consistent and repeatable. With Terraform, infrastructure can be defined through configuration files that can be versioned, reused and shared, while a consistent workflow can be used to provision and manage resources across supported infrastructure providers. ³
The executive issue behind that technical capability is optionality.
How dependent is the workload on a particular platform, proprietary service or operational model? What would be required to reproduce the environment elsewhere? Can infrastructure configurations be documented and automated, or does significant institutional knowledge reside with a handful of people?
Portability does not necessarily mean that a workload should move.
It means the organization retains more control over its ability to make that decision.
7. What happens if the environment becomes unavailable?
Reliability discussions can easily become infrastructure discussions when they should really be business discussions.
How long can this workload be unavailable before the organization experiences meaningful operational, financial or customer impact?
How much data can the organization afford to lose?
Where are backups stored?
What dependencies could prevent an application from recovering even if its primary infrastructure is restored?
Recovery requirements should ultimately reflect business impact. Recovery Time Objectives (RTOs), for example, define how long a system resource can remain unavailable before the disruption creates an unacceptable impact on other resources or supported business processes.⁴
The goal isn’t maximum redundancy everywhere.
It’s the right resilience for the right workload.
8. Are we evaluating workload placement—or simply renewing what we already have?
This may be the most important question.
Infrastructure decisions frequently arrive disguised as renewals, refreshes, migrations or capacity expansions.
That can encourage organizations to begin with a destination:
Which cloud should we move to?
What should replace our current virtualization platform?
How much additional storage should we purchase?
Where can we get GPU capacity?
A better starting point is discovery.
Understand the existing environment. Inventory workloads. Establish dependencies. Baseline performance. Identify business requirements. Determine security, availability and recovery needs.
Then evaluate the options.
That sequence turns an infrastructure event into an opportunity to reconsider whether workloads are running in the environments that make the most sense for them today.
The Future of Workload Placement Is Workload-Driven
The infrastructure conversation doesn’t need another universal answer.
Public cloud, private cloud, dedicated infrastructure, on-premises environments and specialized CPU or GPU resources can all have a role in a modern enterprise architecture.
The more useful question is where each workload belongs.
That requires looking beyond infrastructure as a commodity and evaluating the combination of performance, economics, security, control, resiliency, operational requirements and flexibility that a workload actually needs.
For CIOs, that doesn’t mean mastering every acronym in the data center.
It means asking better questions.
And for Technology Advisors, it creates an opportunity to move the infrastructure conversation beyond products and platforms and help clients evaluate the underlying business and technical requirements driving the decision.
Where GPCN Fits
Global Private Cloud Network (GPCN™) adds another infrastructure option to that conversation.
The platform provides access to private cloud infrastructure across a global network, including virtual machines, GPU compute, block storage and private networking. GPCN is designed for performance-sensitive workloads and combines dedicated infrastructure with cloud-like provisioning and management capabilities. ⁵
Through EnTelegent Solutions, organizations and their Technology Advisors can explore where GPCN may fit within a broader workload-placement strategy—whether the requirement involves private CPU infrastructure, GPU and AI workloads, storage or an alternative infrastructure environment.
The goal isn’t to move every workload.
It’s to determine which workloads may benefit from another option.
Continue the Conversation
Whether you’re evaluating infrastructure for your organization or helping a client assess their options, connect with an EnTelegent GPCN Specialist to discuss workload requirements, request a quote or learn more about partnering with us.
Sources
1. FinOps Foundation, Architecting & Workload Placement — Guidance for evaluating workload architecture and placement based on business value, cost, performance, scalability, security, reliability and operational requirements.
2. NVIDIA, What Is a GPU? — Overview of GPU parallel processing and CPU/GPU workload characteristics.
3. HashiCorp, What Is Terraform? and What Is Infrastructure as Code with Terraform? — Infrastructure as Code, reusable and versionable configuration, and consistent infrastructure provisioning workflows.
4. National Institute of Standards and Technology (NIST), Special Publication 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems — Recovery planning and Recovery Time Objectives based on acceptable business and operational impact.
5. GPCN™, GPCN Hub Documentation — Platform documentation for GPCN infrastructure capabilities.
