Reply to post: The why and what for

Wrestling with Microsoft's Nano Server preview

Uffe Seerup

The why and what for

Per Microsofts Jeffrey Snover (chief architect for Windows server), Server Nano is *primarily* a scratch-your-own-itch refactoring.

The biggest user of Windows Server - by far - is Microsoft Azure. If you can save 25% on the size, you can increase VM density by 20%. If you can save 50% you can double the VM density.

Harddisk footprint has been reduced with a factor 20. That is a *massive* saving once they scale to Azure.

OS RAM usage is down considerably as well. The fewer features means fewer patches (both bugfixes and security patches) and consequently fewer reboots. Microsoft investigated how many of the patches in 2014 that touched the components in Nano and concluded that 80% of patches would not have been required, as they concerned components not in Nano.

But to turn the question around? Why does a *server* - by definition a machine whose primary task is to run a workload - need to have a *command interpreter*, a *shell* and an *editor* - even if it is very basic.

Why should you need to log in to a machine over SSH, start a command interpreter on the server and issue commands? Why would you want a Ruby interpreter? All extra components has to be maintained and adds to the attack surface.

Microsoft has come to this realization late, but at least they now go the whole way and may very well take it a bit further.

Ideally the remote server is "just a server" with a standard interface to control and configure it and no way to log in locally. That is what Server Nano is.

Btw, PowerShell has this nice property that it can submit "script blocks". Script blocks are semi-compiled script, so while MS will still need some PowerShell infrastructure on Nano, they could very well cut away the *shell* part of it - leaving only the execution engine. Already today - if you use PowerShell remoting - you can send scripts to the remote that is not just text. They are parsed and turned into a PS script block locally and then sent to the remote PS engine. The upshot is that you can create scripts that refer to *local* script files but execute them remotely. PS will send the parsed scripts blocks for those files across the wire.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019