T-SQL Tuesday is a monthly community blogging event started by Adam Machanic back in 2009. Each month, a host picks a topic, participants write about it on the second Tuesday of the month, and the host posts a recap linking everyone’s contributions together. It has been running for over fifteen years now, which is frankly remarkable for anything on the internet.
This month’s host is Koen Verbeek, and he based the topic on a post I wrote earlier this year called The Whiplash Effect. The more I think about that post, the more I realize I’m nowhere near done with the topic. Koen offered several entry points — war stories, advice for juniors, perspectives from people who never left on-prem — but I’m going to start with the most personal one: what skill would I actually have to relearn if I had to go back?
Let me tell you where I landed.
We’re not building. We’re assembling. #
There’s a distinction I keep coming back to when I try to explain the difference between cloud and on-premises work to people who haven’t been around long enough to have worked on-premises.
Think about Lego. You have a large pile of bricks in different shapes and colors. There are many ways to connect them — the constraint is mostly your creativity, and occasionally physics. But the freedom cuts both ways: it’s entirely on you to figure out how to make the pieces fit together in a way that actually works as intended. Nobody is going to stop you from building something that looks impressive and collapses immediately.
A model kit is different. You get a lot of pieces, many of them requiring careful preparation — cleaning up mold lines, sanding, priming — but the ways to assemble them are far more constrained than a pile of Lego bricks. And crucially, the kit comes with options. Different turrets for the tank. Different weapon loadouts for the mech. You make real choices, and those choices matter — but you’re choosing between configurations that have already been designed, tested, and validated to fit together. Nobody is handing you raw styrene and a lathe.
That’s what the cloud is. A very sophisticated model kit, with variant sprues.
The options are real. Do you want zone-redundant storage or locally redundant? A dedicated SQL instance or a serverless one that scales to zero? A complete analytics-in-a-box solution such as Fabric or just Power BI? These are meaningful architectural decisions with genuine trade-offs. But you are always choosing from a menu. The underlying pieces snap together in ways that have been engineered to work. The tolerances are set. The fit is designed.
Infrastructure-as-a-service, platform-as-a-service — these are pre-built assemblies. Someone else already made the load balancer work. Someone else figured out the networking between the compute layer and the storage layer. Your job is to select the right assemblies and connect them in a configuration that solves your specific business problem. It’s genuinely a different kind of work, and it rewards a different kind of thinking.
On-premises, there are no pre-built assemblies. You have the bricks, and you have a problem to solve — and everything in between is yours to figure out.
The assemblies don’t build themselves #
Here’s what that actually means in practice.
When I came up in this profession, you didn’t get a managed SQL instance with a checkbox for high availability. You got a server, a license, and a problem. If you wanted high availability, you learned clustering. You learned shared storage. You learned what a quorum witness was and why it mattered, often by watching a cluster fall over in a catastrophic way in the middle of a Saturday night. You learned that “failover” and “instant failover” are not the same thing, and that your application developers had strong opinions about the difference.
You learned networking. Not “I understand the concept of networking” — you actually learned subnets, VLANs, firewall rules, and what happens when you get them wrong. You learned that a misconfigured network isn’t a cloud ticket you raise and wait on. It’s you, a network engineer who is mildly annoyed at you, and a packet capture. (Here is a top tip: make sure that the net masks of the private IPs on all the nodes of a Windows Cluster matches.)
You learned virtualization. Not as an abstraction, but as a set of decisions with real consequences. What happens when you overcommit CPU on a host? What about memory? What does a resource-starved VM actually look like from inside SQL Server, and how do you distinguish that from a bad query? These weren’t theoretical questions. They were Friday afternoon questions.
And through all of it, you developed a very intimate relationship with the concept of unintended consequences.
And when something goes wrong — and something always goes wrong — the buck stops with you. Not with a platform team, not with a support SLA, not with an incident response bot. There might be a support engineer somewhere who can help with a specific layer of the stack, but they will arrive with a strong prior that the problem is not theirs. Proving otherwise is your job. You are the integrator, the architect, the diagnostician, and ultimately the one accountable for the whole thing holding together. Nobody else has the full picture. Nobody else can have it.
The skill I would have to relearn #
So what would I actually have to relearn?
The honest answer is: troubleshooting from first principles.
In Azure, when something goes wrong, the diagnostic surface is rich and the abstraction layers are doing most of the heavy lifting. Azure Monitor, Log Analytics, built-in metrics, alerts — there is an enormous amount of tooling designed to tell you what is wrong before you have to figure it out yourself. The managed services hide the infrastructure, which is mostly a feature. Until it isn’t.
On-premises, when something goes wrong, you are much closer to the metal. You don’t have platform logs handed to you — you configure them, you collect them, you query them. You need to understand what you’re looking at, which requires understanding the layers below the thing that’s misbehaving.
I spent years developing exactly that kind of bottom-up diagnostic intuition. SQL Server behaving strangely? Is it the query, the statistics, the memory pressure, the I/O subsystem, the storage controller, the SAN configuration, or the fact that someone decided to run a full backup on the same spindles as tempdb? Each of those is a real place to look. Each of them requires a different set of tools and knowledge to investigate.
In the cloud, that problem space collapses. You don’t own the storage controller. You don’t manage the SAN. The I/O subsystem is someone else’s concern, surfaced to you only as a metric.
Think about that. Twenty years of developed instinct — where to look, in what order, what to rule out first — becomes partially irrelevant the moment you move to managed services. Not useless. But rusty in ways you don’t notice until you need it.
That’s what I would have to relearn. Not just the individual skills — though there are plenty of those — but the posture. The reflex of reaching for the layer below the one that’s complaining. The patience for diagnostic work that doesn’t have a dashboard.
What this means for the people coming up now #
I want to be careful not to turn this into one of those “we had it harder and you’re soft” arguments, because that’s not what I believe. The cloud has genuinely improved how we build data platforms. The productivity gains are real. Managed services exist because the assembly work was often not the valuable part.
But there is a gap forming. Junior data engineers today may never have had to think about where their storage lives, how their network is segmented, or what happens to a SQL Server instance when the underlying host starts fighting for memory. They’ve inherited the model kit. They’ve never touched the Lego.
That’s not their fault. But it does mean that when the model kit behaves unexpectedly — and it will — they may not have the vocabulary to describe what’s happening, let alone diagnose it.
If I had to go back, I’d need to redevelop the muscle memory for that kind of work. The tools have changed. The diagnostic surfaces look different. But the reasoning process — systematic elimination, layer-by-layer investigation, an understanding of how components affect each other — that’s the same as it was in 2003.
I still remember how to think that way. I’m just not sure how long that would last if I never had to use it.
I said at the top that I’m not done with the Whiplash Effect. I meant it. There are at least three more angles here I want to explore — the advice-for-juniors angle, the sovereignty angle, and the “what did on-prem actually teach you that you still use” angle. Watch this space.