January 20, 2017 at 8:02 am
SQL 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...
January 20, 2017 at 8:05 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.
Yeah, what makes SQL Azure interesting, at least from the perspective of some customers, isn't so much the cloud hosting aspect of it, but the licensing and free incremental upgrade aspect of it. Of course for on-prem versions of SQL Server it would be based more on a yearly subscription than usage. It could be the same SQL Azure product; just in the familiar on-prem data center (or closet) where they keep their existing database server located today. It is inevitable that they'll all eventually come around; perhaps when my kids start their careers in IT (wishful thinking), they'll take for granted an industry where 95% of database servers are hosted in the cloud.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 20, 2017 at 8:11 am
Gary Varga - Friday, January 20, 2017 8:02 AMpeter.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.
Actually, I was thinking that the license would be renewed yearly and perpetually (at a lower price point than the one-off purchase obviously), and upgrades would be on the same release schedule as SQL Azure. Maybe what I'm describing essentially exists in some form. If so, then Microsoft should get the word out and promote it more.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 20, 2017 at 8:11 am
Eric M Russell - Friday, January 20, 2017 8:05 AMpeter.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.
Yeah, what makes SQL Azure interesting, at least from the perspective of some customers, isn't so much the cloud hosting aspect of it, but the licensing and free incremental upgrade aspect of it. Of course for on-prem versions of SQL Server it would be based more on a yearly subscription than usage. It could be the same SQL Azure product; just in the familiar on-prem data center (or closet) where they keep their existing database server located today. It is inevitable that they'll all eventually come around; perhaps when my kids start their careers in IT (wishful thinking), they'll take for granted an industry where 95% of database servers are hosted in the cloud.
Unfortunately SQL Azure doesn't support every thing we need, like reporting services for 1. I hate SSRS but we are using it thus I need it, thus SQL Azure is not an option.
January 20, 2017 at 8:16 am
peter.row - Friday, January 20, 2017 8:11 AMEric M Russell - Friday, January 20, 2017 8:05 AMpeter.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.
Yeah, what makes SQL Azure interesting, at least from the perspective of some customers, isn't so much the cloud hosting aspect of it, but the licensing and free incremental upgrade aspect of it. Of course for on-prem versions of SQL Server it would be based more on a yearly subscription than usage. It could be the same SQL Azure product; just in the familiar on-prem data center (or closet) where they keep their existing database server located today. It is inevitable that they'll all eventually come around; perhaps when my kids start their careers in IT (wishful thinking), they'll take for granted an industry where 95% of database servers are hosted in the cloud.
Unfortunately SQL Azure doesn't support every thing we need, like reporting services for 1. I hate SSRS but we are using it thus I need it, thus SQL Azure is not an option.
That's a limitation of the cloud based Azure infrastructure. It's not a hard stop limitation; Microsoft just hasn't released the refactored Azure versions of SSIS/SSRS/SSAS yet. But if SQL Azure is hosted on-prem, installing the full stack is still an option, even if it's installing the on-prem versions of the products. I mean that technically speaking it could be done that way, if Microsoft theoretically chose to allow it like that.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 20, 2017 at 8:26 am
We have discussed this many times in the past as the new version release schedule seems to be getting shorter and shorter. I don't know how most companies will keep up. We run a mixture of versions already and have 52 production SQL Servers. We are at the tail end of upgrading one application that has it's databases in SQL 2005 which is a tiny part of the entire product. We are about 80% complete and we are at month 16 on this upgrade. It is a massive undertaking and is a very heavily used system... AND we are ONLY upgrading it to SQL 2012 because SQL 2014 wasn't yet supported by the application. This is well over a million dollar upgrade project and we are 2 versions of SQL Server old already. Our main SQL Server that runs a LOT of stuff is on 2008R2 active/passive cluster with a TON of cores. With the way Microsoft now licenses SQL Server by core I don't know how my boss is not going to flip out when I begin discussions this Summer about the cost to upgrade that one.. and that one is going to take a ton of man hours testing as it supports over 50 critical applications. The new features added to newer versions is nice, however we don't need them at all. We simply need SQL Server to run databases to query the data so new features being added isn't a selling point to our IT VP.
Today we have:
27 DBs in SQL 2005 by end of year will be zero
489 DBs in SQL 2008 and or SQL 2008R2
67 DBs in SQL 2012
130 in SQL 2014
How are all of you forum folks fairing database wise with versions?
January 20, 2017 at 9:23 am
Markus - Friday, January 20, 2017 8:26 AMWe have discussed this many times in the past as the new version release schedule seems to be getting shorter and shorter. I don't know how most companies will keep up. We run a mixture of versions already and have 52 production SQL Servers. We are at the tail end of upgrading one application that has it's databases in SQL 2005 which is a tiny part of the entire product. We are about 80% complete and we are at month 16 on this upgrade. It is a massive undertaking and is a very heavily used system... AND we are ONLY upgrading it to SQL 2012 because SQL 2014 wasn't yet supported by the application. This is well over a million dollar upgrade project and we are 2 versions of SQL Server old already. Our main SQL Server that runs a LOT of stuff is on 2008R2 active/passive cluster with a TON of cores. With the way Microsoft now licenses SQL Server by core I don't know how my boss is not going to flip out when I begin discussions this Summer about the cost to upgrade that one.. and that one is going to take a ton of man hours testing as it supports over 50 critical applications. The new features added to newer versions is nice, however we don't need them at all. We simply need SQL Server to run databases to query the data so new features being added isn't a selling point to our IT VP.Today we have:
27 DBs in SQL 2005 by end of year will be zero
489 DBs in SQL 2008 and or SQL 2008R2
67 DBs in SQL 2012
130 in SQL 2014How are all of you forum folks fairing database wise with versions?
Excluding system / utility databases, and ignoring SQLExpress stuff (eg backupexec):
Plus a few in SQL7, 2000. Nothing in production in SQL2016, though. Not yet... though I did hear a rumour that we may be getting some soon... 😀
Thomas Rushton
blog: https://thelonedba.wordpress.com
January 20, 2017 at 9:40 am
Renting 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.
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
January 20, 2017 at 10:01 am
roger.plowman - Friday, January 20, 2017 8:02 AM...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...
I must respectfully disagree. For an agile and lean development team it is never alpha software that is released. It is always production quality.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
January 20, 2017 at 10:18 am
Gary Varga - Friday, January 20, 2017 10:01 AMroger.plowman - Friday, January 20, 2017 8:02 AM...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...
I must respectfully disagree. For an agile and lean development team it is never alpha software that is released. It is always production quality.
I would disagree as well. Lean organizations that respond to changing conditions, fix issues and alter the way the code works when it needs it are a better way to increase quality.
If only new features are added and old ones not fixed/improved, then that's a separate issue, but has nothing to do with pace.
January 20, 2017 at 10:49 am
Steve Jones - SSC Editor - Thursday, January 19, 2017 9:27 PMComments posted to this topic are about the item Legacy Limits
Steve, while a lot of points were brought up, a simple fact gets overlooked. This is customer service and so the bottom line is to provide the customer what they want at a reasonable cost. Everything else is just hurdles to providing it and the less the customer has to be involved beyond payment the happier they are.
January 20, 2017 at 12:40 pm
We just started migrating from 2008 to 2014 this past summer and we're still working on getting everyone moved over. I can't imagine how well we'd do if we had to upgrade every year, short of having a dedicated team to doing just upgrades. This particular upgrade may just be particularly onerous, though. We found that there were some serious issues with some stored procedures and the new cardinality estimator in 2014 that slowed the upgrade process down until we identified and fixed them.
January 20, 2017 at 1:57 pm
huckleseed - Friday, January 20, 2017 10:49 AMSteve Jones - SSC Editor - Thursday, January 19, 2017 9:27 PMComments posted to this topic are about the item Legacy LimitsSteve, while a lot of points were brought up, a simple fact gets overlooked. This is customer service and so the bottom line is to provide the customer what they want at a reasonable cost. Everything else is just hurdles to providing it and the less the customer has to be involved beyond payment the happier they are.
You hit it right on the nose.
January 20, 2017 at 3:15 pm
huckleseed - Friday, January 20, 2017 10:49 AMSteve Jones - SSC Editor - Thursday, January 19, 2017 9:27 PMComments posted to this topic are about the item Legacy LimitsSteve, while a lot of points were brought up, a simple fact gets overlooked. This is customer service and so the bottom line is to provide the customer what they want at a reasonable cost. Everything else is just hurdles to providing it and the less the customer has to be involved beyond payment the happier they are.
Great points
January 20, 2017 at 5:10 pm
Microsoft 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.
Viewing 15 posts - 16 through 30 (of 45 total)
You must be logged in to reply to this topic. Login to reply