January 21, 2017 at 8:30 am
Old software is going to stay old software for a long time. A few lucky organisations will be able to move their applications to new software, but most places will continue to use old software until they close down and no-one want to buy the asset. It does not matter if the old software is secure or not, while it runs it will keep running.
If we think the problems of old software are bad now, we are just starting to see what will happen as IoT grows and you have some hardware device running software with little thought on how to make it secure and no ability to upgrade once it has been made. Your grandchildren will probably still see embedded XP and NetWare while they struggle to cope with certification for SQL Server 2050.
We simply have to accept that old stuff will always be around, and focus on what regulatory and business infrastructure is needed to support it.
Original author: https://github.com/SQL-FineBuild/Common/wiki/ 1-click install and best practice configuration of SQL Server 2019, 2017 2016, 2014, 2012, 2008 R2, 2008 and 2005.
When I give food to the poor they call me a saint. When I ask why they are poor they call me a communist - Archbishop Hélder Câmara
January 22, 2017 at 8:37 am
Steve Jones - SSC Editor - Thursday, January 19, 2017 9:27 PMComments posted to this topic are about the item Legacy Limits
I personally don't support any version of SQL Server older than SQL 2008 R2. However, that's not true of many all apps where I work. We have a lot of apps that use SQL 2005, even SQL 2000. There's a big push to identify everything currently running on Windows 2003 Server and older, due to the fact that support for those OS's is gone away.
Kindest Regards, Rod Connect with me on LinkedIn.
January 23, 2017 at 1:18 am
David.Poole - Friday, January 20, 2017 5:10 PMMicrosoft has to make money, the question is as to where the optimum pricing point is.In Britain there used to be a 50% tax band. It cost more to administer than the revenue it collected. There's a point where people don't put the effort into avoiding tax and beyond that point where hiring an accountant saves you more money than it costs.
The question for Microsoft is as to whether they would gain extra customers and revenue with a 4 upgrades policy or would a single big bang policy work better?
You have to factor in Azure. If you stick with the big bang then on premise SQLServer could be severely behind Azure .
As to increased cadence meaning reduced quality I'm not sure that I agree.
If you have well designed software with decent test coverage alterations are relatively painless. Last week I did four releases in one day, all successful, all adding value. The thing that made that possible was a well structured application and an ever growing test suite.People complain that they write more code for tests than they do for the application itself. That's because end users have an inate talent for discovering bizarre ways to abuse software. They can certainly find more ways to do it wrong than there are to do it right, and those oddities need testing for.
SQL Azure doesn't support half the features that SQL on premises does. For example it doesn't support SSRS, SSIS, SSAS - 3 big components. So in fact being behind all depends on what features you use.
January 23, 2017 at 1:20 am
Thom A - Friday, January 20, 2017 9:40 AMRenting software for a product like SQL could be a wonderful thing. If you look at Office 365, this is already in existence. You pay a fixed fee every month, and you get the latest copy of Office. If a new version comes out, you can download and upgrade your installed software as and when you like.I'd certainly expect, with SQL Server, that an initial fee would be required, and likely a minimum term contract, but knowing that when a new version comes out you know you will gain access to it could be a major selling point for many clients.
Except for the fact that SQL Server is nothing like Office.
Getting the latest Office usually doesn't introduce features/changes that cause existing things to break. See the new cardinality estimator introduced in SQL 2014.
January 23, 2017 at 2:29 am
peter.row - Monday, January 23, 2017 1:20 AMThom A - Friday, January 20, 2017 9:40 AMRenting software for a product like SQL could be a wonderful thing. If you look at Office 365, this is already in existence. You pay a fixed fee every month, and you get the latest copy of Office. If a new version comes out, you can download and upgrade your installed software as and when you like.I'd certainly expect, with SQL Server, that an initial fee would be required, and likely a minimum term contract, but knowing that when a new version comes out you know you will gain access to it could be a major selling point for many clients.
Except for the fact that SQL Server is nothing like Office.
Getting the latest Office usually doesn't introduce features/changes that cause existing things to break. See the new cardinality estimator introduced in SQL 2014.
I'm far from saying that you upgrade when it comes out, but that you have the option to,
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
January 23, 2017 at 2:34 am
Thom A - Monday, January 23, 2017 2:29 AMpeter.row - Monday, January 23, 2017 1:20 AMThom A - Friday, January 20, 2017 9:40 AMRenting software for a product like SQL could be a wonderful thing. If you look at Office 365, this is already in existence. You pay a fixed fee every month, and you get the latest copy of Office. If a new version comes out, you can download and upgrade your installed software as and when you like.I'd certainly expect, with SQL Server, that an initial fee would be required, and likely a minimum term contract, but knowing that when a new version comes out you know you will gain access to it could be a major selling point for many clients.
Except for the fact that SQL Server is nothing like Office.
Getting the latest Office usually doesn't introduce features/changes that cause existing things to break. See the new cardinality estimator introduced in SQL 2014.I'm far from saying that you upgrade when it comes out, but that you have the option to,
Unfortunately though that's how subscription based Office works, the updates get applied behind the scenes.
And with SQL Azure you don't really get a choice it just happens, you probably won't even know it's happened.
Hence my original reply.
January 23, 2017 at 2:44 pm
At my last job my dev team supported a Financial LOB VB5 application that used a SQL Server 6.5 database, and ran on and XP Pro machine. We had to restart the database server often.
January 25, 2017 at 8:41 am
roger.plowman - Friday, January 20, 2017 8:02 AMSQL Server should *NOT* increase its release cadence, for a few reasons.1) SMBs invest serious money in even a single copy of SQL Server. I think our copy of 2008R2 cost $11,000. Do you honestly think the PTB would be willing to spend that every 18 months? 😛 Oh, and lets not forget the greedy bean counters insisted on changing the license from per processor to per core. So new versions giving the same license cost far more!
2) Development stability. SQL Server is a *platform*. It's a complex platform with lots and lots of moving parts. Developers should be able to rely on features existing over the long term (i.e. the life of SQL Server, regardless of version). Deprecated features, changes of paradigm, these things are anathema to small development teams, much less lone wolves like me. Increased cadence increases learning time--which takes away from actual development time.
3) Increased cadence *by definition* means less time for Microsoft to test, and thus less stability. Meaning more patches. Patches, by definition, need to be released quickly. Which means less testing. Which means more patches... Blargh.
No. Increased cadence of any platform is a horrible idea. For SQL Server 24 months is bad, 18 months is crazy, and 12 months would be suicidal.
Besides, there's a name for a system that's constantly being updated: Alpha software...
This is contrary thought to the idea of DevOps, though, isn't it?
January 25, 2017 at 8:50 am
Michael J. Babcock - Wednesday, January 25, 2017 8:41 AMroger.plowman - Friday, January 20, 2017 8:02 AMSQL Server should *NOT* increase its release cadence, for a few reasons.1) SMBs invest serious money in even a single copy of SQL Server. I think our copy of 2008R2 cost $11,000. Do you honestly think the PTB would be willing to spend that every 18 months? 😛 Oh, and lets not forget the greedy bean counters insisted on changing the license from per processor to per core. So new versions giving the same license cost far more!
2) Development stability. SQL Server is a *platform*. It's a complex platform with lots and lots of moving parts. Developers should be able to rely on features existing over the long term (i.e. the life of SQL Server, regardless of version). Deprecated features, changes of paradigm, these things are anathema to small development teams, much less lone wolves like me. Increased cadence increases learning time--which takes away from actual development time.
3) Increased cadence *by definition* means less time for Microsoft to test, and thus less stability. Meaning more patches. Patches, by definition, need to be released quickly. Which means less testing. Which means more patches... Blargh.
No. Increased cadence of any platform is a horrible idea. For SQL Server 24 months is bad, 18 months is crazy, and 12 months would be suicidal.
Besides, there's a name for a system that's constantly being updated: Alpha software...
This is contrary thought to the idea of DevOps, though, isn't it?
This further helps to justify Software Assurance doesn't it? If they release a new version every 12-15 months... the question then becomes will there be enough IT folks to constantly be upgrading 24X7X365 systems..... I know we don't have enough folks and we have 125 SQL Server based systems and counting.
However, Microsoft MUST keep up with the competitors with features so I can sort of see their point. The continue to evolve Azure.
January 25, 2017 at 10:01 am
Markus - Wednesday, January 25, 2017 8:50 AMMichael J. Babcock - Wednesday, January 25, 2017 8:41 AMThis is contrary thought to the idea of DevOps, though, isn't it?This further helps to justify Software Assurance doesn't it? If they release a new version every 12-15 months... the question then becomes will there be enough IT folks to constantly be upgrading 24X7X365 systems..... I know we don't have enough folks and we have 125 SQL Server based systems and counting.
However, Microsoft MUST keep up with the competitors with features so I can sort of see their point. The continue to evolve Azure.
When I hear the term "Software Assurance" I just recall it's initial deployment/ROI was NOT good, if I'm not mistaken. M$ sold SA to folks (years ago), and they didn't deliver new versions much at all, so hence, it felt like a waste of money. Or am I mistaken?
January 25, 2017 at 10:06 am
Michael J. Babcock - Wednesday, January 25, 2017 10:01 AMMarkus - Wednesday, January 25, 2017 8:50 AMMichael J. Babcock - Wednesday, January 25, 2017 8:41 AMThis is contrary thought to the idea of DevOps, though, isn't it?This further helps to justify Software Assurance doesn't it? If they release a new version every 12-15 months... the question then becomes will there be enough IT folks to constantly be upgrading 24X7X365 systems..... I know we don't have enough folks and we have 125 SQL Server based systems and counting.
However, Microsoft MUST keep up with the competitors with features so I can sort of see their point. The continue to evolve Azure.
When I hear the term "Software Assurance" I just recall it's initial deployment/ROI was NOT good, if I'm not mistaken. M$ sold SA to folks (years ago), and they didn't deliver new versions much at all, so hence, it felt like a waste of money. Or am I mistaken?
You are correct. However, now a new version is going to come out about once a year as they say.
January 25, 2017 at 11:41 am
In the past, SA was a tough sell. 2000-2005-2008 caught many people with SA not getting upgrades or new features. With the 2 (or less) year cadence, SA makes more sense if you do try to keep up. If you don't, and I think lots of people might want 2016, but will still run older versions, then SA makes less sense.
I'm not convinced SA makes sense, even if MS releases every year. Most of my instances would stick with a version for much longer than SA timeframes.
January 25, 2017 at 11:47 am
Steve Jones - SSC Editor - Wednesday, January 25, 2017 11:41 AMIn the past, SA was a tough sell. 2000-2005-2008 caught many people with SA not getting upgrades or new features. With the 2 (or less) year cadence, SA makes more sense if you do try to keep up. If you don't, and I think lots of people might want 2016, but will still run older versions, then SA makes less sense.I'm not convinced SA makes sense, even if MS releases every year. Most of my instances would stick with a version for much longer than SA timeframes.
I agree with you Steve.
January 25, 2017 at 12:23 pm
Markus - Wednesday, January 25, 2017 11:47 AMSteve Jones - SSC Editor - Wednesday, January 25, 2017 11:41 AMIn the past, SA was a tough sell. 2000-2005-2008 caught many people with SA not getting upgrades or new features. With the 2 (or less) year cadence, SA makes more sense if you do try to keep up. If you don't, and I think lots of people might want 2016, but will still run older versions, then SA makes less sense.I'm not convinced SA makes sense, even if MS releases every year. Most of my instances would stick with a version for much longer than SA timeframes.
I agree with you Steve.
+1. I think SA was largely seen as a money-grab from MS. Most companies want stability and changing every year isn't towards that goal. A CIO told me 15 years ago: "There's a reason they call it the bleeding edge." lol
January 27, 2017 at 3:24 am
Michael J. Babcock - Wednesday, January 25, 2017 12:23 PMMarkus - Wednesday, January 25, 2017 11:47 AMSteve Jones - SSC Editor - Wednesday, January 25, 2017 11:41 AMIn the past, SA was a tough sell. 2000-2005-2008 caught many people with SA not getting upgrades or new features. With the 2 (or less) year cadence, SA makes more sense if you do try to keep up. If you don't, and I think lots of people might want 2016, but will still run older versions, then SA makes less sense.I'm not convinced SA makes sense, even if MS releases every year. Most of my instances would stick with a version for much longer than SA timeframes.
I agree with you Steve.
+1. I think SA was largely seen as a money-grab from MS. Most companies want stability and changing every year isn't towards that goal. A CIO told me 15 years ago: "There's a reason they call it the bleeding edge." lol
And software development practices have stayed the same since 2002? I don't think so.
I can understand 100% not wanting to be on the bleeding edge but being more than 1 version behind is painful, i.e. < 2014.
Since SA is optional then it's hardly a money grab - i.e. if you don't see the value you don't buy it - and you can still have it as a 1 off - so it's not like it was SA or nothing, hence not a money grab.
Viewing 15 posts - 31 through 45 (of 45 total)
You must be logged in to reply to this topic. Login to reply