> In particular, if the solution begins with "First, install..." you've pretty much lost out of the gate. Solving a five-minute problem by taking a half hour to download and install a program is a net loss. In a corporate environment, adding a program to a deployment is extraordinarily expensive. You have to work with your company's legal team to make sure the licensing terms for the new program are acceptable and do not create undue risk from a legal standpoint. What is your plan of action if the new program stops working, and your company starts losing tens of thousands of dollars a day? You have to do interoperability testing to make sure the new program doesn't conflict with the other programs in the deployment. (In the non-corporate case, you still run the risk that the new program will conflict with one of your existing programs.)
> Second, many of these "solutions" require that you abandon your partial solution so far and rewrite it in the new model. If you've invested years in tweaking a batch file and you just need one more thing to get that new feature working, and somebody says, "Oh, what you need to do is throw away you batch file and start over in this new language," you're unlikely to take up that suggestion.
The fud from Microsoft is interesting. They imply that by using open source, you can't get support for when you're company is losing money. Additionally, they imply that by using Microsoft, they will actually do something useful in this contrived situation losing thousands per day.
Here's a hint, whichever solution is more complex is going to bite much harder from a downtime perspective, regardless of the underlying technology. I would much rather depend on a few line script that uses sendmail rather than a 5,000 mail client half implemented in a batch script.
I actually don't hear FUD from MS about open source any more. I'm doing tests on my workstation of .net core and asp.net 5...all open source. Mark Russinovich said the other day that they are considering open sourcing Windows one day. They contribute to the Linux kernel. I can spin up a linux VM in azure with a powershell command. I don't know how much more friendly to open source they could be.
The article that was quoted and that you are talking about is an old article by Raymond Chen where he is talking about the importance and value of backwards compatibility. He's talking about the pain in the ass that large businesses face when trying to update the base image for a fleet of servers. I can tell you from personal experience that its a painful process.
That's a personal blog, not some official Microsoft thing. I think that, regardless of the source, it's an important point -- at a really big environment it's hard to introduce new software packages for nontechnical reasons (like the licensing stuff) and for technical ones too (gazillions of machines with different configurations you have to worry about breaking). I've been a system administrator at a small place and even then it's not fun to try to roll out something like that.
wow. in which world do you live?
since puppet, its really easy to update fleets of machines.
and the tools even emerged.
new software could be upgraded easily, as long you have a valid license or if it is handled by a "free" license.
In 3 years Microsoft will deliver MS Virtual Deployment Technology that uses powershell and ftp under the hood, but the integration with Visual Studio will be swooned for by millions. I'm speculating of course, but it feels like familiar territory. It always sounds like stockholm syndrome...
not everyone is in a place where they can use puppet or a similar orchestration system. Lot's of places are actually really scared of automation because they did it in the past and someone left without documenting something that caused some mayhem. I know, things like that can be avoided. And yes, all of the places that are gaining the benefits of scale are using lot's of automation...not everywhere is like that.
Things are better than they used to be, yes. But in lots of big businesses you wouldn't believe how slow processes are for all kinds of very valid sounding reasons. Don't get me wrong...its something that I'm personally working on changing everywhere that I can. I think everyone should be able to code, system admins should ALL be able to code in at least one language.
> In particular, if the solution begins with "First, install..." you've pretty much lost out of the gate. Solving a five-minute problem by taking a half hour to download and install a program is a net loss. In a corporate environment, adding a program to a deployment is extraordinarily expensive. You have to work with your company's legal team to make sure the licensing terms for the new program are acceptable and do not create undue risk from a legal standpoint. What is your plan of action if the new program stops working, and your company starts losing tens of thousands of dollars a day? You have to do interoperability testing to make sure the new program doesn't conflict with the other programs in the deployment. (In the non-corporate case, you still run the risk that the new program will conflict with one of your existing programs.)
> Second, many of these "solutions" require that you abandon your partial solution so far and rewrite it in the new model. If you've invested years in tweaking a batch file and you just need one more thing to get that new feature working, and somebody says, "Oh, what you need to do is throw away you batch file and start over in this new language," you're unlikely to take up that suggestion.