Introduction — Why This Series Exists

Technology has gone through one of the most extraordinary economic transformations in modern history.

For over four decades, the industry benefited from continuously cheaper computing resources, exponentially faster processors, collapsing storage costs, and an almost limitless ability to scale systems through virtualization and cloud computing.

During that time, many of the operational disciplines that once defined great engineering slowly faded into the background. Precise sizing, deep performance analysis, workload modeling, and resource optimization became less visible as organizations increasingly relied on abundant infrastructure to compensate for inefficiencies.

But the economics are changing.

Today we are entering an era defined by:

• exploding GPU costs
• massive AI infrastructure investments
• rising power consumption
• thermal and density limitations
• increasingly expensive semiconductor fabrication
• and cloud bills that are exposing years of architectural inefficiency

As these pressures grow, the industry is rediscovering something earlier generations of technologists already understood:

Efficiency matters.

And ultimately:

Sizing matters.

This blog series is intended to explore both the history and the future of performance engineering, capacity planning, and system sizing.

The first blog — this one — focuses on how the industry arrived where it is today:

• the Scarcity Era of computing
• the transition into abundance
• the rise of cloud abstraction
• and the re-emergence of constraints in the modern AI era

Future blogs will move from theory and history into practical engineering.

They will examine modern system architectures and explore the many bottlenecks that organizations often overlook, including:

• CPU saturation
• memory pressure
• NUMA effects
• storage latency
• queue depth issues
• network bottlenecks
• virtualization overhead
• cloud inefficiencies
• database scaling challenges
• and workload contention patterns

The series will also discuss methods for properly monitoring, modeling, tuning, and sizing these environments.

Because the scope of the subject is so large, future entries will likely be broken into multiple specialized blogs by technology area.

Some topics may themselves require multi-part deep dives.

 

About the Author

I started my career in technology in 1978 working on a Basic Four-computer system during the early years of enterprise computing.

Over the decades, I have worked across operations, engineering, architecture, product management, database performance tuning, and large-scale infrastructure analysis.

I have architected sizing and performance analysis tools for technology vendors, worked internationally on database and infrastructure performance engagements, and spent much of my career focused on understanding how systems behave under real-world workloads.

My background includes extensive work with Oracle technologies, enterprise performance tuning, workload analysis, and capacity planning across multiple industries and platforms.

Today, I am employed at Everpure as a Field Solution Architect specializing in Oracle technologies and performance engineering.

Having worked through the mainframe era, distributed systems revolution, virtualization, cloud computing, and now the rise of AI infrastructure, I believe the industry is once again approaching a point where operational discipline, efficiency, and proper sizing will become critical engineering skills.

This series is both a technical discussion and a historical perspective from someone who has watched these cycles evolve over nearly five decades.

 

The Lost Art of Sizing

Part I — The Scarcity Era

In the late 1970s, I started my career in technology. My first roles were in operations, running jobs on mainframes overnight and performing backups. Over time, I moved throughout the IT organization before eventually transitioning into engineering and product management in the late 1980s.

I often refer to the 1970s and early 1980s as The Scarcity Era of computing.

During that time, computing resources were extraordinarily expensive:

• Storage could cost the equivalent of hundreds of thousands of dollars per gigabyte
• Memory was frequently measured in tens or hundreds of thousands of dollars per megabyte
• CPU performance was discussed in terms of MIPS (Millions of Instructions Per Second), with systems delivering only a handful of MIPS costing millions of dollars

Every component in the system represented a major financial investment.

Because resources were scarce and expensive, sizing was treated almost as a science. Capacity planning was not optional — it was foundational to the survival of the business.

Over-sizing a system could waste enormous capital. Under-sizing it could bring critical business operations to a halt.

Every byte mattered. Every CPU cycle mattered. Every disk spindle mattered.

This environment created a culture of discipline:

• Applications were optimized aggressively
• Developers understood resource constraints
• Operations teams monitored utilization closely
• Architects carefully modeled workloads
• Performance engineering was considered a core technical skill

In many organizations, some of the best engineers were the people who could make systems smaller, faster, and more efficient.

Software engineering was deeply connected to hardware realities.

You could not simply “add more servers.” There often were no additional servers to add.

This scarcity shaped an entire generation of technologists.

 

Part II — The Abundance Era

Then something extraordinary happened.

Beginning in the late 1980s and accelerating through the 1990s and 2000s, the economics of computing changed completely.

Moore’s Law, semiconductor scaling, manufacturing efficiencies, and global supply chains created an era of unprecedented abundance.

For nearly forty years:

• CPUs became exponentially faster
• Memory became dramatically cheaper
• Storage costs collapsed
• Networks became faster
• Virtualization increased utilization
• Cloud computing made infrastructure appear almost limitless

For the first time in computing history, performance improvements arrived faster than software inefficiencies could consume them.

This fundamentally changed engineering culture.

Disciplines that had once been mandatory slowly became optional.

Applications no longer had to be highly optimized because hardware improvements continuously masked inefficiencies. Instead of tuning software, organizations increasingly solved problems by purchasing more infrastructure.

A new mindset emerged:

Hardware is cheaper than engineering time.

And for many years, that was largely true.

The rise of virtualization and cloud computing accelerated this transition even further. Infrastructure became abstracted from the engineers writing the software. Developers no longer saw physical systems, disk arrays, or memory limitations. Resources became API calls and provisioning scripts.

Eventually, many organizations evolved toward a model where applications were simply “thrown over the wall” into the cloud.

If performance was poor:

• allocate more CPUs
• add more memory
• scale horizontally
• increase cloud spending

The business unit would absorb the cost.

The direct connection between engineering decisions and infrastructure economics became increasingly invisible.

In many environments:

• poor code was tolerated
• inefficient queries were normalized
• oversized containers became standard
• massive memory consumption was accepted
• idle cloud resources accumulated unchecked

Traditional sizing disciplines faded because the financial pain was no longer immediate or visible to the engineering teams creating the workloads.

The cloud did not eliminate capacity planning — it merely changed who paid for bad sizing decisions.

In the mainframe era, poor sizing decisions were catastrophic because hardware was scarce.

In the cloud era, poor sizing decisions became operational expenditures hidden inside monthly invoices.

The result was a generation of systems that often consumed vastly more resources than their actual business function required.

Ironically, many of the operational disciplines developed during the Scarcity Era were not technically obsolete — they had simply become economically unnecessary for a time.

But that may now be changing again.

 

Part III — The Return of Constraints

For nearly four decades, the technology industry operated under a powerful assumption:

Tomorrow’s hardware would solve today’s software problems.

For a long time, that assumption held true.

If an application consumed too much CPU:

• processors became faster

If memory usage grew:

• RAM became cheaper

If storage exploded:

• disk costs continued collapsing

If workloads increased:

• cloud platforms scaled almost infinitely

The economics of computing continuously compensated for inefficient engineering.

But today, something significant is changing.

The industry is beginning to encounter limits again.

Not theoretical limits — real economic, physical, and operational limits.

 

Modern computing infrastructure is no longer getting dramatically cheaper at the rate it once did.

Instead, we are seeing:

• exploding GPU costs
• rising power consumption
• thermal limitations
• expensive high-bandwidth memory
• enormous cloud infrastructure bills
• increasingly expensive semiconductor fabrication
• AI workloads consuming unprecedented resources

For the first time in decades, inefficient software design is becoming economically visible again.

And this has exposed a reality that many organizations had quietly ignored for years:

• poor code
• oversized architectures
• inefficient databases
• excessive abstraction layers
• uncontrolled cloud sprawl
• wasteful microservice designs
• badly tuned queries
• overallocated Kubernetes clusters
• massive idle infrastructure footprints

For years, these inefficiencies were masked by cheap hardware and elastic cloud scaling.

Now they are appearing directly on financial statements.

The cloud did not eliminate waste. It made waste easier to hide.

Until the bills became too large to ignore.

 

At the same time, another challenge has emerged.

Many of the people who developed the operational disciplines of the Scarcity Era are no longer in the industry.

They have:

• retired
• moved into leadership
• transitioned into consulting
• or left technology entirely

The generation that deeply understood:

• workload modeling
• performance engineering
• memory optimization
• queue management
• efficient batch processing
• storage layout
• capacity forecasting
• low-level tuning

is steadily disappearing.

Much of that knowledge was never fully documented because it was simply considered part of being an experienced engineer.

As a result, many younger organizations grew up in an environment where:

• infrastructure felt unlimited
• optimization seemed unnecessary
• cloud scaling replaced careful design
• operational cost was someone else’s problem

Now the industry faces a difficult transition.

The old constraints are returning, but many of the disciplines required to manage those constraints have faded.

 

In many ways, the industry is rediscovering something that earlier generations of technologists already understood:

Resources are never truly infinite.

Eventually:

• power matters
• memory matters
• storage matters
• latency matters
• thermal density matters
• architecture matters

And ultimately:

sizing matters.

The art of sizing has returned.

Not because technology stopped advancing, but because economics, physics, and scale have once again forced the industry to confront efficiency.

What was once viewed as an outdated operational skill may soon become one of the most important engineering disciplines again.

 

Part IV — History Does Not Repeat, But It Rhymes

What we are seeing today in technology is historically unusual — but it is not entirely unprecedented.

Other industries have gone through similar transitions where periods of explosive advancement, falling costs, and seemingly limitless growth eventually collided with economic and physical realities.

The railroad industry is one example.

In the early days of rail expansion during the Industrial Age, railroads transformed economies. Expansion happened rapidly. Costs initially fell as infrastructure scaled, routes expanded, and technology improved.

For a time, railroads represented nearly unlimited economic optimism.

But eventually the easy growth ended.

The cost of expanding and maintaining rail infrastructure began rising dramatically. Marginal improvements became more expensive. Complexity increased. Maintenance became a larger percentage of operating cost. Competition intensified. Returns diminished.

The industry did not disappear. In fact, railroads remained enormously valuable to the economy.

But the economics changed.

The same pattern appeared in other industrial and technological revolutions:

• aviation after the jet age
• nuclear power generation
• telecommunications infrastructure
• automobile manufacturing
• even electrical grid expansion

Early stages were driven by rapid gains and falling relative costs.

Later stages became dominated by:

• scale complexity
• infrastructure costs
• power requirements
• operational efficiency
• regulation
• and diminishing economic returns on incremental improvements

Technology did not stop advancing.

It simply became harder, more expensive, and more complex to continue advancing at the same pace.

That is increasingly where modern computing appears to be heading.

We are now entering the Age of AI.

AI will absolutely create enormous value. In many ways, it already has.

But there is growing evidence that the economics of this era are going to be very different from the cloud and consumer internet revolutions that preceded it.

AI infrastructure is extraordinarily expensive:

• massive GPU clusters
• enormous power consumption
• advanced cooling systems
• high-bandwidth memory
• increasingly expensive semiconductor fabrication
• global supply chain dependencies

For years, the technology industry operated almost like a perpetual motion machine where computing became continuously cheaper while performance improved exponentially.

Today, the relationship between cost and performance is changing.

That does not mean AI is a failure.

Far from it.

But technological revolutions are not light switches.

They are transitions.

And transitions are messy.

Industries often overspend before they stabilize. Architectures evolve through trial and error. Infrastructure expands ahead of efficient utilization. Economic models mature slowly.

The railroad era experienced this. The electrical age experienced this. The internet boom experienced this.

And now AI appears to be entering a similar phase.

The challenge for the next generation of technologists will not simply be building larger systems.

It will be learning how to build efficient, economically sustainable systems again.

Which may ultimately bring the industry back to a lesson many believed had become obsolete:

The art of sizing never really disappeared.

It was merely waiting for constraints to return.