50 comments

[ 1.8 ms ] story [ 79.6 ms ] thread
Can someone tell why one would use Windows Server? I can't imagine using it as an application server because of the OS's heft. Maybe as an admin server over a cluster of lighter-weight app servers?

Edit: Thanks for the answers. The article actually had a pretty good overview. Basically the OS is built to host tons of VM's so every box (hundreds of logical cores, terabytes of memory per VM) can be a cluster in and of itself.

Virtualisation (Hyper-V), Active Directory, Exchange, SQL Server...
People who need SQL Server, Exchange, ASP, .NET, Active Directory, etc. (MS technology) If you want to build a web service that works with Office files, Windows is still your best bet.
(comment deleted)
It's mostly used in large companies (at least in France).

They can use it for ActiveDirectory, and it help them reduce IT department costs: a Windows Desktop SysAdmin can easily manage a Windows Server.

Getting Linux would require them to hire new specialists.

Because some software provider has their stuff working on Windows and your business has determined that is the software they want to use.
They regularly update Windows with a built-in auto updater mechanism (which is called Windows Update). For me, this is a killer feature #1.
windows updates breaks the system quite often. I think all of us experienced it. enabling auto-update on windows servers is not the best idea if you need reliability.

somebody recently told a story of 2 cloned vm machines, the same hardware and configuration. same updates installed on both. one did not start up correctly, other one runs smoothly.

windows platform is way more unpredictable then any other system i worked with.

In addition to what the others have said, there is a very big list of 3rd party vendors who use C#. Look at enterprise CMS, for example. Microsoft also has a very large footprint in both CRM and ERP systems. Those install bases and the ISVs who build on top of them use Windows. There's also the micro/small business market where a server resides in the office to handle printing/video surveillance, small ERP apps. Think about dentist offices/clinics, shops, restaurants, gyms, small warehouses.
Microsoft themselves seem to be making it less relevant as a web app server. ASP.NET Core is cross-platform (I wrote a book on this) and SQL Server 2016 is coming to Linux. I guess they will focus on Azure for this market but Windows Server would still be useful in the back office for email and domain admin.
Some of us just prefer it, even without being tethered by other MS dependencies such as Exchange, SQL Server, etc.

Personally, given the choice I would prefer to start a new web API project in .NET because I feel most productive in that environment.

I have migrated to Linux for app and DB servers, but I don't know of anything better than Active Directory for managing users or Exchange for email.

I'd have to imagine such things exist, (I mean, come on it's 2016 there has to be a reasonable alternative to Exchange at least by now, and something a little better than raw LDAP for user management, right?) I just cut my teeth on a MS environment and don't yet see anything comparable.

You can install Windows Server in a GUI-less configuration, so the OS becomes much lighter. Administration would be done via Powershell command-line (and SSH, etc. Not sure if RDP/VNC would work)
That's the default for 2016
Windows Nano Server is briefly mentioned in the article but they fail to touch on just how lightweight it really is. Currently you can get it on a VHD coming in at 610 MB (https://msdn.microsoft.com/en-us/virtualization/windowsconta...). Not bad for Windows...

Combine that with a need (for whatever reason) to run .NET & IIS and it can definitely make sense to start running some Nano containers.

In this interview, http://softwareengineeringdaily.com/2016/03/14/state-program... Jeff Atwood describes building Discus on *nix versus his experience building StackOverflow [and previous work] using Windows server and related products. My recollection of what he says is along the line of he believes the Windows Server ecosystem requires substantially less systems administration staff/effort at scale. My understanding is that he's not talking about how much work he had to perform on one versus the other [which could be just his level of experience] but rather the way in which the different stacks affected hiring priorities and business finances during growth at Discus versus StackExchange.
thx for the podcast link. I really should listen to software engineering daily more.
Even when I listen more, I can't keep up. I was more than three months behind when I listened to the Atwood episode.
Because the rest of your team is more comfortable with Windows and can support and develop for it.
"Can someone tell why one would use Windows Server? I can't imagine using it as an application server because of the OS's heft."

Well, back in the day, I preferred Windows Server 2K3 because I could actually address more than 4GB RAM on a 32-bit architecture, and worked great for running my Q3 servers (and games played quite well on 2K3.)

Windows server is useful to support legacy apps that depend on Microsoft's propriety services, AD comes to mind. This server would of course not be deployed on metal, but as another VM on a proper Linux host. Windows on metal are not allowed in my organisation.
Well defined solutions.

You don't bother trying to decide what webserver to use. You just add the web server role, and you have iis.

It's pretty easy to manage.

for those who cant handle a command line interface or make automatic scripts. While its possible to write scrips in windows, everyone use the gui. There are not even config files, everything is done via mouse clicks.
This article mentions a lot of hardware specifications and trends (128GB RAM, Xeon, NUMA, etc) but I think those abundant details make it hard to see the forest for the trees.

Here's how I would compress the article's core point...

Windows Server has 3 major time periods:

1) early 1990s: the era of servers as "dumb" file & print servers. This was the time of Windows NT 3.0 and NT 3.5 competing with Novell Netware. At the time, many were debating who would win the server wars based on superficial things like NT having a GUI whereas Netware had a text console, etc. Arguing about those details was missing the point of what would dominate the next era...

2) mid 1990s to mid 2010s: the server as an "app server". Instead of being just a dumb file & print server, the programming API the server exposes enables complex applications to be built on the platform. This is where Windows Win32 API beat out Netware's NLM (Netware Loadable Modules) as a programming interface for things like mail servers (MS Exchange wins), http servers (MS IIS Intenet Information Server wins), databases (Sybase and MS SQL Server), etc. (The "wins" in this context was the defeat of Novell and IBM OS/2 -- not Linux.)

3) 2016 and beyond: the "abstraction level" of IT thinking has moved beyond "file & print server" and also beyond "app server" to the "cloud as the operating system". In this new era, the server o/s itself is no longer a centerpiece of conversation but merely a small component of a larger private cloud stack (e.g. upcoming Azure Private Cloud). This is why Windows 2016 has features such as containers, micro footprint configuration, etc.

Once one has the broad brush strokes above, I think it's easier to overlay the progression of hardware technologies on top of it to see how they enabled each era. If instead, you interweave the hardware stories throughout the article, the macro trends are too easily buried in the details.

Not to nitpick, but do you think points #1 and #2 had to do with the adoption of TCP/IP vs IPX/SPX?
I don't think so because I remember in 1994 that many companies were running Microsoft NETBIOS. Microsoft was already winning the server war before TCPIP became the default choice in the late 1990s. At one time, I remember having to install extra software (Hummingbird?) to get a usable TCPIP stack on MS Windows. However, I don't remember exactly which version of Microsoft Windows I had to do that.
Most people installed Trumpet Winsock on Windows 3.1 to get a TCP/IP stack (written by Peter Tattam, who never got much money out of it since few people paid the shareware fees).

I'm thinking that one reason Microsoft won was because of superior developer tools. I admin'd a small Netware 4.x machine back then and I couldn't even tell you what was needed to write an NLM.

I think if you're pinpointing a move from File & Print to app servers and tying it to the move from Netware to Windows it would more be a combination of Netware's difficulties in stably running multiple apps (it was a rock-solid platform for file and print but less stable as an app. server) combined with Microsoft's "aggressive" moves during that period to supplant Novell and Lotus in the office server marketplace.
>Netware's difficulties in stably running multiple apps (it was a rock-solid platform for file and print but less stable as an app. server)

Thank you for that reminder. The NLM platform was a fragile architecture.[1] In contrast, both IBM OS/2 and Windows NT of that time period had superior architecture (memory protection, separation of kernel-vs-user address space) for complex applications.

And to add to the other commenter about ease of dev tools -- it definitely was easier to use Visual Basic 3.0 and deploy the app on NT rather than use Netware's NLM SDK that required the C programming language. Even though VB was marketed as a tool for desktop apps, it didn't stop Microsoft shops from deploying VB apps on the server side.

[1]https://en.wikipedia.org/wiki/NetWare_Loadable_Module#Progra...

Ugh, I remember having to use esc+alt+shift+shift debugger to try and get the server back long enough to down it. And praying that VREPAIR didn't run on restart.
"2016 and beyond: the "abstraction level" of IT thinking has moved beyond "file & print server" and also beyond "app server" to the "cloud as the operating system"."

I think you forgot about WYSE, which did this back in the 90s and earlier 2000s.

Yeah, until sshd breaks due to incompatible dependency and I cannot login. There are exceptions though. For example, RedHat does a good job (in contrast to some other distros) and I always had auto update on for RedHat systems. Windows works like a Swiss clock in this regards, and it is the biggest selling point for me. Slap, update and forget. It just works then without any manual intervention, and most importantly, does not break things after updates.
Even for updating domain controllers? This has not been the case for me. At the basic level pretty much any option will "just work", but for complex setups... I have found Windows to be difficult to use and difficult to learn about, with lots of proprietary software solutions for problems that should be easy to solve with the OS-provided tools, but aren't.
> Yeah, until sshd breaks due to incompatible dependency and I cannot login.

I can't say I've every had that happen to me or anyone else I've dealt with. Do you have any references to relevant bugs/issues? A properly running package manager should not allow this unless there is a serious bug in the packages themselves.

The closest I can think of otherwise is someone getting locked out of a remote machine where root was the only active account and was authenticated buy user/pass not by key, and he accepted the "start blocking password logins for root" change in a distribution upgrade (so he was warned so his own fault!).

Why would you need SSH if the machine is auto-updating itself?
> until sshd breaks due to incompatible dependency and I cannot login.

I've never had that happen, but thankfully remote (virtual) serial consoles are commonplace. Something I wish was more common in Windows environments, as I've had remote access dump on Windows many times, leaving me with no options other than a long drive or call in to a remote DC.

TCP was included by default with Windows 95 and NT 3.1.
Nano Server gets it right finally for Windows Server. It's tiny and headless...no graphical stack at all. Just watch, most internal Microsoft teams will transition to it over time. First they will start releasing software as a container that runs on Nano, probably in the form of Server Core. Then built native for Nano Server.

I've said this before...If you still think that Microsoft has been sitting still for the last 10 years because they lost out on the mobile shift, you are mistaken. Server and tools have done a fantastic job and the rest of the company is starting to unf*ck themselves too. Azure isn't as popular with the HN crowd as Amazon, but if you work in large enterprises...they have a much better story to tell. It's really hard to compare.

Hate on, haters.

>is starting to unf*ck themselves too.

Too late. Developers have left the building.

.NET only exists any more because of legacy interests, there's little compelling developer story otherwise.

> Developers have left the building.

Eh, developers (collectively -- individually, less so, but the set of individuals that make up the collective are in constant flux) are fickle. If there's something good on offer, they'll come back. There's some psuchological resistance that might make rebranding helpful to this, but Microsoft's big enough that, they can probably afford keep things going long enough that people will get over psychological resistance even without that, if they are dedicated.

This developer is going to leave the building when someone else can provide documentation on the MSDN level
I cringe every time I have to read the MSDN documentation. When you really need it, it barely goes into detail to explain what a class/method/parameter does, how to use it, or give any useful code examples.

Its just a false sense of security, in my opinion. Python and Django has great documentation that most of all is relevant with good examples. For the things that you cant figure out, you can always read the source and you will find the answer.

We have a few companies on our portfolio which are both part of Fortune 500 index and whose IT is around 80% Windows.

The last four years I only developed UNIX applications outside work.

Our cloud platform (Azure) here in Cloud and Enterprise team (where I work) does not only embrace .NET and Windows Server. We've got a lot of people working every day to make sure Linux is a first class citizen and we're ensuring that developers working with Python, Node.js, Ruby, etc, get a first class experience as much as we can make it happen.

If you want one huge example where we are embracing Linux as an OS, just see how our SQL Server team is bringing SQL Server to Linux. (its not in public preview yet but we're working on that). https://www.microsoft.com/en-us/cloud-platform/sql-server-on...

But don't get me wrong, we really love and believe in .NET and our own server technology, we're always looking to find ways to innovate and grow it. Just as one example, look at all the work we've done with .NET Core and bringing that to run on Linux, Mac and Windows equally. https://www.microsoft.com/net/core

This isn't the old Microsoft and I love working here more and more every day now that for the last few years we've really embraced the developer community to enable them choice in however they want to build their next app.

You confuse developers like you or like the ones you know with all developers.
No hate at all here, but my last contract I had to deal with Windows deployments and it's still a clusterfuck.

Without a Enterprise agreement you can't automatically install a new Windows 10 machine, period. Bear in mind this counts for the same machine being reinstalled constantly (whilst working out the exact incantations). The Linux hosts these machines ran on installed fine from Kickstarts / preseed files.

Powershell was nice, you can't compare it to bash (they're just too different) but it lives in a world that is .net and the vast majority of the Windows world isn't .net. We needed Windows VMs for some specific apps that couldn't even install without a gui. Could I automate their install? Not a chance.

Basically all these changes are 10 years too late. Powershell is nice, if you live in a .net world. I can't PXE boot a Windows VM without gui intervention without a Enterprise agreement. Why the hell would I go with a Windows Nano solution, which doesn't support the entire Windows ecosystem, when I can write a greenfield app in Linux, even using Mono, and call it a day?

I'm not sure what to tell you there. I actually don't think that's the case about some of that stuff... but I get it. I think Microsoft didn't really get how hard it was to run a large network of windows machines until they had to do it themselves.

Nano does support the entire windows ecosystem through containers running server core. There really aren't major apps that won't run on server core. Even if they need the GUI to install you can remove it afterwards and most apps will run just fine.

I hate to say it, but every new Microsoft announcement makes me think "Never again" more than "I can't wait to use that."

Nadella seems to be making great moves that are good for the ecosystem. Yet a decade and a half of Ballmer is hard to forget as proof of how Microsoft trends when it doesn't have competition. (And I'm not faulting most of the people involved; I'm sure any other company would have done the same thing in Microsoft's position)

Exactly.

If Microsoft had let me install from the autounattend.xml (or whatever it's called) without an Enterprise agreement, i'd have explored it further. But no, for Windows 10 they made it not work at all.

If WSUS was as easy as using createrepo to mirror a Ubuntu or RHEL repo without breaking after an update to support Windows 10, i'd be all ears.

But no, Microsoft continue to break the developer/ops experience. Having my first job in 15 years trying to wrangle Windows infrastructure into place as part of a wider Linux install, i've doubled my resolve to never touch the stuff again.

Interestingly I finished at my last contract on Friday - 2 of the 3 contracts i've been called about since are related to moving away from the Microsoft stack.