Valerion wrote:Windows works well as long as EVERYTHING is Windows. If you create a heterogeneous network environment it falls apart pretty quickly, or become a setup nightmare.
It gets equally nightmarish if you go all-Windows. Just because all the software ships under the same brand name doesn't mean it works well, or even works
together. Our company has been MS-centric since 1999, with our AD forest established in that time.
Today, we can't migrate to Microsoft Office 365 because of the age of our domain, and the hundreds of issues with OUs and objects and whatever else. We can't upgrade the forest because there are Windows servers that we cannot upgrade the OS on, because old Microsoft products that wouldn't work under Server 2012.
We couldn't integrate Exchange and Lync to provide in-browser IM in OWA, something that Gmail's had for years. We couldn't integrate SCOM and Lync to provide centralized monitoring and reports. We couldn't get the various flavors of Office to play together well, so anything installed via 365 will not have the same functions as that installed via VL.
Maybe it used to be the case that if you went all-Microsoft, everything would work together well, but that's simply not the case these days. There are far too many moving parts in any given corporate network, and different product divisions at Microsoft responsible for each component.
Microsoft is basically open-souce software that you pay for:
- The code would be too complex for any one developer to maintain
- You need to go to support communities to find documentation and help
- The paid-for helplines are useless
- A lot of functionality requires workarounds, scripts and hacks that look an awful lot like Linux-ish "fixes"
- People have left Microsoft and taken their knowledge with them, so products are stagnating just like older open-source products
- You have to pay third-party vendors for implementation and migration support - Office 365 openly requires this for successful migrations, since they cannot build a tool powerful enough to pull any on-prem config into the cloud, for their own stack
- Different products have different standards and formats, and it's very difficult to integrate functionality between them
- Things break for no reason - I have an ASP.NET MVC 3 application using EF, that occasionally fails to create in-memory objects, causing YSODs for absolutely no reason.
- You're more likely to find a fix for an obscure issue on a third-party blog than Microsoft's own documentation
- Microsoft is moving all the administration features to Powershell, without all the accompanying documentation. When we set up Lync 2013 we had to run commands as per a third-party guide, trusting that the cmdlet would accept the parameters.
In almost every respect, you get the same level of performance from open-source than you do from Microsoft, except that with Microsoft you're paying license fees on top of everything else, and you're having to deal with proprietary standards in most of their products.
The only thing that Microsoft has going for it at the moment (at our company anyway) is inertia. The cost of migration is higher than the cost of paying the licenses, so we'll continue to do so.