to change, as you pay for the time that the VM is running. In the pricing calculator
example, I showed that the VMs were set as running 744 hours a month, which means
running 24 hours a day, every day of the month. However, it’s unlikely that every VM
has to run every minute of every day. Consider a website that consists of 20 IIS VMs.
All 20 may be needed during the day, but at night maybe only half are needed, which
in Azure means that you would shut them down and save that money. If your services
are not needed during the weekend, they would be shut down so that you don’t pay for
them. An assessment would be performed on the environment to understand the real
resource requirements throughout the month so that instances can be stopped and
started to optimize spending. The Microsoft Assessment and Planning toolkit can
assist you with this in addition to scaling capabilities in Azure.
One scenario that commonly comes up is desktop as a service (DaaS), offering desktop
environments in the public cloud. Microsoft Azure has its own application publishing
service called Azure RemoteApp, which can publish Office applications through a
provided template or your own custom application through your own custom
template, and there is nothing to stop you from creating your own deployment for
your organization. Microsoft has guidance on the configuration of Remote Desktop
Services (RDS) in Microsoft Azure, which will give you a session-based desktop
experience. This guidance can be found at the following location:
http://msdn.microsoft.com/en-us/library/windowsazure/dn451351.aspx
What you cannot do is run Windows client operating systems in Microsoft Azure (or
any other public cloud service, for that matter). This is not a technical limitation but
rather a licensing one. There is no way to license a Windows client to run in a public
cloud environment. That is why any DaaS offerings that you see are based around
sessions running on Windows Server as opposed to connections to an actual Windows
client operating system. Even if a Windows client could be run in Azure, you would
still not be able to run a VDI solution, as VDI requires agents to run on the hosts to
help manage the state of VMs, and it is not possible to deploy agents on Azure hosts.
The good news, as discussed in the previous chapter, is that using session-based
services gives the same end-user experience and a higher density of users, so it’s a
win-win. Also, Windows Server 2016 has Personal Session Desktops, which provide a
way to give specific users a specific hosted desktop, and it does not require an agent on
the compute host.