What the History of Data Centers Means for the Concrete Industry

Cloud Computing, 1946 Style | Credit: U.S. Army photo, public domain, via Wikimedia Commons.

I got the idea for this blog post from the No Agenda podcast, which I donate to every month.

Hint, hint.

Now would be a great time to stop reading and donate to your favorite concrete podcast: www.concretelogicpodcast.com/donate

See how smooth that was?

Anyway, I was listening to the No Agenda Show when John C. Dvorak made a point about data centers that stuck with me.

His point was simple: computing has already been through this cycle.

It starts local.

Then it moves remote.

Then it moves back local.

Then it moves remote again.

For most of us in the concrete industry, data centers are not a technology discussion. They are a bid invite.

You get an email from a general contractor. There is a site package. Foundations. Maybe tilt-up. Slab-on-grade. Lots of equipment pads, duct banks, paving, utility structures, generator pads, screen walls, retaining walls, and a schedule that looks like it was written by someone who has never seen rain.

That is how most concrete people experience data centers.

But we probably need to pay closer attention.

Not because we need to become IT experts. Not because we need to understand every chip, rack, cooling loop, or software stack.

We need to understand the cycle.

Because if data centers are going to keep driving concrete demand, we need to know whether we are looking at a long-term infrastructure shift or just the latest version of an old pendulum swing.

And history says the pendulum always swings.

1940s–1950s: The Computer Was the Room

Before “the cloud,” before server farms, before AWS, before AI, computing was a machine in a room.

A big room.

In the 1940s and 1950s, early computers like ENIAC and UNIVAC were massive. They needed dedicated space, dedicated power, dedicated cooling, and dedicated people who knew how to keep them alive.

Nobody had a computer on their desk.

Nobody had a phone in their pocket.

Nobody was asking a robot to write an email to the concrete supplier about missing test cylinders.

The computer was the facility.

You went to the machine. Or more accurately, your information went to the machine.

The user was local.

The computer was somewhere else.

Sound familiar?

1960s–1970s: Mainframes Were the First Cloud

In the 1960s and 1970s, companies, universities, banks, and government agencies used mainframes.

A mainframe was not something everyone had. It was expensive, powerful, and centralized. People used terminals to connect to it. Those terminals were not really computers in the way we think of them today. They were mostly a keyboard and screen connected to the real machine.

The brain was somewhere else.

This was centralized computing.

A bunch of users connected to one powerful system.

Today we call that cloud computing and act like we invented something new.

We didn’t.

We improved it.

The mainframe was the old cloud. It just had worse graphics, less marketing, and probably a much more serious guy in a short-sleeve dress shirt guarding the room.

1970s–1980s: Computing Moved Closer to the User

As computers got smaller and cheaper, the pendulum started to swing.

In the 1970s and 1980s, departments inside companies started getting their own systems. Instead of one central computer doing everything, different groups could have their own computing power.

Accounting had a system.

Engineering had a system.

The lab had a system.

The factory had a system.

This was not fully personal computing yet, but it moved power closer to the people doing the work.

Why?

Because people do not like waiting on central control.

This is true in IT.

It is true in construction.

It is true when a project engineer is waiting on an RFI answer.

Centralized systems are efficient until they become bottlenecks.

Then people find a way around them.

1980s–1990s: The PC Put the Computer on the Desk

Then came the personal computer.

In the 1980s and 1990s, computing moved from the central room to the individual desk. Word processing, spreadsheets, estimating, accounting, CAD, and databases all started moving closer to the user.

This changed everything.

It gave people control.

It also created chaos.

Files lived on individual machines. Backups were inconsistent. Software versions did not match. Every department had its own way of doing things. People made spreadsheets that became mission-critical business systems even though nobody wanted to admit it.

Again, sound familiar?

The PC era was powerful because it was local.

It was messy because it was local.

That is usually the tradeoff.

Local gives you speed, control, and flexibility.

Remote gives you scale, consistency, and control from the center.

The history of computing is mostly a fight between those two forces.

1990s–Early 2000s: Companies Re-Centralized With Servers

By the 1990s and early 2000s, businesses had a problem.

Everybody had computers, but now the information was scattered everywhere.

So companies started moving important applications and data back to servers.

The desktop computer still mattered, but the important stuff lived in a server room or corporate data center.

This was the client-server era.

The user had a smart machine, but the shared database, application, or file system lived somewhere more controlled.

That was the pendulum swinging back toward the center.

Not all the way back to mainframes.

But definitely back toward centralized control.

The concrete version is easy to understand.

A company lets every project team create its own form, spreadsheet, and process. That feels fast at first. Then the company grows and nobody can compare anything. So they centralize preconstruction, accounting, safety, quality, scheduling, and reporting.

Then people complain the centralized system is too slow.

Then they create side spreadsheets.

Then management tries to kill the side spreadsheets.

Then the cycle starts again.

Technology is not as unique as technology people think.

Late 1990s–2000s: The Internet Turned the Server Room Into Someone Else’s Problem

Then the internet changed the geography.

In the late 1990s and 2000s, companies no longer needed everything inside their own building.

Software could be hosted somewhere else. Data could live somewhere else. Servers could sit in a colocation facility. Companies could rent space, power, cooling, and network access instead of building their own data center.

This is when the modern data center industry really started to take shape.

The server room left the office and became a real estate, power, and infrastructure business.

That matters for concrete people.

Because once computing left the office closet, it became construction.

Buildings.

Slabs.

Foundations.

Tilt panels.

Paving.

Utility duct banks.

Stormwater structures.

Equipment pads.

Generator yards.

Cooling infrastructure.

Security walls.

Substations.

Access roads.

The internet did not make computing less physical.

It made the physical parts easier to ignore.

2006–2020s: The Cloud Became the New Mainframe

Then came the cloud.

Starting in the mid-2000s, Amazon, Microsoft, Google, and others figured out that companies did not want to buy, maintain, cool, secure, and replace their own servers if they could rent computing power instead.

The pitch was simple:

Why own the machine when you can rent the output?

That changed everything.

Businesses could scale faster. Software companies could launch without buying a room full of servers. Storage and computing became something you could turn up or down.

This was centralization again, but bigger.

Much bigger.

Instead of one company having a server room, a hyperscale cloud provider builds a campus with hundreds of thousands of servers. Instead of every company buying backup power, cooling, and IT staff, the cloud provider does it at industrial scale.

That is why the data center boom became so massive.

The cloud is not floating in the sky.

The cloud is land, power, concrete, steel, copper, fiber, water, transformers, switchgear, generators, and a construction schedule.

For our industry, this is the part worth remembering:

Every digital revolution eventually becomes a physical construction project.

AI is no different.

2020s and Beyond: AI Pushes the Cycle Again

AI has made the data center conversation bigger.

Training large AI models takes enormous computing power. That kind of computing wants to be centralized. It needs huge power supplies, specialized chips, cooling systems, and buildings designed around density and uptime.

That is why we are seeing massive data center campuses.

That is why utilities are scrambling.

That is why power availability has become one of the biggest constraints.

That is why concrete people keep getting invited to price these projects.

But history says the same cycle will probably happen again.

AI starts centralized because it needs scale.

Then pieces of it move local because users want speed, privacy, lower cost, and control.

Ten or fifteen years ago, did most people think they would be talking to their phone?

Did most people think they would have Amazon boxes in their house listening for commands?

Not really.

Then it became normal.

That shift happened quickly.

Local AI will likely follow the same path.

Some AI will run in massive data centers. Some will run in regional facilities. Some will run on phones, laptops, vehicles, cameras, job trailers, tools, and equipment.

A job-site camera may identify progress or safety issues without sending every second of video to a remote server.

A batch plant may use local AI to flag inconsistencies.

A contractor may have an AI assistant trained on its own specs, RFIs, safety policies, and past project lessons.

The pendulum will not swing all the way back.

But it will swing.

Why Concrete People Should Care

The concrete scope follows the computing model.

When computing centralizes, concrete demand shows up in massive campuses.

When computing decentralizes, concrete demand spreads into regional facilities, edge sites, utility upgrades, substations, industrial buildings, and retrofits.

That is the point.

The work does not disappear.

It changes shape.

So when we get the next data center bid invite, we should ask more than:

Can we hit the schedule?

What is the mix?

How many yards?

Who has the labor?

What is the floor tolerance?

We should also ask:

Where is computing going next?

Because a data center is not just a building type.

It is the current physical expression of where computing sits in the cycle.

And that cycle has never stopped moving.

The cloud is not magic.

AI is not weightless.

Data does not float.

Somewhere, someone has to build the place where all this stuff lives.

And before the chips turn on, the concrete has to show up.