When Microsoft started talking about the direction of Windows Server, a confusing term started showing up: client.
If you were writing a server application, said Microsoft distinguished engineer Jeffrey Snover at the TechDays Online event in February, you needed to think about how you built your client.
Not your client for connecting to the server, but your client for running on the server. "If you want, you can put a client on a server," Snover said. "You can put a client on the server but use server APIs."
Wait, a client on the server? Not client-server where you have a client application like Outlook and a server like Exchange, but a client on the server.
If that sounds like a bad and confusing idea, it is - but it's what we've been doing on servers since Windows NT gave us a graphical interface for running our servers. Most of the time the applications you run on a server have a graphical interface - and usually it's not scriptable and automate-able so it's not an interface you can control remotely, except by logging in with Remote Desktop. In the new world of automation and virtualisation, that's just making more work for yourself.
Actually, the name should be a clue; why does a server have a desktop? So you can interact with applications on the server. Should you actually be interacting with applications on the server? Not through a GUI, says Snover. He made that point much more clearly at Build, calling the server GUI "poison".
Now that we know about Nano Server, it makes much more sense to talk about - and deprecate - the idea of a client on the server, in terms of applications that aren't built for the modern server operating system.
The future of Windows Server is a minimal version of the OS with only as much of the APIs and features as you need, working with command line tools or with remote tools. If you want a graphical tool, there are going to be web versions of tools like task manager and the registry editor, because actually there are plenty of things that you need a graphic interface to do efficiently. You just don't want all the extra code needed to run that interface running on the server, because it takes up space and needs more memory and means more patches and reboots. "The Web GUI is not a compromise," Snover promised at Build.
Snover suggests that we need to change the way we talk about the different things we do on a server. Looking back, he thinks using the terms 'Server Core' and 'full server' was "a misstep" because it made it sound as if full server was better. Now Snover would rather say, "It's not full server; it's server with a GUI. Let's get even clearer; it's a client stack running on the server."
He expects the final name to be something like 'server with a client experience'. Nano Server and PowerShell may be the future - and Snover is clear about calling Nano Server the future of Windows Server, talking about a model of "just enough operating system" - but if you want a GUI on a server you can get it, for things like Remote Desktop.
You just need to remember that you're adding more of an attack surface and you're using more resources and you're going to have more reboots, so it should be an exception rather than the rule. Snover puts it pretty bluntly: "Most server applications should not be used in a client stack on a server."
So if using the term 'client' when you're talking about a server makes you scratch your head, that's a good thing - because you ought to think long and hard before you keep on doing it, just because that's what you're used to.