February 11, 2020 at 12:00 am
Comments posted to this topic are about the item Good Luck is Needed with Old Versions
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 11, 2020 at 3:17 am
I agree with everything you said but, with all the really cool stuff that's been built into SQL Server in the last 8 years, couldn't you have cited a better reason to upgrade other than XE? Sheesh!
--Jeff Moden
Change is inevitable... Change for the better is not.
February 11, 2020 at 8:35 am
I know of a company that paid an astronomic sum to keep a warehouse distribution system supported on obsolete hardware and a long obsolete version of the software.
They had a 24 hour dispatch promise to their customers or the customer got the goods for free.
When it went pop they discovered that the company to whom they were paying a huge amount of support hadn't got a clue. They had no-one who had experienced tech that old.
February 11, 2020 at 11:42 am
I'm currently doing the last bits & pieces of a DWH Upgrade / Replacement to 2017 and I already am screaming for SQL Server 2019 (MDS learns how to HTML5 instead of Silverlight, woah!). It's not that my Supervisor or the Head of IT don't want to let me upgrade but rather that SQL Server 2019 hasn't been validated yet within this organization and therefore we're stuck with upgrading to 2017.
February 11, 2020 at 11:54 am
I agree with everything you said but, with all the really cool stuff that's been built into SQL Server in the last 8 years, couldn't you have cited a better reason to upgrade other than XE? Sheesh!
Honestly, I'm not sure how that slipped in. I think it was a brain fart, not my point at all. Apologies.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 11, 2020 at 11:57 am
I know of a company that paid an astronomic sum to keep a warehouse distribution system supported on obsolete hardware and a long obsolete version of the software.
They had a 24 hour dispatch promise to their customers or the customer got the goods for free.
When it went pop they discovered that the company to whom they were paying a huge amount of support hadn't got a clue. They had no-one who had experienced tech that old.
I recall my former employer did have to push people to support insanely older systems. It was an exercise in frustration for all involved.
It's like how I'm always trying to push people to adopt a DevOps-style of development and deployment, lots of communication, automation, tearing down unnecessary barriers, etc. The issue is, people are used to the pain that they have. New things involve new pain and new pain hurts worse than the old pain, no matter how bad that pain is. It's pain you're used to.
So, organizations will pay more to keep the old tech in place than it would cost to upgrade. I've seen it a bunch. It's hard.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 11, 2020 at 11:58 am
I'm currently doing the last bits & pieces of a DWH Upgrade / Replacement to 2017 and I already am screaming for SQL Server 2019 (MDS learns how to HTML5 instead of Silverlight, woah!). It's not that my Supervisor or the Head of IT don't want to let me upgrade but rather that SQL Server 2019 hasn't been validated yet within this organization and therefore we're stuck with upgrading to 2017.
Yikes. I've had run-ins with those types of approval groups. I even tell part of the story in the 2020 State of Database DevOps report. They can make things difficult.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 11, 2020 at 1:59 pm
While I completely agree that a controlled upgrade path is absolutely valid for service machines, where I work we produce software dependent upon older environments for builds. These are virtual machines that are spun up at build time and deleted upon completion of the build, so are not nearly as subject to security problems (security by obscurity - the machine only exists for an hour before being destroyed) and there is far less likelihood that the virtualization software will break the VM's compatibility. We have some Linux VMs using RedHat FC3, a few even older, and more than one build needs Windows XP CE. Since I work in gaming (video slot machines/poker/lottery) our target deployment hardware is relatively static but also pretty finicky, so we're stuck in this ancient OS hell....
There are use cases - but generally it's wiser to keep things up to date.
February 11, 2020 at 2:12 pm
Oh, Grant, I am so envious of your career!! My career has practically been the opposite. In the 90's I worked for an organization that did soil and biological testing. They used equipment that printed results on very specialized thermal paper. This equipment was very old, not network capable. So, what technicians had to do was print the results on the thermal paper and then double enter it into either some custom program or an Excel spreadsheet. The company that manufactured this specialized equipment went out of business. Because of that the company the produced the thermal paper stopped manufacturing that. Rather than change equipment and use something new, the organization I worked for opted to buy the world's remaining supply of that specialized thermal paper, rather than work on replacing it. I and others were ready, willing and able to get new equipment and write the software (if necessary) to work with it. Nope, just buy the remaining world's supply of this specialized thermal paper and kick the can down the road. I left that organization shortly after that.
Years later I rejoined that organization, working in a different department. But I could see that the organization's habit of never upgrading anything, unless forced to, was still very much in effect. I can think of at least half a dozen examples of this organization's tendency to put things off until after the last minute has passed, but will related one. I was put onto a project to try and get data out of a really old data store that I had no experience with. I wasn't even sure what sort of database it was. And no one else knew either. The app that users use was originally written back in the early 2000's, by the Center for Disease Control (CDC). I contacted them and learned that even they didn't have anyone who knew the system, database, etc. (I get the impression that the CDC doesn't have the source code, either.) So, in this particular case because the organization had waited so long, it became impossible to do anything more with it. I'm not saying that organization has done the delay game for all things, but they have for some.
Now, Grant, to answer your question ("Tell me why rolling the dice and planning on good luck is the more sensible approach?"), my answer is only one thing; budget. Nothing else matters. They ask themselves, "Can we afford it now?" If the answer is no, then they kick the can down the road. It becomes a habit to kick the can down the road year after year.
Rod
February 11, 2020 at 2:14 pm
While I completely agree that a controlled upgrade path is absolutely valid for service machines, where I work we produce software dependent upon older environments for builds. These are virtual machines that are spun up at build time and deleted upon completion of the build, so are not nearly as subject to security problems (security by obscurity - the machine only exists for an hour before being destroyed) and there is far less likelihood that the virtualization software will break the VM's compatibility. We have some Linux VMs using RedHat FC3, a few even older, and more than one build needs Windows XP CE. Since I work in gaming (video slot machines/poker/lottery) our target deployment hardware is relatively static but also pretty finicky, so we're stuck in this ancient OS hell....
There are use cases - but generally it's wiser to keep things up to date.
Sure. There are always exceptions. However, exceptions should be exceptional. I will frequently see people take some exception, like yours, and then extend it into areas where it's just not applicable.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 11, 2020 at 2:18 pm
Now, Grant, to answer your question ("Tell me why rolling the dice and planning on good luck is the more sensible approach?"), my answer is only one thing; budget. Nothing else matters. They ask themselves, "Can we afford it now?" If the answer is no, then they kick the can down the road. It becomes a habit to kick the can down the road year after year.
Yikes. To the whole thing.
This answer though only works to a degree. I think it's still more a resistance to the pain of change as opposed to a cost/benefit analysis. Where we were keeping the machine alive through purchases on EBay, we knew it was costing more than a replacement. We just couldn't get the political capital together to champion the change. So, they kept spending more money. Technology is hard, and that's why I love it so.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 11, 2020 at 2:25 pm
I joined an IT operations department in 2013. At the time, they were all on 2008 R2. I warned them at the time that they should begin upgrading immediately. They ignored me because of "budget". I left in 2017.
Flash forward to summer, 2019, end of life for 2008 R2. They were told by corporate IT to upgrade or lose access to their databases. They went through a massive upgrade effort, suffering significant outages. Afterward, the VP of the department was fired. The department was dismantled with significant layoffs. All of their IT resources were transferred to corporate.
The cost to upgrade goes up the longer it is put off. Ignore advice to upgrade at your peril. I have seen entire departments evaporate because of this.
February 11, 2020 at 2:42 pm
I joined an IT operations department in 2013. At the time, they were all on 2008 R2. I warned them at the time that they should begin upgrading immediately. They ignored me because of "budget". I left in 2017.
Flash forward to summer, 2019, end of life for 2008 R2. They were told by corporate IT to upgrade or lose access to their databases. They went through a massive upgrade effort, suffering significant outages. Afterward, the VP of the department was fired. The department was dismantled with significant layoffs. All of their IT resources were transferred to corporate.
The cost to upgrade goes up the longer it is put off. Ignore advice to upgrade at your peril. I have seen entire departments evaporate because of this.
Stories like this happen all the time. Yet, people still make the choices they make. Servers still get installed without passwords. SQL Injection is still a thing. Backups? What are those? On & on. Some days, it gets a little depressing.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
February 11, 2020 at 3:32 pm
I think most of the time it is a belief that they are saving money. Sometimes it is fear driven. I really can't count the number of times I have seen a huge amount of concern that a particular database wouldn't function correctly on a newer version of SQL Server. And I wouldn't say that such could never happen. But I can say I have yet to see a single hiccup that didn't trace to a backup which wouldn't have worked to the original server anyway. Then again, I spend the vast majority of my time in development.
Here is the question that I wonder - how does it make sense to risk one's livelihood working for a company that doesn't upgrade?
Viewing 15 posts - 1 through 15 (of 25 total)
You must be logged in to reply to this topic. Login to reply