Lakshya

IT Infrastructure

Datacentre & Critical Facilities

Infrastructure · datacentre 73%, power and cooling 70%

The physical layer. Unfashionable, non-optional, and being rebuilt right now because AI broke the assumptions it was designed around.

Seventy-three percent of IT infrastructure postings name datacentre or colocation work and 70% name power, cooling or critical facilities. This is not a legacy field — it is a constrained one, and the constraint has become the story: AI workloads need power densities that most existing halls physically cannot deliver.

TimeWhat you are actually doing
07:30Walk the floor. Thermal imaging on a suspect rack, a check on a PDU that alarmed overnight, and a look at the cage where the new row is going.
09:30Capacity meeting. Not server capacity — power. How many kilowatts are contracted, how many are committed, and how many are actually drawn, because those three numbers are always different.
11:00A cooling design review. Rear-door heat exchangers versus direct-to-chip for the new deployment, and whether the building's water loop can carry it.
14:00Vendor and logistics. Lead times, a delayed shipment, and the fact that the row cannot energise until a specific part arrives.
16:00Change control. A UPS maintenance bypass next weekend, which is the highest-risk routine activity in the building and is planned accordingly.

What makes this hard

  • Nothing is reversible quickly. A software mistake rolls back; a power design that cannot carry the load is a construction project.
  • Lead times dominate. Transformers, switchgear and generators are measured in quarters, sometimes years, so capacity planning has a horizon most technologists never work at.
  • Concurrent maintainability — every component must be serviceable without taking load offline, which is what Tier III actually means and why it costs what it does.
  • Safety is a real constraint, not a compliance checkbox. Arc flash, working at height, and lockout-tagout are the parts of infrastructure where people are genuinely hurt.

The decisive round

“We want to deploy AI training in an existing hall. Can we?”

Interviewer: “The business wants to put GPU training racks into our existing datacentre. What do you tell them?”

A weak answer. “I'd check we have the space and power available, and if not we'd need to look at expanding or using a colocation provider.” Right conclusion, no reasoning, and it misses the constraint that actually decides it.

A strong answer. “Space is almost never the binding constraint, and I would say that first. A hall designed for 5 to 10 kW per rack has the floor area for GPU racks and cannot power or cool them — a dense training rack can draw 40 to over 100 kW, so a single row can exceed what a whole aisle was designed for.

So the questions in order. What is our contracted power and our actual draw? The gap is what is genuinely available, and it is usually smaller than people assume because commitments are counted optimistically. What can the distribution deliver to a single rack position? Even with headroom in the building, the busway, PDUs and branch circuits to that spot may cap far lower. Can we reject the heat? This is where it usually fails — air cooling runs out somewhere around 30 kW per rack in most designs, so we are talking about rear-door heat exchangers or direct-to-chip liquid, which needs a water loop the building may not have. Can the floor carry it? Dense racks are heavy, and raised floors have limits.

Then the honest answer, which is usually: we can deploy a small number of racks by spreading them across the hall to distribute thermal load — which wastes space and is often the right pragmatic move — and anything at scale needs either a retrofit with liquid cooling or a purpose-built facility. I would give the business both the number of racks we can take today and the lead time and cost for each option, because ‘no’ without alternatives just gets routed around.”

Knowing that power and heat rejection bind before space, and giving the business a number they can plan against rather than a refusal.

  • Learn the arithmetic: kW per rack, PUE, cooling capacity, and how to convert a GPU specification into a power and heat budget.
  • Understand redundancy notation — N, N+1, 2N, and what concurrently maintainable actually requires.
  • Know the liquid cooling options and their building implications, because this is the live question in the field right now.
  • Have a capacity story where you forecast a constraint far enough ahead that something could be done about it.

Compensation

MarketBandNotes
United States$95k – $185kCritical facilities engineering with electrical depth sits at the top
India₹8L – ₹35L totalGrowing quickly with domestic datacentre buildout
Both—The lowest band of the five fields, and the one with the least competition per posting

The book for this field

Networks, Automation, Connectivity & Data Centres

Twelve chapters from a single packet to a submarine cable. Subnetting worked by hand, BGP and why hijacks succeed, DNS and the two outages worth knowing by name, TLS and the expiry that still takes down companies, cloud networking with the arithmetic, transit and peering, colocation and what an AI rack did to the industry, and four debugging scenarios worked end to end.

CHAPTER 11Colocation and the data centreWhat you are actually renting, what the bill is made of, and why an AI rack changed the economics of an entire industry.READ THE CHAPTER →CHAPTER 13Data centre engineering: what the numbers actually sayTiers, PUE, rack density and cooling — with the published figures, and the four places the industry's own marketing contradicts its own survey data.READ THE CHAPTER →CHAPTER 9The WAN: leased lines, MPLS, SD-WAN and what actually replaced whatHow offices, factories and data centres connect to each other, and why a technology that dominated for twenty years is now a line item people are trying to remove.READ THE CHAPTER →

All 18 chapters in Networks, Automation, Connectivity & Data Centres →

Also read for this role

Infrastructure & Reliability

Reliability and error budgets, capacity arithmetic, networks, storage and the restore you have not tested, the physical layer, a debugging method that transfers, running production, and an honest look at Kubernetes. Plus a Middleware section — web and application servers, messaging (IBM MQ, Kafka) and managed file transfer, from basics to licensing and cost.

CHAPTER 5The physical layer, and why AI broke the datacentrePower, cooling and space. Unfashionable, non-optional, and currently the binding constraint on the entire industry.READ THE CHAPTER →CHAPTER 2Capacity, and the cost of being wrong in each directionUnder-provision and you fail. Over-provision and you fund nothing else. The arithmetic is learnable in an afternoon.READ THE CHAPTER →CHAPTER 1What actually makes a system reliableNot uptime. A shared, written definition of acceptable, and a budget for spending the rest.READ THE CHAPTER →

All 33 chapters in Infrastructure & Reliability →

Cross-cutting

Skills every archetype tests

These are shared across every field on this site — the same question asked in different vocabulary — so preparation here compounds rather than being spent once. The book above is specific to your field.

Design under constraintThe decisive round for SRE, AI Platform, Infrastructure — and the reason strong engineers fail it.READ THE CHAPTER →Failure and incident narrativeEvery archetype asks for this story. The outage is the setting; the decisions are the content.READ THE CHAPTER →

Practice the 8 IT Infra questions →  ·  Back to IT Infrastructure →