January 19, 2017 at 9:27 pm
Comments posted to this topic are about the item Legacy Limits
January 20, 2017 at 2:15 am
I'm a developer of a system that uses SQL Server currently we are tied to SQL 2008R2 but hopefully we will push past that with only a couple of customers on that version. All our other customers we host and our host is on SQL 2014.
The problem I'd say is unless you are a multi-national company it's very hard to support lots of different versions of your product. For example we can't use SQL Servers paging window functions introduced in SQL 2012 because it is too much effort - time/money to maintain the system working both with and without that syntax.
Even a massive company such as Microsoft is moving away from this - see Windows 10, because it is hard to do. If a massive company like that can't do it any more what hope has small (by comparison, i.e. < 250 employees) companies got?
The problem in bespoke/narrow scope software/products as I see it is that customers don't want to pay to upgrade, but if you keep going and release new versions as the editorial suggests they'll soon come crying when they run into a bug that you fixed 3 versions after the version they are on, you can't easily backport it because 2 versions after the one they are on you did some much needed refactoring. Remember when under pressure from customers and bosses for features to be done now, now, now you're never going to get the best solution, just a working solution - that is why refactoring is needed. Software is never complete.
For all sorts of political reasons just letting someone else effectively fork your product and do fixes is not an option. Imagine if Bobs software co' were to fork Word 2000 from MS. They release some patches, it screws something up such that when user actually does upgrade to Word 2016 and opens a precious, to them, document it gets corrupted - who do you think they are going to scream and shout at and bad mouth all over the internet - Bobs software co' or Microsoft - if you think Bobs software co' you are very naïve.
January 20, 2017 at 2:52 am
Security is a concern for older platforms. Data is gaining ever more prominence and it only takes one breach and regulatory fine to wipe out any saving you may have made by not upgrading.
If it is possible to script an entire install of the legacy software so that you can spin up and environment in under 5 minutes then at least the stuff is maintainable. As far as I am aware it is possible to do this for SQL2005 and onwards.
The ability to make the legacy software testable is also something that enhances the maintainability and longevity of software. If the legacy software is well designed then automated testing is feasible. If your legacy software is a big ball of mud and has become legacy because no one dares to touch it then it is a ticking timebomb.
In terms of upping the cadence of SQL Server release cycles I think there needs to be a rethink on marketing vs technical release concerns. A major version every two years feels about right. Feature releases more frequently would be handy. Perhaps the licencing of the product should be geared around the expectation of 4 feature releases included in the licence. That gives the message to customers that they are getting value for money and that the platform that they have invested in is progressing forwards at a rate of knots. That should make the financial hit of upgrading to a major release much more palatable.
I would feel happy with a SQL2016R2, R3 and R4 followed by a big bang for SQL2018 or 2019.<br
January 20, 2017 at 2:52 am
Steve Jones - SSC Editor - Thursday, January 19, 2017 9:27 PMComments posted to this topic are about the item Legacy Limits
Do not forget that money makes the music - business is paying developers.Does not matter what developer wants.
It does matter what the business wants. If I ,as a developer, could justify to the business that is some value in upgrade / re-architecture , the business will give me the money . If not, not.
Andrei Ignat
.NET Teacher | .NET Videos 5 minutes
January 20, 2017 at 4:30 am
In my company we implement not just software developed by ourselves, but also third-party vendors.
Some systems are sold with licensing and support agreements that are only valid unless the specified O/S and database versions are installed.
These agreements generally allow the client to upgrade to newer versions for 'free'.
Unfortunately, support agreements are not always renewed and soon you sit with legacy systems.
Sometimes the regulatory processes also prevents frequent upgrades.
In the pharmaceutical industry, for example, FDA 21 CFR Part 11 and other validation/quality/safety regulations make upgrades very costly.
Then there are budgets, Capex and other production constraints to complicate things.
Virtualization also allows these legacy systems to basically run forever.
Not all industries or business units within companies are suitable for cloud-based databases.
Yes, all DBA's, engineers and developers would like to work with the latest and greatest systems.
But in the real world, money talks.
Just for the record:
Last year we virtualized a system consisting of 3 servers running on Windows Server 2003 Standard SP2 (32 bit).
SQL Server 2005 SP2 (32 bit) is running on two of the servers, including a Reporting Services instance.
I can guarantee you that it will still be running in 10 years’ time!
January 20, 2017 at 4:53 am
I *dream* of only having to support as far back as SQL2005... My normal support scripts & monitoring techniques are crippled by the lack of DMVs in SQL 2000 (and SQL2005RTM doesn't understand OBJECT_SCHEMA_NAME, and stuff before SQL2008R2RTM doesn't have the sys.dm_server_services); Still, at least we don't have anything earlier than that...
...Oh, wait. We do. Damn.
Mind you, it's not just the different versions of SQL (by which I mean SQL 2008R2, SQL2012, etc) but the different SP / CU levels. These are often mandated by the software suppliers - "thou shalt only run this software on at the latest SQL2005SP3, because we haven't tested it on anything later" - and (from previous places) the integration partners / software suppliers being unwilling to take on the challenges of migrating environments that have been heavily customised over the years since original implementation (which itself involved some heavy customisation work *that they did*).
Thomas Rushton
blog: https://thelonedba.wordpress.com
January 20, 2017 at 5:23 am
One of the issues with an upgrade policy and matching pricing strategy is highlighted by this forum: so many different requirements from different clients. For SQL Server Microsoft has to try and please as many clients as possible whilst maximising profitability.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
January 20, 2017 at 6:24 am
As a life-long tech geek, I like new and improved things. I love the fast hardware and virtualization that today offers.
But as a mature nerd I realize that there's a finite amount of resources. It would be awesome if every database was on SQL Server 2014 or greater. And if operating systems were written in Ada by the same programmers that write critical code for NASA. And recruiters could understand the difference between Java and JavaScript.
But it's not going to happen Anytime Real Soon.
January 20, 2017 at 6:40 am
I would just throw my hands up if MS starts releasing versions of SQL Server at a more rapid pace. That would just mean there'd that much more real world knowledge I'd be lacking.
January 20, 2017 at 7:31 am
David.Poole - Friday, January 20, 2017 2:52 AMSecurity is a concern for older platforms. Data is gaining ever more prominence and it only takes one breach and regulatory fine to wipe out any saving you may have made by not upgrading.If it is possible to script an entire install of the legacy software so that you can spin up and environment in under 5 minutes then at least the stuff is maintainable. As far as I am aware it is possible to do this for SQL2005 and onwards.
The ability to make the legacy software testable is also something that enhances the maintainability and longevity of software. If the legacy software is well designed then automated testing is feasible. If your legacy software is a big ball of mud and has become legacy because no one dares to touch it then it is a ticking timebomb.In terms of upping the cadence of SQL Server release cycles I think there needs to be a rethink on marketing vs technical release concerns. A major version every two years feels about right. Feature releases more frequently would be handy. Perhaps the licencing of the product should be geared around the expectation of 4 feature releases included in the licence. That gives the message to customers that they are getting value for money and that the platform that they have invested in is progressing forwards at a rate of knots. That should make the financial hit of upgrading to a major release much more palatable.
I would feel happy with a SQL2016R2, R3 and R4 followed by a big bang for SQL2018 or 2019.
I like the idea of including a few versions in the cost. In fact, I almost wish that were some sort of regulatory item, perhaps requiring backporting or upgrades since the idea of selling software that has issues, constantly releasing new versions but not necessarily fixing old ones, feels a bit like a scam.
January 20, 2017 at 7:40 am
jwilsonDBA - Friday, January 20, 2017 6:40 AMI would just throw my hands up if MS starts releasing versions of SQL Server at a more rapid pace. That would just mean there'd that much more real world knowledge I'd be lacking.
Put them up. We're going to see changes in Azure every quarter, and some people will use that. I suspect that we could get down to on-premise every 12 months, but my guess would be with the marketing effort and hassles, we won't practically be less than every 18 months. Could be wrong. We'll see.
January 20, 2017 at 7:44 am
jwilsonDBA - Friday, January 20, 2017 6:40 AMI would just throw my hands up if MS starts releasing versions of SQL Server at a more rapid pace. That would just mean there'd that much more real world knowledge I'd be lacking.
Unless you've had the Enterprise version and a need to use the latest features, most folks don't dwell on the latest features outside the hardcore and the bloggers.
Now that 2016 has bought more of the features down to us mere mortals, it may be worth a look for security or performance or easy of management sake. But the core of the product is still the same.
January 20, 2017 at 7:52 am
With the current pace of innovation, it seems to me that it just doesn't make sense anymore for organizations to consider their purchase of SQL Server Enterprise and Standard Edition as a big one-off capitalizable expense that they sit on for several years. However, expecting most of these legacy SQL Server users to move to SQL Azure just for the usage based and subscription based licensing model is perhaps asking too much of them in terms of adjusting to a new cloud hosted paradigm. Perhaps it would be in the best interest of Microsoft, it's customers (and it's DBAs), if Microsoft moved to a yearly subscription based licensing model, more similar to MSDN, for on-prem SQL Server, and then also make the option retroactive to cover existing installations of 2000 - 2016. That would allow current users of SQL Server 2008 could upgrade to 2016 at a fraction of the cost and just start on the yearly license model.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 20, 2017 at 7:58 am
Eric M Russell - Friday, January 20, 2017 7:52 AMWith the current pace of innovation, it seems to me that it just doesn't make sense anymore for organizations to consider their purchase of SQL Server Enterprise and Standard Edition as a big one-off capitalizable expense that they sit on for several years. However, expecting most of these legacy SQL Server users to move to SQL Azure just for the usage based and subscription based licensing model is perhaps asking too much of them in terms of adjusting to a new cloud hosted paradigm. Perhaps it would be in the best interest of Microsoft, it's customers (and it's DBAs), if Microsoft moved to a yearly subscription based licensing model, more similar to MSDN, for on-prem SQL Server, and then also make the option retroactive to cover existing installations of 2000 - 2016. That would allow current users of SQL Server 2008 could upgrade to 2016 at a fraction of the cost and just start on the yearly license model.
I would love this - typically we get stuck having to support older SQL Servers merely because that was the current release when we released the software. If they did your yearly subscription idea to lower the cost then there would be no excuse, although they'd have to significantly lower the price.
January 20, 2017 at 8:02 am
peter.row - Friday, January 20, 2017 7:58 AMEric M Russell - Friday, January 20, 2017 7:52 AMWith the current pace of innovation, it seems to me that it just doesn't make sense anymore for organizations to consider their purchase of SQL Server Enterprise and Standard Edition as a big one-off capitalizable expense that they sit on for several years. However, expecting most of these legacy SQL Server users to move to SQL Azure just for the usage based and subscription based licensing model is perhaps asking too much of them in terms of adjusting to a new cloud hosted paradigm. Perhaps it would be in the best interest of Microsoft, it's customers (and it's DBAs), if Microsoft moved to a yearly subscription based licensing model, more similar to MSDN, for on-prem SQL Server, and then also make the option retroactive to cover existing installations of 2000 - 2016. That would allow current users of SQL Server 2008 could upgrade to 2016 at a fraction of the cost and just start on the yearly license model.I would love this - typically we get stuck having to support older SQL Servers merely because that was the current release when we released the software. If they did your yearly subscription idea to lower the cost then there would be no excuse, although they'd have to significantly lower the price.
Perhaps the license should include X number of years upgrades included automatically.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 15 posts - 1 through 15 (of 45 total)
You must be logged in to reply to this topic. Login to reply