So let me get this straight...
-
Randor wrote:
It seems perfectly reasonable to give the server administrator several days or perhaps weeks to perform a manual reboot. if that does not happen... force the update.
Absolutely NOT. Computer systems are tools of the business, not the other way around. The vendor does not own the environment, does not manage the environment, and has absolutely no say in how the environment is managed. They can recommend, but it is NOT their call. I have worked in complex, highly regulated environments where any computer rebooting in the middle of a process will cause (at least) hundreds of thousands of dollars in damage, not including loss of business due to loss of confidence by the customers. People get fired for doing anything that negatively affects such processes, so I don't expect any OS that can force reboots will be allowed.
And how much do you pay out from those hundreds of thousand dollars to those clients who lost everything using your service because a timing issue existed in your system unpatched? Or because Google is your competitor[^]?
-
And how much do you pay out from those hundreds of thousand dollars to those clients who lost everything using your service because a timing issue existed in your system unpatched? Or because Google is your competitor[^]?
Peter Adam wrote:
And how much do you pay out from those hundreds of thousand dollars to those clients who lost everything using your service because a timing issue existed in your system unpatched?
This has nothing to do with the point of allowing a known defect (unmanaged server reboot) into a business process.
-
Let's say I'm crazy enough to install Windows Server 2016 to host an app I want to keep going in the cloud 24/7. There's no way to stop this thing from magically rebooting willy nilly outside of setting the normal business hours or whatnot... but say when not in that timeframe, Windows will up and just restart la la la without a care to the wind for a *server* app? Did I miss the memo where MS started smoking crack?
Jeremy Falcon
I don't get how you want to 'keep going 24/7' and have this running on a single server and not in a cluster (in VM's on a Nano Server or something...)
-
Let's say I'm crazy enough to install Windows Server 2016 to host an app I want to keep going in the cloud 24/7. There's no way to stop this thing from magically rebooting willy nilly outside of setting the normal business hours or whatnot... but say when not in that timeframe, Windows will up and just restart la la la without a care to the wind for a *server* app? Did I miss the memo where MS started smoking crack?
Jeremy Falcon
So Netflix reboot there servers all the time, and they have no idea when it's going to happen. It makes their system more robust. I know they are an extreme example, but I think it shows that if you can't handle a machine reboot, it means that your architecture is wrong for 24/7 up time. If you are designing applications for a cloud environment then following the 12 factor approach is a good start, specifically The Twelve-Factor App - Disposability[^]
-
Let's say I'm crazy enough to install Windows Server 2016 to host an app I want to keep going in the cloud 24/7. There's no way to stop this thing from magically rebooting willy nilly outside of setting the normal business hours or whatnot... but say when not in that timeframe, Windows will up and just restart la la la without a care to the wind for a *server* app? Did I miss the memo where MS started smoking crack?
Jeremy Falcon
After giving this much thought, I'm going to side with Microsoft on this one. A server is intended to be part of a domain and to therefore adopt the domain policies once deployed. Until then, it should default to the most fanatically secure/paranoid state possible. Public facing system deployment should be done with deliberation requiring opt-out options for anything related to security.
-
So Netflix reboot there servers all the time, and they have no idea when it's going to happen. It makes their system more robust. I know they are an extreme example, but I think it shows that if you can't handle a machine reboot, it means that your architecture is wrong for 24/7 up time. If you are designing applications for a cloud environment then following the 12 factor approach is a good start, specifically The Twelve-Factor App - Disposability[^]
While I agree, that in the context of something redundant, "underlying OS for a cloud", etc. that's just a node on a cluster of machines, a single machine reboot can be acceptable. I don't agree that forcing it upon the user within a guest VM or legit server is prudent. And since Windows update tends to release updates for all at the same time, it would force more than one machine to reboot at similar times. I don't agree with that, it takes the assumptions that server admins are smart enough to figure out how to keep machines up to date.
Jeremy Falcon
-
After giving this much thought, I'm going to side with Microsoft on this one. A server is intended to be part of a domain and to therefore adopt the domain policies once deployed. Until then, it should default to the most fanatically secure/paranoid state possible. Public facing system deployment should be done with deliberation requiring opt-out options for anything related to security.
You disagreeing with me... again? Say it isn't so. :rolleyes: I don't agree with MS. I've administered ISPs. Under no circumstance should a machine go down without the admin having a say-so in it. This takes the assumption a sys admin is a retard who can't patch his/her system without being spoon fed.
Jeremy Falcon
-
I don't get how you want to 'keep going 24/7' and have this running on a single server and not in a cluster (in VM's on a Nano Server or something...)
Fair enough, but still doesn't mean a magical reboot is a good idea.
Jeremy Falcon
-
You disagreeing with me... again? Say it isn't so. :rolleyes: I don't agree with MS. I've administered ISPs. Under no circumstance should a machine go down without the admin having a say-so in it. This takes the assumption a sys admin is a retard who can't patch his/her system without being spoon fed.
Jeremy Falcon
This is about a default configuration, not a deployed configuration. A server should never be deployed in its default configuration. The unfortunate reality is that many admins aren't doing due diligence in setting up servers. The number of unpatched servers of all OS varieties is astonishing. Another point is that Microsoft intends Windows Server to be used on a domain with domain policies in place, not stand-alone.
-
This is about a default configuration, not a deployed configuration. A server should never be deployed in its default configuration. The unfortunate reality is that many admins aren't doing due diligence in setting up servers. The number of unpatched servers of all OS varieties is astonishing. Another point is that Microsoft intends Windows Server to be used on a domain with domain policies in place, not stand-alone.
I know it's about a default configuration. I also know it's not nearly as easy to avoid this now. And I know there are stupid admins out there. However, magical default reboots are silly. And stand-alone or cluster doesn't matter. I don't expect you to agree with me. Seriously Joe. I get how this pattern works between us. You never reply to my posts unless it's to disagree with me. Been years now bro. Seriously. Tell me something nice.
Jeremy Falcon