Using new server OS upon release
-
Now if you are talking a truly new product, like when Microsoft moved from DOS/Windows to Windows NT and there was no shared code or development at the core level, yes I would agree that being an early adopter is dangerous and potentially expensive. Although in that particular case Windows NT was already pretty mature having been renamed from IBM OS/2 which had proven itself already to be incredibly stable and capable. So even that is a difficult case. The better one would have been moving from DOS to OS/2 around 1990. That first release of OS/2 was a big leap of faith. But it ended up becoming the OS that everyone just calls Windows today.
The introduction of truly new OSes is almost unheard of. No major OS has come out new in decades. OS/2 / Windows NT was around 1990. Linux was around 1991. FreeBSD is similar, maybe 1994. Even if you consider Mac OSX to be completely new rather than an incremental change to FreeBSD, it was 2000, fifteen years ago. Most niche systems that people still use here and there like AIX, Solaris, VMS, HP-UX are older, not newer.
So, essentially, in any discussion about new OS deployments, we are talking about very venerable products with huge histories and massive technology backing and really strong testing chains being out small updates.
Even moves between Windows NT versions (like from the 5.x family to the 6.x family) are relatively minor and should cause little concern. And moves in the RHEL family from say RHEL 6 to RHEL 7 are tiny and don't include a major kernel upgrade between them. So even "major" updates tend to be relatively minor.
-
Application support is probably one of the biggest issues yo deal with. Though now that we are years past the x64 conversion, I tend to agree that most of those problems are behind us.
Speaking more on the desktop side, drivers from vista often work in Windows 8/8.1 in the x86 space, and really only several years after windows 7's x64 release did we see broad x64 support that appears to still be working.
-
If it is an application server then I would wait until the application vendor has qualified their software against the new OS. Depending on the vendor, this may be some time after the OS is released.
-
@scottalanmiller said:
And moves in the RHEL family from say RHEL 6 to RHEL 7 are tiny and don't include a major kernel upgrade between them. So even "major" updates tend to be relatively minor.
I find this to be especially true in the Linux world... I started with Ubuntu 8.04 on my office machine and ran that all the way up through the iterative upgrades to v10.10 (before I lost a hard drive). The upgrades never gave me a lick of problem. At my current job, I am running on a machine that started as SuSE 9.x and it is now SuSE 11.x SP3... Again, no problems.
I have never had a successful Windows upgrade without some form of issues (major or minor)...and usually wind up having to Wipe & Reload the machine with the new OS anyhow.
-
@Dashrender said:
Application support is probably one of the biggest issues yo deal with. Though now that we are years past the x64 conversion, I tend to agree that most of those problems are behind us.
And that was an architectural change, not an OS one. You still have these issues when moving between architectures regardless of OS age. If you move between ARM, AMD64, Power and Sparc you need to deal with serious compatibility concerns.
-
@Dashrender said:
Speaking more on the desktop side, drivers from vista often work in Windows 8/8.1 in the x86 space, and really only several years after windows 7's x64 release did we see broad x64 support that appears to still be working.
These are issues dealt with easily with very little testing. And even better when you consider that in the modern age, all drivers should be virtualized and therefore no longer even drivers are a concern. What OS doesn't support all four platforms, HyperV, Xen, KVM and VMware, at the time of release?
-
@Carnival-Boy said:
If it is an application server then I would wait until the application vendor has qualified their software against the new OS. Depending on the vendor, this may be some time after the OS is released.
That's a non-technical issue and very important. If politics, support agreements, licensing, cost and other "non-technical" issues dictate that you can't update, by all means yes you stay behind. But it is important to recognize that it is because of a license or support or whatever, not because the OS isn't capable of being reliable.
-
@dafyre said:
I have never had a successful Windows upgrade without some form of issues (major or minor)...and usually wind up having to Wipe & Reload the machine with the new OS anyhow.
I should also point out, upgrades and fresh deployments are different things. There are plenty of times you would choose not to upgrade a running system. We are talking about "at the time of an OS deployment" do you choose to deploy what is current or you do you intentionally deploy something old that is not the current release.
-
I will do current release unless I have specific reasons not to. (Lack of Driver Support, or as @Carnival-Boy mentioned, applicatoin vendors not being current.
-
@scottalanmiller said:
@Carnival-Boy said:
If it is an application server then I would wait until the application vendor has qualified their software against the new OS. Depending on the vendor, this may be some time after the OS is released.
That's a non-technical issue and very important. If politics, support agreements, licensing, cost and other "non-technical" issues dictate that you can't update, by all means yes you stay behind. But it is important to recognize that it is because of a license or support or whatever, not because the OS isn't capable of being reliable.
I wouldn't say it's non-technical. Qualification involves a vendor testing their application on a new OS to ensure that it doesn't have any issues, prior to telling their users it is ok. That's a technical process.
At the same time, I would generally always install an application on the latest vendor qualified OS. So if my application vendor says their application is qualified for Windows 10 I would install it on Windows 10 even if it had only just been released.
So the vendor dictates which OS I use more than me.
But really, Windows Server is so mature now that minor new releases aren't going to have any issues are they? If something goes wrong it is either going to be because I screwed up somehow, or the application is badly written.
-
@Carnival-Boy said:
I wouldn't say it's non-technical. Qualification involves a vendor testing their application on a new OS to ensure that it doesn't have any issues, prior to telling their users it is ok. That's a technical process.
It may be technical on their end (or may not) but to you it is support based, not technical, if that makes sense. That's what I meant. Sure it might be that the app doesn't work on the new OS at all, and that is very technical, but to you it might be a non-technical "can't go to the new version". If it were technical to you you should have some means of fixing it, in theory.
-
@scottalanmiller said:
@Dashrender said:
What is your take on moving to a new server OS upon release?
This is a tough discussion as there are many factors. But the first one I want to consider is... what do you consider a "new release?" In the Linux world, where numbering tends to be very straightforward, let's talk about RHEL / CentOS.
With RHEL, it is common for people to wait on major releases (RHEL 4, 5, 6 or 7) for a month or two before really starting to deploy, normally by having them in their labs first to test application compatibility. It is very rare that someone has a stability concern with even new major releases as a key part of the goals of a major release is to address stability. But there is cause for some concern due to the number of changes so a blended approach can make sense.
Generally, however, minor released (RHEL 6.1, 6.2, 6.3) are not something that you wait for because they are incremental patches, service packs, if you will. They don't represent a core change to the system although they might bring new functionality, they are small changes that are supposed to represent another six months (or whatever) upgrades whether security, stability, new features (rare), etc.
When talking Windows you have to look at the Windows NT numbers to know what you are looking at. Windows NT 6.0 (Server 2008) and its family are still continuing today. NT 6.1 was 2008 R2. NT 6.2 was 2012. NT 6.3 was 2012 R2. And NT 6.4 is Windows Server 10.
When Windows Server 10 releases, which is really at the core of what we are discussing here, we are not talking about a "new" OS, IMHO, but we are talking about a small, incremental, late lifecycle upgrade from 6.3 to 6.4 with some new features (new FEATURES might be avoided, but not the OS itself) and lots of security, stability and performance upgrades to the core OS.
Not only will Windows Server 10 be a minor release (incremental) but it will also be out months after its desktop iteration is releases. So the OS itself will have quite a bit of field time both in desktop protection and in Server RC candidates before being released as production.
So even if you consider Windows Server 10 to be a new OS, which I do not at all, both because of faith in the vendor's diligence and the heavy industry use of the product before production release I would consider it battle tested even on release day.
But truly, think of it only as a minor update and not a new OS and suddenly the reasons to deploy it become very clear. This isn't "new code" but is, in reality, the most mature, well tested version of the NT 6 family. As a late release, it is the oldest, not the newest, copy of the code.
I thought I read some where that Microsoft is making the jump from 6.4 to 10, which will be the first time the os and kernel match. I could be wrong though.
-
@lance said:
I thought I read some where that Microsoft is making the jump from 6.4 to 10, which will be the first time the os and kernel match. I could be wrong though.
Linux did a renumbering too, recently, to make the number more marketable. But 3.0 is actually part of the 2.6 family. At best you could consider it 2.8. Microsoft may do the same thing, switch from a meaningful numbering to a marketing number. But the new kernel is remaining part of the Vista kernel family.
