Introduction

Something I've been pondering for a while is how to visualise the way I've tried to make decisions throughout my career. Fundamentally there is always a trade-off so I'd like to present the Infrastructure Triangle.

Like many of these sort of helpful triangles, The Infrastructure Triangle is a decision-making model for technical leads driving infrastructure, tooling, automation and operational solutions.

It describes three desirable properties:

• Operational Performance (from here referred to as Fast): Minimise the time required to deliver a solution and the time required for it to perform its intended work.

• Resource Efficiency (Efficient): Maximise useful output from available resources, minimising waste and unnecessary effort.

• Cost of Ownership (Cheap): Minimise the total cost of delivering, operating and maintaining the solution.

The underlying principle is that, when meaningful constraints exist, optimising for two properties often requires a compromise in the third.

A solution that is fast and efficient may require greater financial investment. One that is fast and cheap may accept inefficiency or operational overhead. One that is efficient and cheap may sacrifice performance or immediate availability.

The triangle does not prescribe which compromise is correct. Its purpose is to make the trade-offs explicit, allowing technical leads to select solutions that best serve the needs of the business.

1. Defining the three points

Fast - Optimise for time

How quickly can we deliver the solution, and how quickly can it do its job?

Fast covers both the delivery of a capability and its operational performance once it is available.

It has two principal dimensions:

• Time to deliver: Design, implementation, provisioning, deployment and time to value.

• Time to execute: Execution duration, response latency, throughput, queue time and recovery time, as appropriate to the workload.

For infrastructure and build engineering, this might mean how quickly a Jenkins agent can be provisioned, how long a Unity build takes, how quickly a pipeline responds to a code change, or how rapidly a service recovers from failure.

Typical characteristics include managed services, pre-provisioned capacity, parallel execution, caching, high-performance infrastructure and straightforward implementation.

Typical sacrifice: Higher infrastructure costs, additional capacity, duplicated resources, or greater engineering investment to reduce execution time.

The important distinction is that a solution can be quick to implement but slow to operate, or expensive and time-consuming to develop but exceptionally fast once running.

Fast is concerned with the time taken to achieve the required outcome across the solution's lifecycle.

Efficient - Optimise for useful output

How effectively do we use the resources and effort available to us?

Efficiency measures how much useful work we achieve from the resources consumed.

This includes compute, storage, network capacity, infrastructure utilisation, engineering effort, operational toil and the reuse of existing capabilities.

Typical characteristics include right-sized infrastructure, effective workload scheduling, shared services, caching, reusable pipeline components, automation and automated resource lifecycle management.

For example, a shared Jenkins fleet might maximise agent utilisation by scheduling workloads carefully, while reusable GitLab pipeline components might eliminate duplicated engineering effort across multiple teams.

Typical sacrifice: Upfront engineering investment, additional complexity, longer implementation lead times, or reduced spare capacity that can affect performance during demand spikes.

Efficiency is not the same as cheapness. A highly efficient system may require expensive hardware or substantial engineering investment to achieve excellent utilisation and throughput. Equally, an inexpensive solution may be highly inefficient if it consumes excessive human effort or repeatedly performs the same work.

Cheap - Optimise for total cost

How little does it cost to deliver and sustain the required capability?

Cheap considers the total cost of ownership rather than just the initial purchase price or monthly infrastructure bill.

It includes:

• Compute, storage, networking and other infrastructure expenditure.

• Hardware purchases, licences and support contracts.

• Engineering time required to build, maintain and operate the solution.

• Ongoing manual work, maintenance and incident response.

• The cost of upgrades, scaling and eventual replacement.

Typical characteristics include using existing infrastructure, adopting suitable open-source tools, choosing appropriately sized resources, reusing existing capabilities and avoiding unnecessary complexity.

Typical sacrifice: Longer waiting times, lower throughput, reduced redundancy, manual intervention or deferred improvements.

A solution that avoids spending £500 on cloud resources but consumes hundreds of hours of engineering time may be inexpensive in one budget and expensive overall.

Equally, spending more on infrastructure can be the cheaper option over the lifetime of a high-volume workload if it significantly reduces execution time and ongoing operational effort.

Cheap is about the overall cost of delivering the required outcome, not simply choosing the lowest-priced option.

2. The three trade-offs

The triangle becomes most useful when considering the consequences of prioritising two properties over the third.

These combinations represent typical infrastructure strategies rather than absolute rules. The appropriate choice depends on the workload, its frequency, the business priorities and the constraints involved.

Fast + Efficient = Expensive

Trade-off: Cheap

You invest in infrastructure and engineering to achieve high performance while making effective use of resources.

The objective is to deliver results quickly without wasting resources, even if doing so requires more investment.

Example: A dedicated, high-performance build farm with appropriately sized parallel workers, fast storage, effective caching and pre-warmed build environments.

Builds complete quickly, resources are used effectively, and developers spend less time waiting. However, the infrastructure, engineering effort and ongoing support may cost more or require a larger team to manage it than a simpler alternative.

Why choose it?

When developer productivity, release cadence, throughput or service responsiveness justifies the additional investment.

Typical scenario: A release-critical Unity build pipeline where reducing build duration has a measurable impact on the team's ability to deliver updates.

Fast + Cheap = Inefficient

Trade-off: Efficient

You prioritise quick results and low cost, accepting that the solution may waste resources, duplicate effort or create operational overhead.

The objective is to solve the immediate problem with minimal expenditure and delay, rather than investing in the most reusable or optimised approach.

Examples:

• Manual processes instead of automation: An engineer manually triggers and monitors builds rather than investing in automation. This can be fast and inexpensive to establish for a one-off task, but consumes repeated human effort if used frequently.

• Quick, bespoke scripts: A small script solves an immediate problem without the development cost of a reusable component. Similar scripts may subsequently be created by other teams, duplicating functionality and maintenance.

• Using existing infrastructure without optimisation: An additional workload is placed on an existing build agent rather than investing in a more appropriate shared architecture. This avoids new expenditure but may introduce contention, unnecessary waiting or operational workarounds.

• Deferring improvements: An existing system is kept running because replacing or optimising it would require investment. This avoids immediate costs but can preserve inefficient processes and repeated manual effort.

Why choose it?

When the problem is urgent, the workload is temporary, budgets are constrained, or the cost of building a more sophisticated solution exceeds the expected benefit.

Typical scenario: A one-off release task is handled manually because building and maintaining a fully automated pipeline would take longer and cost more than the task itself.

The critical distinction is that this approach can be entirely sensible for an isolated problem. As the frequency, scale or lifetime of the workload increases, the accumulated waste may make it the more expensive option.

Efficient + Cheap = Slow

Trade-off: Fast

You minimise expenditure and maximise the value extracted from existing resources, accepting longer execution times, queues or reduced immediate availability.

The objective is to achieve the required outcome with minimal waste and cost, rather than optimising for the shortest possible elapsed time.

Examples:

• Shared build infrastructure: A limited pool of right-sized Jenkins agents or Gitlab runners handles workloads from multiple teams. Utilisation is high and costs are controlled, but builds queue during peak demand.

• Scheduled workloads: Non-urgent jobs run during quieter periods to maximise utilisation and avoid provisioning additional capacity.

• Resource reuse: Existing infrastructure and cached artefacts are reused wherever practical, avoiding additional expenditure but sometimes introducing waiting or scheduling constraints.

• Consolidated services: Multiple workloads share a smaller infrastructure footprint rather than receiving dedicated resources, reducing expenditure but potentially limiting their ability to run concurrently.

Why choose it?

When workloads are predictable or non-urgent, cost control is important, and the business can tolerate longer turnaround times.

Typical scenario: Overnight validation jobs run on a shared build fleet. They complete reliably and economically, even though the system would not be suitable for a developer who needs immediate feedback during an interactive workflow.

The trade-off is not necessarily that the infrastructure is poorly performing. It is that the solution deliberately avoids spending money to eliminate every queue, delay or capacity constraint.

3. Applying the triangle to infrastructure decisions

The following examples illustrate how the model can help technical leads evaluate real choices.

Scenario A: A Unity build takes too long

Objective: Reduce build turnaround time and improve developer productivity.

Fast + Efficient: Invest in parallel build agents, appropriate compute, effective caching and pipeline optimisation. The infrastructure and engineering investment may be higher, but builds complete faster without unnecessary resource consumption.

Fast + Cheap: Use existing infrastructure and a straightforward workaround to get an immediate improvement. This might avoid investment in a reusable build platform but introduce duplicated scripts, manual steps or contention that becomes increasingly costly at scale.

Efficient + Cheap: Retain the existing fleet and improve scheduling, resource allocation and caching where possible. Costs remain controlled, but limited capacity may mean some builds continue to queue.

Leadership question: How much developer waiting time is the business willing to pay to eliminate, and at what workload volume does additional investment become worthwhile?

Scenario B: A new GitLab runner capability is required

Objective: Deliver a capability that multiple teams can use consistently.

Fast + Efficient: Adopt an appropriate existing solution or invest in a reusable, well-supported component that can be rolled out consistently. This may involve licence costs or greater upfront engineering investment.

Fast + Cheap: Implement a small, team-specific script or workaround, target runners to team specific tags. The immediate problem is solved quickly and inexpensively, but future teams may duplicate the work or maintain incompatible versions. Adding teams, will result in adding runners.

Efficient + Cheap: Develop a shared component with a standard interface, documentation and clear ownership. This reduces repeated effort and long-term maintenance, but takes longer to design, implement and roll out.

Leadership question: Is this a one-off problem, or are we investing in a capability that will provide value across the organisation?

Scenario C: A cloud workload runs continuously

Objective: Reduce the cost of a stable infrastructure workload without compromising essential service requirements.

Fast + Efficient: Use appropriately scalable infrastructure, automated recovery and tuned capacity. This can deliver responsive performance without unnecessary resource consumption, but redundancy and spare capacity may increase cost.

Fast + Cheap: Use an existing deployment mechanism and available infrastructure to get the workload running quickly. The solution may be inexpensive to establish but less efficient to operate, monitor or scale.

Efficient + Cheap: Right-size instances, consolidate workloads and maximise utilisation. The system remains economical, but may have less spare capacity to absorb demand spikes, potentially increasing queues or recovery times.

Leadership question: What is the cost of spare capacity compared with the business impact of waiting, degraded performance or unavailability?

4. Using the triangle as a technical leadership tool

The Infrastructure Triangle should not be used simply to label a solution as good or bad. Its purpose is to make the decision-making process more explicit.

A technical lead should be able to explain five things.

1. What are we optimising for?

Identify which properties matter most for the particular workload. A developer-facing build pipeline may prioritise speed, while a scheduled reporting workload may prioritise cost and efficiency.

2. What are we sacrificing?

State the compromise explicitly. Are we accepting longer build queues, higher expenditure, manual work or additional complexity?

3. Who bears the cost?

Infrastructure expenditure is visible in a budget, but the cost of waiting, repeated manual work and reduced developer productivity may be spread across other teams. The decision should consider the wider organisation rather than only the team's immediate budget.

4. Is the trade-off temporary or permanent?

A manual workaround may be justified to meet an urgent deadline. It may be inappropriate as a permanent solution for a frequently repeated workload.

5. What would change our decision?

Define the circumstances that would justify revisiting the choice. Examples include increasing build volume, growing cloud expenditure, repeated operational incidents, excessive queue times or the introduction of new business requirements.

This turns the triangle into a practical design-review tool. Rather than debating whether a particular technology is inherently better, the discussion focuses on the outcome required, the cost of achieving it and the consequences of the selected approach.

5. Distinguishing the three dimensions

The model depends on keeping Fast, Efficient and Cheap separate enough to support meaningful decisions.

These measures are related, but they are not interchangeable.

A system can be efficient yet slow because it deliberately queues work to maximise utilisation. A system can be fast yet inefficient because it uses more resources than necessary to minimise execution time. A system can have a low purchase price yet be expensive to operate because it requires constant manual intervention.

The measures should also be selected to suit the workload. For example, throughput and latency are useful for an online service, whereas queue time and build duration may be more relevant for a build farm.

One further consideration is the value of engineering time. Manual intervention is not automatically a bad decision: for a rare, one-off task, it may be cheaper than automation. For a frequently repeated task, the cumulative cost can quickly outweigh the initial investment in a reusable solution.

The triangle is therefore best used to compare options against a consistent workload, time horizon and set of requirements.

6. Summary

So, what makes my triangle different from other triangles you may have seen online? As far as I can tell, the main differences are;

1. Fast includes operational performance. You're not just asking how quickly an engineering team can deliver a solution. You're also asking how quickly that solution executes builds, provisions infrastructure, processes workloads or recovers from failures.

2. Efficient is not the same as Good. A solution can be high quality but inefficient, or efficient but slow. You're explicitly considering how well infrastructure and engineering effort are utilised, rather than treating quality as the third variable.

3. Cheap includes the lifetime cost of operating the solution. You're considering infrastructure expenditure alongside engineering effort, maintenance and operational overhead. This is especially relevant to infrastructure that runs for years.

And that's it. My Infrastructure Triangle. I hope you find it useful.