I am renowned for my long sentences. Editors hate me for it, but this article may hang on a sec buck the trend. That's because I'm going to be talking you through the new Amazon cloud server instances that use just a minute, bear with me Windows 2008. The reason this is worth a look, even though AWS has been around for several years, is because the free trial version now has enough hours of runtime to leave a Windows server up and operational for a year.
At least, that's their claim.
I know there is a sharp divide in the technology world over Amazon Web Services: either you get it, or you don't. There is no partial state, no gentle road to comprehension. In the most clich-ridden view, AWS fans tend to be more Linux than Windows; more developer than supporter; more compiler than CSS; and increasingly, have never touched an old-school server inside an old-school company. But this new combination of operating system and (non) billing will, Amazon hopes, draw in those who have thus far been disqualified by failing to hit one of those clichs squarely on the "yes" button.
It is actually quite instructive to think about what the diametrically-opposite tribe from the existing AWS user base might use for a description. It is easy to start off with more Windows than Linux, more systems builder than developer, more batch file and Group Policy than HTML or C, and finally, those more accustomed to working in whole Terabytes and IOPs than flashing the newest, tiniest netbook. I would guess there are more of these in the IT Pro readership than the first sort, so here is a little canter through what you get when you set up a Windows Instance on AWS.
First of all as my stuttery start here should imply lay a bit of time aside for a good deal of to-ing and fro-ing. First you have to go to aws.amzon.com and sign up. This includes a process of issuing you with a small file that is your portion of a key exchange process, so avoid doing this on a shared or borrowed machine you cannot access later. You use the keys now and again, not every day, so they are prime candidates for going walkies. In my case, I was trying all this out on my faithful Thinkpad X61s, as also used during my trip to Microsoft Redmond, to look at their SystemCenter 2012 Virtual machine management utility suite, so (quite coincidentally) the usability comparisons between that and AWS will be almost scientifically precise.
Once I had my AWS membership all secured, it was on to create some instances in EC2. This is just a matter of picking the right tab in the AWS browser page, then asking for a new instance. You are presented with an impressively long list of operating systems and other parts too: the Windows 2008 Server options include machines with SQL Server (Express or full fat) as well as Clustering (I guess so you can make a Cluster with a local machine inside your company) and even 2008 R1, if you want it.
The rest of the pick list is flavours of Linux, though in a bit of a fight back against VMWare's airy assertion that with the coming of virtualisation, "everything's x386", several of the distros on offer include access to CUDA and Nvidia specific drivers. Before you snort and say "playing games on a VM in the cloud? What is the point?" remember that there is lots of work done these days on raw number crunching by handing a job over to the dedicated processors on an NVidia graphics card, as these are so much faster than Intel CPUs for maths.
(That was a long sentence, I know the signup's done now and I am getting my connection method together).
Once you define which OS/app combination you are after, you have to work out how large to make your instance. This is where the split between free and paid-for becomes more apparent: you can take a "T1.micro" instance inside the free offering which has a single core and up to 613MB of RAM, or you can up the spec until you hit some improbable maxima: 20 cores and 60-odd GB. This is the part where you decide if your instance is going to stay free and running all the time or not, too. Of course, the presented charges look encouragingly low. Initially.
Once you pick your emulated hardware (I went for the micro) there is a remarkably short pause before you go to the instance management view to decide whether to start or stop your new server. This has almost none of the look and feel of the old-school server build process no volumes to lay out, no serial numbers to type in, no drivers to hunt down.
However, there is another little pair of downloads that can take up to 30 minutes to complete. This is another public/private key file for that specific instance, and the lag is not about low-speed links or massive sizes, it is a delay in which the admin password for that Windows server is generated and applied to your new instance.
To understand why some of this is quick, while other parts are slow, and why there are some slightly odd memory limits to several of the configuration options, you need to understand a little bit about the deep dive, under the hood world of VDI.
This is becoming a general industry term for single-user virtual machines on a remote host in other words, the user cannot tell how many other guests are alongside them within the architecture. They just see their closed box, and do their thing. Someone else sees the management interface that parcels out VM guests across a pool of hosts. VDI also incorporates the concept of the "Gold Image" a basic VM guest instance that represents the current state of the art for that user population.
When a user starts a VM, what actually happens in VDI is that the "Gold Image" is cloned, with a cut-up and fudged memory map that partly points back to the original (for bits of memory that won't change between instances of the image) and partly into the "user space" in the underlying host. That second bit does vary from guest to guest.
Gold image based guest provision has some advantages it is fast, for one thing and some oddities. The amount of memory you need will throw you off guard if you are an oldschool type, because actually the host is parcelling out the memory between largely identical guests, and cheating. Also, the usual VM protective/supportive toolbox is a bit absent, because as Joe Guest, you get no access to the VM feature set and true enough, I could not suspend or snapshot my EC2 Windows server.
The next thing to contemplate is the networking. My free server instance came with an IPv4 address, beginning 10.205. Those with long exposure to the world of IP networking will instantly exclaim that this is a private IP range, and hence not reachable from outside, on the rest of the net, without special configurations inside some kind of unspecified border device. While informing me of their choice of address, AWS also showed me a deceptively short firewall configuration dialog box, with initially the only option being standard Remote Desktop traffic on Port 3389.
The deceptively simple bit is that you can add other protocols, and you can also limit the range of IPs from which each protocol will accept connections.
Home users and hackers will not see the point of this, but if you are on any kind of business internet connection, the chances are you will have an external fixed IP address and therefore you can take advantage of this feature and secure your new Cloud VM right from the word go. The disadvantage is rather more subtle: it was the case that companies could happily leave the RDP ports open for user remote access, mainly because hackers had no experience of using a server configured for RDP, so they never tried to penetrate company firewalls by using it. Those days look like they are over, now that an effectively unlimited demo setup shows the whole world how remote access can be made to work.
At the end of the simple firewall choice process, AWS offered to download a desktop shortcut to let me connect to my cloud VM server. This avoids the problem of the VM having an IPv4 private address, by borrowing a concept from IPv4 Reverse Lookup Zones: the connection shortcut addressed my server as "xx-xxx-205-10.aws.amazon.com".
This is the same fix that I encountered using the equally immense Microsoft infrastructure, sitting in Redmond on my humble IPv4 only Thinkpad both Amazon and Microsoft are not IPv4 internally, but they are obliged to handle traffic from and to the older protocol. So getting to an AWS VM instance involves your RDP traffic hitting a gateway host, which then uses Amazon's internal protocol (I'm not fudging here Amazon doesn't use IP internally and the exact details are at least mildly secret...) to forward your traffic to the host where your VM is running, in my case, in Virginia.
What was I proposing to do with about 12GB of free disk space, 600MB or RAM and a copy of Server 2008? The easiest test I could think of was a quick install of SmarterMail (see www.smartertools.com) , which manages to be small, reliable, and uses Windows Server in a faintly abusive way with traffic on non-standard ports and a bit of hacking to show some nice web pages. To my slight amazement, I was able to turn off IE ESC in my VM and grab the SmarterMail download without any trouble: even though the registration and one-shot download link came to my Thinkpad, Amazon have allowed for clipboard sharing between RDP host and client, so a quick copy and paste, and I was running my setup program.
The only part that was missing in all of this was even the slightest hint of a Windows licence key. Not a whisper did I hear that I might have to buy a key first or have one I had prepared earlier from my own eOpen or TechNet subscription. Along with many other questions about the boundaries of this or that flavour of AWS VM, this question is definitely a candidate for some intense Googling, mostly through the AWS Developer Forum sites (telling name, that).
Whilst Amazon is not a charity, it turns out that almost everything you could ever want in a server is available, though at a price. And there is a lot of internal infrastructure at Amazon that you need to be ready to negotiate to find what you want. For a very simple first example, I found out later that if I had nominated a different virtual hardware platform, I could have had a suspend/resume capability, and the list of these platforms is cryptic at best.
The hardest thing to overcome, when using AWS, is that something which looks, feels and smells so much like a local server is actually on the other side of the Atlantic. In our tests, system boot times and responses were excellent, if a shade slower than those achievable with local current-generation hardware and hypervisors.
I may even make use of my little SmarterMail test install, even though the IP routing to my little free server means it cannot send or receive Internet mails, because SmarterMail's upgrade path includes a complete export, reinstall, and import for at least one of my clients. If I can upload their message-base to my test machine then that's an ideal bit of temporary on-demand cloud computing I can use without disturbing their venerable server or their mail software. And that is an added bonus.
