October 8, 2014 at 8:37 pm
Comments posted to this topic are about the item Continuous Delivery for Windows?
October 9, 2014 at 12:42 am
As someone who accepts all patches as soon as they are available, it sounds good to me.
As someone who relies on DBAs testing patches before releasing them into live, a am a little nervous about this.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
October 9, 2014 at 6:24 am
An already very complex OS would become far more complex to manage, if patches were written for specific configurations. The possible variations would explode, along with the testing required. Nice idea, for sure, and maybe some clever person can figure out how to deploy continuous delivery.
For the production environment though, I'm far more interested in a stable platform. Unnecessary "feature" updates are undesirable. At best, the platform remains as it was before the update (i.e. working). It can only go downhill from that starting point.
October 9, 2014 at 7:04 am
The configuration-specific scenario sounds a bit complex to manage. I do like the quick fix model. I've always hated having to sit on a fix, knowing that more and more data is getting messed up, while my fix goes through that long process of testing. But I also realize those little tweaks to code can sometimes introduce horrendous problems. Still I vote for the quicker release.
October 9, 2014 at 7:06 am
For nearly two decades now I wanted Windows features to be advertised by an API. I don't want to check the version of Windows to assume that an API is available. I want to call an API to see if API X is installed. That way I can verify application/service requirements on launch (services would have to subscribe for notifications of API installs/uninstalls as they are longer running, perhaps Apps too).
This would allow for installations of stripped back Windows. No API X available? That's OK we checked and took our designed option (which could have been application termination, service suspension, reduced processing, etc.). This should be an OS framework that systems and applications can utilise i.e. is SSIS installed, let's just check as MS SQL Server integrates with the Feature API!!!
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
October 9, 2014 at 7:23 am
I already run several systems, (Linux), that can use continuous Delivery through package managers, plus utilize a large software ecosystem (Anaconda/Python) that can use the same.
It's all fine until someone decides to make changes to your networking that causes issues or not update a component because they chose not to support it anymore. You still need to test and evaluate every single change or just blindly trust others.
The nice thing is that there are tools that allow you to chose exactly what you want to use and the dependencies.
October 9, 2014 at 7:24 am
We've already seen SQL Server move to a pace that releases new versions every two years and bimonthly patches to fix issues. Imagine that we could get patches even more often, as bugs are fixed.
I'm not the sysadmin side of things, so I'm not sure, but does applying a SQL Server patch typically require a restart of the service? If so, then that would be inconvenient if it occurred every couple of weeks, especially for a standalone non-clustered instance.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
October 9, 2014 at 7:27 am
Steve Jones - SSC Editor (10/8/2014)
Comments posted to this topic are about the item <A HREF="/articles/Editorial/116864/">Continuous Delivery for Windows?</A>
IMO Microsoft didn't go to a two year release cycle with SQL to improve the product - they did it to improve revenue. Since they only support the last couple releases of an OS, more frequent OS releases would benefit nobody but Microsoft and their shareholders, while costing business huge amounts of money for no return on investment.
For those who disagree, I have one word for you. Remembers Windows 98, ME, Vista and Windows 8. 8 is so bad they skipped 9.
OK, maybe more than one word... 🙂
Businesses aren't in business to purchase Microsoft products. They are in business to sell cars, electronics, food, et cetera. Spending millions to replace an OS that works perfectly well simply because Microsoft wasn't satisfied with the transition to a newer version, does NOT benefit those businesses.
All that said, if they are changing their process in order to deliver a product that actually works correctly, isn't riddled with security flaws, and doesn't force Microsoft's vision down the consumer's throats, maybe there will be some positive there.
In the meantime, Linux and other open source products are going to continue gaining market share.
Dave
October 9, 2014 at 7:44 am
IMO Microsoft didn't go to a two year release cycle with SQL to improve the product - they did it to improve revenue.
Bingo!
That's why we still have happy clients running SQL Server 2005, 2008, 2008R2, etc... They don't need the new features nor the much larger license costs.
October 9, 2014 at 7:52 am
chrisn-585491 (10/9/2014)
IMO Microsoft didn't go to a two year release cycle with SQL to improve the product - they did it to improve revenue.
Bingo!
That's why we still have happy clients running SQL Server 2005, 2008, 2008R2, etc... They don't need the new features nor the much larger license costs.
I think you have a type or misspelling. Did you really mean:
They don't need the new features nor the significantly vast, horrendously wasteful, totally inappropriate, designed to make people think SQL Server is as good as Oracle, larger license costs.
I do like some of the newer features, but I have a major issue with a business model of getting your customers tied to your product, and then forcing them to pay more money because they can't change.
Dave
October 9, 2014 at 8:02 am
djackson 22568 (10/9/2014)
chrisn-585491 (10/9/2014)
IMO Microsoft didn't go to a two year release cycle with SQL to improve the product - they did it to improve revenue.
Bingo!
That's why we still have happy clients running SQL Server 2005, 2008, 2008R2, etc... They don't need the new features nor the much larger license costs.
I think you have a type or misspelling. Did you really mean:
They don't need the new features nor the significantly vast, horrendously wasteful, totally inappropriate, designed to make people think SQL Server is as good as Oracle, larger license costs.
I do like some of the newer features, but I have a major issue with a business model of getting your customers tied to your product, and then forcing them to pay more money because they can't change.
I think that you guys have simplified it a little too much. The product team would have been eager for a more rapid delivery of fixes and improvements. The business development and marketing teams would have been ensuring that the more rapid deliveries were packaged as more frequent new versions and that the licensing was changed.
I don't believe for one minute that this was a push from marketing nor for another minute that marketing didn't see an opportunity and jumped on it.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
October 9, 2014 at 8:14 am
Gary Varga (10/9/2014)
djackson 22568 (10/9/2014)
chrisn-585491 (10/9/2014)
IMO Microsoft didn't go to a two year release cycle with SQL to improve the product - they did it to improve revenue.
Bingo!
That's why we still have happy clients running SQL Server 2005, 2008, 2008R2, etc... They don't need the new features nor the much larger license costs.
I think you have a type or misspelling. Did you really mean:
They don't need the new features nor the significantly vast, horrendously wasteful, totally inappropriate, designed to make people think SQL Server is as good as Oracle, larger license costs.
I do like some of the newer features, but I have a major issue with a business model of getting your customers tied to your product, and then forcing them to pay more money because they can't change.
I won't argue that at all. You are breaking it down by business unit, whereas I am just looking at the corporation as a whole. We all know developers and database people are awesome "guys and gals" that focus on quality and features, and aren't worried about profit as their main motive... 🙂
I think that you guys have simplified it a little too much. The product team would have been eager for a more rapid delivery of fixes and improvements. The business development and marketing teams would have been ensuring that the more rapid deliveries were packaged as more frequent new versions and that the licensing was changed.
I don't believe for one minute that this was a push from marketing nor for another minute that marketing didn't see an opportunity and jumped on it.
Dave
October 9, 2014 at 9:17 am
My point is that I believe that the continuous delivery of SQL Server, or something approaching it, was coming regardless of any licensing or cost changes.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
October 9, 2014 at 9:50 am
Gary Varga (10/9/2014)
My point is that I believe that the continuous delivery of SQL Server, or something approaching it, was coming regardless of any licensing or cost changes.
I think you have a valid point. The new delivery approach is the next logical step, and not a marketing deal.
Marketing will roll additional cost into the license for each major release of the product.
Not all gray hairs are Dinosaurs!
October 10, 2014 at 6:50 am
Gary Varga (10/9/2014)
As someone who accepts all patches as soon as they are available, it sounds good to me.As someone who relies on DBAs testing patches before releasing them into live, a am a little nervous about this.
Yikes! I need your blog or twitter. I rarely accept anything until it's been tested by people like you for at least a few weeks.
Viewing 15 posts - 1 through 15 (of 23 total)
You must be logged in to reply to this topic. Login to reply