It’s the second tuesday of the month, which means T-SQL Tuesday time! This month’s topic is chosen by myself, and it’s inspired by a blog post of Alexander Arvidsson. In a nutshell, I’m asking what we would do if we need to move our data platforms back to on-prem, after a good decade of cloud computing. What would we – for example – teach our junior colleagues, since they “grew up” with cloud, serverless, SaaS and other shenanigans.
I’d tell my junior peers that if something breaks, or if performance is slow, it might not just be your code. There are so many other factors that come into play when working on-premises (and when you essentially manage the whole stack). Of course, check the code first 
It might be a slow SAN. Or it might be DNS (it’s probably DNS). Or maybe the anti-virus has kicked in and it has locked some crucial files. Or someone configured the server (or didn’t change the default) to be in energy-saving mode. Or perhaps the NIC (the network interface card for the young people among us) has intermittent issues (it took me a long while to figure that one out. It caused a SQL Server Agent job running an SSIS package to fail occasionally, about once or twice a week). Or, for the old-timers, maybe it’s a 32-bit issue, or the wrong drivers are installed.
You get the gist, so many things can go wrong (and will go wrong). Alexander has a good point in his blog post: we used to deal with so many variables, and maybe we have lost some of those skills along the way. Maybe we’ve gone a bit “lazy”. But, silver lining, since LLMs are trained on all the Internet content, we can ask it questions that were solved in those old forums a long time ago…
The post T-SQL Tuesday #199: Back to the on-prem first appeared on Under the kover of business intelligence.