Ever since Microsoft decided to tighten its grip on the way in which its software is provisioned, product activation became a part of every Windows administrators agenda.

Stepping up from Windows Server 2003 to Windows Server 2008, Microsoft has introduced two changes to the activation process (or in its official name: Windows Product Activation):

1. Volume License customers are no longer exempt from performing activation; customers unwilling or unable to activate products online must use the newly introduced Key Management Service (more on KMS coming right up)
2. The Activation we knew from Windows XP/2003 in which the Windows is provided with a product key during installation which is later verified online (or by phone) is still available in Windows 2008 and has been labeled as Multiple Key Activation (MAK). In addition to MAK, Microsoft introduced a new activation method in which Windows periodically checks-out a license from a centralized Key Management Service (KMS) which is good for only 180 days. After the initial activation, Windows will contact the KMS server every 7 days to restart the 180 days countdown.

It is important to understand that both methods are designed to control (read:limit) the number of Windows activations performed by the customers based on the number of licenses purchased from Microsoft by requiring that each copy of Windows be activated for the particular hardware that its loaded onto.

This means two things:

1. Each new Windows installation must be activated – even if it on the same hardware configuration (click here for Microsofts definition of “hardware configuration”).
2. When an existing copy of Windows is migrated between hardware configurations it must be re-activated.

That’s hardly news, why does it suddenly relate to AWS?

Traditionally, the only way to launch Windows Instances was from one of the AWS provided AMIs (or a user-created derivative thereof). These AMIs were pre-configured to include a number of features such as paravirtualized drivers, the EC2 Configuration Service as well as numerous other configuration defaults which went largely unnoticed.

One such configuration was Windows Activation – does anyone recall ever activating or fiddling with the activation configuration of his EC2 Instance? Every time we provisioned a new Instance, or re–sized an existing one the – Windows OS would just boot-up normally without ever as much as mentioning the need for any Activation. This silent background configuration effectively crossed Windows Activation from the administrators to–do list when dealing with EC2 Instances.

With the recent introduction of the “VM import” feature that allows us to import an existing Virtual Machine – AWS has essentially opened the door for Windows instances that are 100% built and configured by customers from scratch (with the exception of drivers injected during the import process); and with this newfound freedom comes a wave of new problems and miss–configurations.

Focusing On The Problem At Hand

As previously mentioned, moving a copy of Windows from one hardware configuration to another will trigger Windows to require a new activation – and migrating from a VMware virtual machine to EC2 Instance definitely fits this bill. Trying to activate Windows at this point will result in one of the following:

• If using Multiple Activation Key: It is possible to re–activate this Windows copy online, but doing so will consume one activation from our online activations quota that is tracked by Microsoft (once that quota is reached – online activation will no longer be permitted).
• If using Key Management Services: Our new Instance will attempt to access the same internal activation server it had and will probably fail (unless connected via VPN).

It’s worth mentioning that in both cases we are attempting to Activate Windows using our existing Windows licenses; why should we consume our internal product licenses when the base Windows license is included in the EC2 hourly rate?

The Solution: AWS’s Key Management Services

In order to address this exact problem (and make good on the proposition that the base Windows costs are covered in the EC2 hourly rate) – AWS is providing us with their own Key Management Services to simply offload the license management from EC2 customers.

In order to successfully activate our Instance using AWS’s KMS we need to perform the following actions from within our Instance:

1. Synchronize the Instance’s Windows clock with that of the AWS KMS server. The easiest way of achieving that is by configuring the Instance to synchronize against time.windows.com by going to the “Date and Time” settings from the control panel, select the “Internet Time tab” and set to synchronize with “time.windows.com”. It’s important to click on the “Update Now” button in order to avoid error code 0xC004F06C when attempting to activate.
2. Configure our Instance to activate against one of AWS’s KMS servers from the table below by using the slmgr.vbs tool:

   slmgr.vbs /skms
   slmbr.vbs /ato

Conclusion

In this post we’ve discussed the potential for misconfiguration that can result from importing an Instance to AWS and continued to discuss in-depth the issue of Windows activation for EC2 Instances.

We’ve concluded with a step-by-step instructions on how to leverage AWS’s free activation service in order to offload any maintenance (and fee) that is associated with the base Windows licensing.

Happy Activations!

EC2 Instances are booted either from the “Instance Store” (a process in which the AMI is copied from S3 onto an ephemeral boot device) or from EBS volumes (in which case the boot device is an EBS created from a snapshot of existing EBS volume serving as a template).

While the two types differ in many aspects, there is difference thing that really draws everyone attention: Instance Store Instances will Terminate upon shutdown (planned or unplanned) whereas EBS backed Instances have the ability to enter a Stopped state similarly to physical computers - when we turn it off it doesn’t disappear; it stays inactive until it is powered back on.

While the added persistency offered by EBS-backed volumes has many benefits - there are situations where the non-persistent nature of Instance Store Instances can be very convenient…

For example: in the past, I found myself provisioning individual all-in-a-box environments to various business partners for demo or development purposes.

In these scenarios I found it very convenient to instruct them to shut down the OS when done (or alternately rig the said Instance to shut itself down at a certain date) - thereby causing the Instance to Terminate; freeing any compute resources it was consuming and ending any charges it was incurring as such.

Note that this is not an airtight solution as we humans tend to forget Instances running and/or the Instance OS may fail to properly shut itself down but it is simple, readily available and best of all - does not require any kind of AWS account access or communication from the said Instance, completely containing the contents of the Instance for security purposes.

So how can we set EBS backed Instances to auto-Terminate?

EBS-backed Instances default to entering the Stopped state upon shutdown (after all, supporting this state is the primary reason why we EBS-backed Instances were conceived!), but that’s configurable using the AWS API and command line tools.

There are two methods of changing this behavior (read: attribute) of the instance, called “Instance Initiated Shutdown Behavior”.

Method I: Configure during the initial creation of the Instance

When we provision an EBS-backed Instances through the RunInstances we can supply the shutdown behavior argument and specify it to terminate upon shutdown like in the following example using the EC2 command line tools:

ec2-run-instances ami-12345678 –instance-initiated-shutdown-behavior terminate

Method II: Modifying an existing Instance

We can use the self-explanatory ModifyInstanceAttribute command on existing Instances

ec2-modify-instance-attribute i-12345678 –instance-initiated-shutdown-behavior terminate

Reverting back to Stop upon shutdown

Building on the previous method of modifying an existing Instance; we can also set the Instance to stop upon shutdown, thus reverting any previous setting to terminate.

Happy termination!

Update March 24th, 2011:

AWS now supports changing the shutdown behavior of the Instance through the web console - just right-click on your Instance and select the “Change Shutdown Behavior” option.

Cloud Computing, when exercised in all of it’s glory is about Services rather than Servers - this often facilitated by some form of task scheduling such as Message Queuing (click here to read my introduction to Amazon SQS and how to best leverage it for Cloud Computing).

In this paradigm, adding resources to the Service (again, Servers are irrelevant) is dome simply by adding more servers to our Service’s pool, rather than adding resources to any server in particular.

But not every deployment is a textbook example of Cloud Computing - and that’s fine. Sometimes we have to deal with a component that simply can’t be distributed between servers (often the case with database servers), and sometimes we are running workloads so light that it really makes more sense to throw more resources at our single server rather than face the complexities of re-architecting our application to scale between multiple servers.

Not all Instances were created (launched) equal

At it’s essence an Instance is an Amazon Machine Image (AMI) that has been deployed to a (virtual) machine and powered-up - hence the term Instance. It is a (running) Instance of an (Amazon Machine) Image. Going back to the machine part of the equation, AWS offers different Instance types (read: sizes), each with a predefined amount of CPU, RAM and I/O (priority) resources. Note that Instance types are either 32 or 64 bit - we’ll get back to this important detail in just a bit.

When we provision a new Instance, we either explicitly specify a type (read: size), or just default to small, which comes with 1.7 GB of memory and 1 EC2 Compute Unit.

Cutting to the chase: Changing the Instance type (size)

AWS gives us the option of changing the type of an already provisioned Instance by invoking the API call ModifyInstanceAttribute to change the instanceType value to either a larger or smaller, according to our discretion.

There are three limitations that we need to keep in mind:

1. This action can only performed on Instances that are in the stopped state.
2. Derived from the previous: the Instance must be EBS-backed (since Instance Store Instances can’t stop - only terminate).
3. It is not permitted to switch between 32 and 64 bit Instance types due to AMI limitations. For example: Small Instances can only grow to Medium while Extra Large Instances can only shrink to Large.

This action can also be performed from the command-line via the EC2 API Tools (getting started with the tools isn’t as easy as I hope it would be. but here is an excellent guide to get us started).

Once the API tools are set-up, the syntax is very straightforward. The following is a working example of taking an instance named i-12345678 and resizing it to Medium:

ec2-modify-instance-attribute.cmd i-12345678 -t c1.medium

Note that the “Instance Types” page on the AWS website contains the updated list of available Instance types, as well as their “API name” (the string that represents their size).

Happy resizing!

Update March 24th, 2011:

AWS now supports resizing the Instance through the web console - just right-click on your (stopped) Instance and select the “Change Instance Type” option. Keep in mind that the all of the above limitations still apply.

And I can certainly understand the logic behind it - using Virtualization we could get so much more mileage out of our instances and theoretically drop the AWS costs even further down (more on that logic later).

The short answer to that question is: No. It is not possible to run any kind of Virtualization software inside an AWS Instance.

A word about Virtualization, and it’s prerequisites

Before we jump into the full answer, let’s first have a quick refresher on Virtualization, Emulation and the difference between them.

Virtualization is about taking an existing system architecture (like an Intel-based server) and enabling multiple instances of operating systems to run on it simultaneously while “playing nice” with each other.

Emulation, on the other hand, is taking an existing system architecture (like the aforementioned Intel-based server) and pretending that it is something completely different - like a Power processor running a Mac or a shiny new iPad.

The thing to keep in mind is that Virtualization doesn’t enable you to run on the given hardware anything which you couldn’t just run natively. In a nutshell: Virtualization is about running more of the same whereas Emulation is about running something else.

For further reading, please see Link, Link.

Peering under the hood of an AWS Instance

Modern Virtualization engines are hardware-assisted - meaning that they are relying on hardware support of the CPU (in the form of Instruction Sets) to do some of the heavy lifting associated to avoid slowing down the execution by performing the processing in software.

In Intel and AMD processors these Instruction Sets are called VT and AMD-V accordingly and unsurprisingly - are required by Hyper-V , VMware and Xen.

Armed with the knowledge of what to look for, Let’s review the available CPU Instruction Sets on a Windows Instance as displayed by the excellent tool CPU-Z:

Likewise, Here are the CPU Instruction Sets in a Linux Instance:

Conclusion

As we’ve seen both in Windows and in Linux Instances, no Instruction Sets are available to the instance even though they are supported by the underlying processor (Intel E5430 in our case).

Although running a hypervisor inside another hypervisor (also known as cascading) is possible in different circumstances and under strict limitations - I can certainly understand AWS for not allowing this feature due to security concerns (opening this kind of interaction between an Instance and the underlying Hypervisor can be dangerous) as well as operational (think about how adding another layer of IP multiplexing will effect the AWS network management).

Plus, from a service offering perspective: if customers want more machines they should just launch new ones and pay for them accordingly rather then stress their existing one to their limit and strain the AWS servers to the point of abuse.

Although we’ve established that Virtualization is generally not possible, Emulation is still a viable option (with all of it’s numerous drawbacks) - the only reason I can think of to run Emulation in AWS is to run applications that were written to non-Intel processors (such as Power).

Here is a guide on how to run QEMU in AWS.

Final Thoughts

I would like to ask why are we trying to enter the adventure of owning and operating Virtualization hypervisors (with all of the attached costs and labor) when we already have the ability to launch as many virtual machines as we want for “free” from AWS?

Sure, EC2 Instances cost money - but the ability to launch more and more machines is there right from the gate with no maintenance cost.

After all, having someone taking care of our server infrastructure (storage, servers, switches, hypervisors, etc.) for no up-front cost is the whole point of Cloud Computing? - turning down this “hypervisor outsourcing” may save a few cents, but pulls us back towards the business of operating our own server infrastructure and erodes the benefits we already receive from the Cloud.

Cloud Computing grants us access to incredible amount of compute resources right at our fingertips - just hanging there, waiting to be tapped. Nonetheless, it is often overlooked that while provisioning new servers is incredible easy the trick is to get them to do something actually useful (a virgin OS happily idling in the cloud only generates expenses - not business value or revenue).

In this post we’ll discuss the art and science of making the required configurations and customizations in order to bring our cloud-provisioned servers to a state where it is manifesting itself into business value.

First, Let’s review our options

Let’s start the discussion by outlining a simple scenario in which we set upon provisioning a new, fully-functioning web server in an existing environment.

To that end, we will typically need to perform the following steps:

1. Install the web server on the base OS.
2. Install any required modules/frameworks (like Rails, .NET, mod-php etc.)
3. Import the web application itself, along with any required static content.
4. Import and configure any relevant server identifications such as hostname, public DNS name and X.509 certificates.
5. Configure the server to take it’s place in the application tiers by opening firewall ports, creating an ODBC connection to the database back-end and establish connection with relevant application servers.
6. Fire-up the server, insert it into the load-balancing scheme and validate it’s actually functioning properly.

To fulfill these requirements, we could go down one of the following paths:

1. Manually install and configure the required components (as done in many, if not most, IT shops do today).
2. Bundle all of the requirements into an Image (with physical servers this is often done via using Symantec Ghost or the equivalent) that our cloud provider will use to provision new machines.
3. Provision a vanilla OS image and as a part of it’s initialization fetch on-the-fly the desired components and perform the necessary customizations to bring it to production.

So which configuration method is best?

Manually configuring our servers is time consuming at best and error-prone at worse - making it by far the worse of the three. The simple truth is that we humans are simply poor at performing repetitive tasks - and so much better off delegating it to the consistent and cheap computers we have at our disposal.

Imaging is easy to set up (just manually customize once, and let the provider duplicate this configuration time and time again), but is limited in the sense that we need to create a separate Image for every different configuration - often resulting in a large number of nearly-identical images that all need to be manually maintained.

I strongly suggest implementing a scripted installation and configuration mechanism (we’ll discuss the actual implementation in just a bit) for software and components. It may require more work up-front, but it offers ?such great benefits easily return that investment:

1. First and foremost, unlike imaging: We can apply the desired configurations to existing machines! A machine that has been around for a month is not fundamentally different than one that has been around for a minute as far as running scripts is concerned.
2. No need to create and maintain multiple images. All of the customization is based on the same one baseline - think about having to patch and test only one baseline (also applies to configuration removals, such as uninstalling Apache Webserver).
3. Allows us to create new configurations literally on-the-spot (as they are made-to-order to begin with) - resulting in a much more dynamic and agile IT.
4. It is hardware agnostic (to a greater degree), so the same configuration could be reused on different types of virtual/physical machines.

Scripted configurations have been around for a while, why should we do things differently in the Cloud?

First off, I strongly recommend scripted installations to manage all of your machines - be them physical, virtual or in the Cloud.

It’s the most efficient way to reign control on your IT infrastructure, and with some researches suggest that system configuration and installation tasks are consuming 60%-80% of IT departments’ time (making it a very hard-hitting method of lowering operational costs).

True, we can insist on configuring Cloud machines the old-fashioned way (read: the inefficient way), but that won’t allow us to really leverage the elastic and dynamic nature of the Cloud infrastructure - resulting in nothing more than a glorified pay-by-the-hour hosting.

Although in traditional environments we could get away with doing things inefficiently - the only way to fully leverage the rapidly provisioned Cloud resources and offer highly dynamic and scalable solutions is to rely heavily on a strong configuration and automation toolkit.

Puppet to the rescue

Puppet 101

Puppet is an open source project, backed by a commercial company aimed at automatically configuring Linux (and soon Windows!) systems from a centralized location (providing all of the benefits I’ve mentioned in the previous section).

Puppet revolves around resources which represent various components of a system (such as a file or a process) and enables the administrator to define how does a particular resource be configured on a particular server (or group of similar servers such as “all of the web servers”.

For example, the following resource definition represents Apache webserver:

service { “webserver”:
require => Package[“httpd”],
ensure => running,
hasstatus => true,
hasrestart => true,
}

The two lines highlighted in bold are the main piece of it: the first line ensures that the webserver package (“httpd” in RedHat or “apache2” in Debian) is installed on the system while the second line ensures that it is always running.

These various statements are handled by various providers - components of the system that provide configuration functionality such as the package manager and service manager in the above example.

We don’t dig any deeper into the implementation - but suffice to say that it leverages the existing distribution components, is completely configurable and allows for the addition of custom providers to further extend Puppet’s abilities.

Deploying Puppet In The Cloud

Puppet is a client/server framework with Puppet Agents running on every computer identifying themselves to an aptly named Puppetmaster server that centrally holds all of our configurations - for obvious reasons we’ll need to make Puppetmaster available to our Cloud machines.

Naturally, we probably don’t want all of our machines to have the same configuration - to this end I recommend using AWS’s user-data parameter when starting EC2 Instances to provide the name of the configuration we’d like Puppet to assign to this instance.

For example: if we want this instance to be a webserver then we could pass “webserver-ApplicationA” , or if we want a DB machine we could pass “mysql-ApplicationA” and have Puppet install and configure MySQL - The important benefit is that once the instance has been launched Puppet does all of the heavy lifting for us required to bring this Instance into full production use!

For advanced users, I also recommend pairing Puppet with Subversion to enable rollback and auditing of configurations.

For EC2 users, there is also a freely available EC2 Puppet configuration recipe (enabling some nifty functionality such as having the instance map Elastic IP on boot) freely available at the Puppet website.

Conclusion

The beauty of Cloud Computing is that we switch our focus from Servers to Services. Obviously servers are still the building blocks of services, but instead of maintaining and configuring them one-by-one - we choose to couple Cloud computing with automation to alleviate the need to interact with individual machines and instead focus on the endgame: Services.

Now days, network-edge security is a well established practice - with firewalls providing IP based protection in every organization (and even in almost every home).

So it doesn’t surprise me that I get receive the following quite often from customers and peers: “What is the IP range of my EC2 machines?”

First, the origin of the question

In an on-premise scenario, we usually know before-hand the IP range of the network we are attaching our machine to, and proceed therefrom to assign it an IP address either via DHCP or manually. (in the future, I’ll post why DHCP is so much better, even for servers).

In EC2, AWS provides us with an IP address via DHCP. This mechanism works just fine - but doesn’t tell us what is the IP range of our machines (which could come in handy in case we are looking to group them together under the same firewall rule).

Also, in the AWS console, we can set firewall rules based on Security Group, but not with AWS as a whole.

The answer: AWS is multi-tenant, so you don’t get a private IP range - next best thing is to the entire EC2 IP range.

AWS really managed to hide this information in their discussion board, but here it is (subject to future change), ordered by Region:

A final word of caution

Filtering network traffic by IP is a great first-line of defense, but by no means should it by your only!

Not only could an attack originate from the above EC2 IP range, and thus falsely “validated” by your firewall rule - even when properly configured it was already easily circumvented in the past (and the knowledge is already out there on how to do it again, and again).

In order to further control the initialization of network traffic, I strongly advise you to use SSL coupled with PKI or consider limiting yourself to VPN traffic.

As S3 is a web-based file share, rather than a locally attached block device such as a SCSI disk or thumb drive. Because it is (only) accessible via HTTP, we can choose to direct web clients directly to it, instead of serving it from our web server, thereby offloading the load from the web servers and enjoying the built-in redundancy of S3.

The beauty of it is that it requires absolutely no change from either the web server or the client browser - just be sure to generate your HTML code with absolute paths to the relevant files in S3 and we are good to go:

<img src="http://s3.amazonaws.com/MyBucket/MyPicture.jpeg"/>

Simple has its own limitations

The classic use-case for this feature is where we have a public website serving equally public multimedia content (such as pictures) for anonymous internet clients.

But what happens when we want to implement access-control and authenticate users in our application before we allow them direct access to the content stored on S3?

The bad news is that S3 supports setting file permission ACLs, but it only works with Amazon user accounts (the same ones used for AWS and the Amazon bookstore) - which isn’t really practical to control from inside our application and doesn’t integrate with any existing user database.

The solution is to use an S3 feature called URL Expiration.

URL Expiration to the rescue

S3 allows us to generate a unique URL alias to individual files on S3. This URL can be set to automatically expire, say, after one minute from it’s generation.

And now if we mix together all of the ingredients: it is entirely possible to have a web application that authenticates a user for access to this particular image, an at that point generate a unique URL for that user, set to auto expire one hour later (just like the user session timeout in our web application) with the confidence that we are blocking out unauthenticated users as well as tightly controlling the distribution of these URL (as they auto-expire, users are forced to re-authenticate in order to access the same resources).

Not bulletproof, but pretty close

Some purists will point out that the generated unique URL does open a window of opportunity for a would-be attacker to brute-force his way into that resource, or for the legitimate user to pass-on the URL to a third party.

While these are valid concerns, the reality is that due to the very short lifespan of each URL makes brute-forcing statistically impossible, and as for passing along or intercepting/hijacking the URL from the user - this exposure is no greater than the widely used existing practice of using an HTTP session token.

Conclusion

Although S3 URL Expiration doesn’t bring any new functionality to the table, compared to the existing method of just serving the files directly from the web server - it still holds much value in reducing cost and administrative overhead while greatly improving the scalability and reliability of our generic HTTP application.

In a previous post, I’ve covered the basics of Message Queuing, and Amazon’s implementation of it: SQS (Simple Queue Service).

Amazon has built SQS with three leading principles in mind: Simplicity, Scalability and Redundancy.

In order to achieve exactly that (and achieve they have), some concessions and unorthodox design decisions, creating a few gotchas that we need to keep in mind when working with SQS.

Some technical background before we dive in

In order to provide the so-called unlimited scalability for a given Queue (represented by the unlimited number of messages that could be placed in it) - the operation of the Queue service divided between a number of servers

This is done by grouping messages in the Queue Blocks composed of a certain number of messages which are dispersed, with each Block handled by a separate server.

This Note that in order to also achieve Redundancy, a given Block is actually duplicated to multiple servers in multiple AWS Availability Zones so that no single server failure will result in a loss of messages.

Anyone who has ever tried scaling software on a massive scale (and massive is really the word that comes into mind when thinking of AWS) knows that the #1 challenge and as such the bane of scalability is synchronization.

Having multiple servers/services/applications/pieces trying to coordinate and synchronize their actions by definition involves one component spending part of its time waiting for another (the more components, the greater the wait to work ratio) - and down goes the utilization.

That’s why AWS has bent some rules and made concessions as far as synchronization goes in order to enable the massive scalability of their offerings - SQS included (for example: you can have unlimited number of messages in a single SQS Queue).

But these amazing qualities come at a price - and below I will describe what exactly that price may be and how we can live with it.

At least one delivery

Every Message inserted in the queue is duplicated to multiple servers to ensure redundancy. Let’s envision a scenario where a server holding a given messages fails, and before the server returned to normal operation a duplicate of the message was successfully received from an alternate server.

In a strictly synchronized environment, the returning server would identify that the message it holds has actually already been delivered and should now be deleted for consistency with the remainder of the servers operating the logical Queue.

However, as previously mentioned, SQS does not offer strict synchronization and thus the above scenario is likely to result in a re-delivery of the same duplicate message - hence the term “At lest one delivery”.

Usually this event is not overly problematic (especially as it very rarely occurs) - it’s just a possibility that needs to be considered and either properly handled by the logic of the receiving application (either by knowing there’s no harm in a duplicate receive or by placing an applicative fail-safe).

Check, recheck and check again

We’ve already established that a Queue is dispersed across multiple servers, so whenever a client performs an action against a Queue - the SQS mechanism redirects him to one of the actual servers operating the Queue.

Again, using simplicity as the enabler for scalability - this SQS load-balancing algorithm does not guarantee that a client request will be redirected to a server that actually contains messages. It is entirely possible to be redirected to one empty server and getting a response of “no messages in Queue” while there are still messages in the Queue that are simply residing on a different server than the one which the client was just redirected to.

The easy (and only) fix to this behavior is to simply have the client re-check again and again the Queue, even if it reports it is empty - this way we ensure that the numerous queries will be load balanced across all of the servers operating the Queue and will eventually get to the waiting messages regardless of their current host server.

Not FIFO

Revisiting the SQS Block architecture and the imperfect load balancing algorithem fronting it - we run into another potential pitfall: contrary to their namesake SQS Queues are not FIFO (First-In-First-Out).

It is entirely possible (and even quite common) that the AWS scalability mechanism which does the redirection of messages to servers to redirect subsequent messages which we will label as Message A and Message B to two separate physical servers (which we will also label as Server A and Server B).

Continuing our scenario, that same load balancing and scalability mechanism may redirect a client to receive messages first from Server B and then from Server A - resulting in the delivery of the messages in scrambled order.

In plain english: there’s no gurantee that messages will be delivered in the same order in which they were sent - if that’s a problem then SQS is not a viable platform and other MQ platforms should be considered instead!

8K Message Size Limit

A single message in SQS is limited to 8K in size - plain and simple.

If there is a requirement to transfer more than that to the recipient we can do one of the two:

1. Place the data that would otherwise have been sent as a message as a single file in some staging area (S3 is a great choice to this end) and just send the URL to the recipient (and still retain the actual benefits of properly dispersing the responsibility to process these files among the recipients).
2. Simply use a different Message Queueing mechanism (I’ve briefly discussed these in a previous article).

4 Days Message Retention

Actually, this one is actually a feature - most MQ administrators would kill to have a SLA guarantee that unread messages will be retained in the Queue for 4 days before purged.

Keep in mind that the proper usage of SQS is as a pipeline, not an archive, and that under normal circumstances messages should never be left unread for so long (no queuing of messages in the beginning of the month pending end-of-month processing).

Conclusion

SQS is everything we’d expect it to be - being a product of AWS that has the word Simple in it’s name.

It’s readily available, simple to use, scalable and incredibly cheap (a bargain at $0.000001 per API call plus regular data charges which are waived if made from EC2 instances).

As discussed in a previous article, using Message Queuing is usually a good idea. This is even more so when designing elastic systems and to that end SQS usually does the job well - just remember to steer away from potential pitfalls and everything will work like clockwork.

The beauty of electronic mail (or plain old snail mail for that matter) is that as the sender, you didn’t need to bother yourself with the the details of how your message reaches it’s destination. After composing the message, all you need to do is just to hand it off to your trusted mailman who’s entire job is to handle the logistics and challenges of mail delivery for you.

This mechanism offers such level of abstraction, that you as a sender are not only not responsible for the actual delivery of the message - you don’t even need (or want) to know how it got to it’s destination (by plane, by truck, by carriage etc.).

Message Queuing (MQ) takes this same concept of relieving the sender from the responsibility of actually delivering the message to it’s destination by offloading it to a dedicated component that specializes in doing exactly that - reliably delivering messages to their destination. It is also the technological cornerstone of SOA (Service Oriented Architecture), but that’s a story for another post.

My applications already communicate just fine, what’s in it for me?

TCP/IP Sockets are natively available in every programming language, and using them in applications is both common practice and common knowledge.

With both the technology and the know-how already in place - it is so very tempting to just use it. After all, why bother to invest in bring something new into the mix (together with the associated overhead of skills and other costs) when we already have a viable way of doing business “for free”?

But, just like many other things in life - “free” often times comes with a hidden price tag:

• It places the burden of validating successful delivery (network-wise as well as logically in an application-specific manner) on the sending applications base code, requiring greater programmatic effort to successfully implement the program as a whole.
• More code = more bugs. Plain and simple.
  That’s not to say that an “off the shelf” middleware is bug-free, but leveraging existing and proven technologies is always safer and easier than writing and maintaining custom code produced in-house, period.
• Sockets are opened between two computers: meaning that transferring a message to multiple recipients requires additional coding effort and more importantly - requires the sender to know where to send the message - a requirement that doesn’t always co-exists well with the dynamic nature of Cloud Computing.
• Sockets are immediate - meaning that in order to pass on a given message the recipient must be ready and willing to receive it right now.
  If the recipient suddenly goes offline or simply unable to immediately process the messages (like an electronic trading system outside trade hours) it is the responsibility of the application to take necessary actions such as buffering the messages until the right time to process them.

Message Queuing is designed to address all of the above and much more - it is a proven concept widely used in the most demanding environments and enjoys numerous implementations such as the stand-alone IBM Websphere MQ, Microsoft Message Queuing (MSMQ) which is bundled with Windows Server, as well as open source implementations like Apache Active MQ.

So how does it work?

Message Queuing revolves around the concept of Queue: a logical FIFO list of messages that share the same logical destination (such as incoming messages from clients to application X, or outgoing messages from application X to application Y). In essence, the Queue’s logical function as a pipeline, enabling messages (read information) to freely and easily flow from one application to another.

Note that a Queue doesn’t explicitly specify servers, as it is a detached and independent entity from any single server - more on that in just a bit.

All we need to do from our application(s) is to invoke the Queue’s “send” method in the sending application (called “Producer Application” in SOA terminology) and similarly invoke the “Receive” method in the receiving application (again, in SOA terminology this application will be called “Consumer Application”) - and that’s literally all there is to it (application-wise).

This two-step process in which one application’s send followed by other application’s receive has two very important properties:

• It is asynchronous: meaning that any period of time can pass between the send and the receive - in which time the message will exist inside of the queue, waiting for delivery.
  This is a very convenient and “free” way of implementing resiliency into our applications as messages aren’t lost when the receiver is down, only queued until the receiver finally does return to normal operation (think of messages in your mailbox while you are away for vacation or sick-leave).
• It is also loosely coupled: meaning that the sender does have to be specifically address the messages to any particular recipient - instead they could be independently fetched by the receiver, or load balanced across multiple receivers (think of call-centers, where your call is placed in a queue and will be answered by the first representative who becomes available).

Together, these two properties are well tailored to Cloud-Computing environments where there is a constantly shifting number of senders and receivers that using this method don’t need to actually know of each other - rather they just pivot around this one central Queue who handles both the load balancing and fault tolerance.

So how does AWS do Message Queuing?

Similarly to S3, SQS is an independent HTTP-based service happily living in the AWS cloud, not attached to any instance in particular.

True to it’s name SQS is very simple to set-up and use (at the expense of being feature-poor compared to other MQ implementations), and can be configured and used by any Internet connected computer (inside and outside of EC2).

Below is a working example, taken from the SQS API Reference for sending a message to a Queue via invoking the following HTTP URL:

http://queue.amazonaws.com/123456789012/testQueue/
?Action=SendMessage
&MessageBody=This+is+a+test+message
&Version=2009-02-01
&SignatureMethod=HmacSHA256
&Expires=2009-04-18T22%3A52%3A43PST
&AWSAccessKeyId=0GS7553JW74RRM612K02EXAMPLE
&SignatureVersion=2
&Signature=Dqlp3Sd6ljTUA9Uf6SGtEExwUQEXAMPLE

Similarly, in order to receive my message from from my queue will invoke the following HTTP URL:

http://queue.amazonaws.com/123456789012/testQueue/
?Action=ReceiveMessage
&MaxNumberOfMessages=5
&VisibilityTimeout=15
&AttributeName=All;
&Version=2009-02-01
&SignatureMethod=HmacSHA256
&Expires=2009-04-18T22%3A52%3A43PST
&AWSAccessKeyId=0GS7553JW74RRM612K02EXAMPLE
&SignatureVersion=2
&Signature=Dqlp3Sd6ljTUA9Uf6SGtEExwUQEXAMPLE

And that’s all there is to it, no servers needed to support the Queue and no dedicated client needed needed to tap into it.

Simple.

Conclusion and Further Reading.

Message Queuing is a proven technological concept that is heavily leveraged both independently and as the foundation of larger concepts (such as SOA, or J2EE) to great success. Oftentimes, Message Queuing is the perfect bridge in the gap between the need to keep applications simple (read: “Single Minded”) and yet sophisticated enough to keep track of what’s going on in highly dynamic Cloud-Computing environments.

Stay tuned, in future posts we will drill down the pros, and cons, of SQS.

As the goal of Application Virtualization is to decouple the application from the underlying Operating System, we often find ourselves lacking this lost integration in unexpected places. One issue I frequently face with customers is how to configure Windows Explorer’s Sendto shortcut (the one available when you right-click on a file) to actually work with a ThinApped copy of Microsoft Outlook.

To thinreg or not to thinreg?

ThinApp’s method of integrating itself into the OS is via a tool called thinreg.exe - but before we discuss why isn’t it suitable for this particular task we need to understand what it does do: When we create a ThinApp package, we are essentially creating a self-contained application “bubble” which can have any number of “Entry Points” - these Entry Points usually represent the individual sub-components of the application that we want to expose to the user (and as they share the same bubble, they share files, registry and configuration with each other).

In the case of Microsoft Office, we typically want to create an Entry Point for each of the suite’s programs such as: Word, Outlook, Excel and Powerpoint - and the configuration of the Entry Points is captured by the ThinApp composer and placed into the package.ini file.

Let’s go over the output of the outlook.exe entry point as captured in a default Office installation, with the sections that interest us bolded:

[Microsoft Office Outlook 2007.exe]
Source=%ProgramFilesDir%\Microsoft Office\Office12\OUTLOOK.EXE
Shortcut=Microsoft Office Enterprise 2007.dat
Icon=%SystemRoot%\Installer{90120000-0030-0000-0000-0000000FF1CE}\outicon.exe
FileTypes=.hol.ibc.ics.msg.oft.vcf.vcs
Protocols=feed;feeds;mailto;Outlook.URL.feed;Outlook.URL.mailto;Outlook.URL.stssync;Outlook.URL.webcal;outlookfeed;outlookfeeds;stssync;webcal;webcals ObjectTypes=DOCSITE.DocSiteControl.1;MailMsgAtt;Outlook.Application;Outlook.Application.12;Outlook.FileAttach;Outlook.MsgAttach;Outlook.OlkBusinessCardControl;Outlook.OlkBusinessCardControl.1;Outlook.OlkCategoryStrip;Outlook.OlkCategoryStrip.1;Outlook.OlkCheckBox;Outlook.OlkCheckBox.1;Outlook.OlkComboBox;Outlook.OlkComboBox.1;Outlook.OlkCommandButton;Outlook.OlkCommandButton.1;Outlook.OlkContactPhoto;Outlook.OlkContactPhoto.1;Outlook.OlkDateControl;Outlook.OlkDateControl.1;Outlook.OlkFrameHeader;Outlook.OlkFrameHeader.1;Outlook.OlkInfoBar;Outlook.OlkInfoBar.1;Outlook.OlkLabel;Outlook.OlkLabel.1;Outlook.OlkListBox;Outlook.OlkListBox.1;Outlook.OlkOptionButton;Outlook.OlkOptionButton.1;Outlook.OlkPageControl;Outlook.OlkPageControl.1;Outlook.OlkSenderPhoto;Outlook.OlkSenderPhoto.1;Outlook.OlkTextBox;Outlook.OlkTextBox.1;Outlook.OlkTimeControl;Outlook.OlkTimeControl.1;Outlook.OlkTimeZone;Outlook.OlkTimeZone.1;RECIP.RecipCtl.1
Shortcuts=%Programs%\Microsoft Office

These parameters interest us because they define the specifics of how to register with the underlying physical OS.
“FileTypes” indicates what file suffixes will be associated with this Entry Point.
“Protocols” is the association with Internet Explorer URL path suffixes (using http and https has become such a second nature to us, that we tend to forget that we can also browse to other types of addresses such using the same Explorer such as ftp).
“ObjectTypes” registers COM objects from ThinApp in the underlying COM Provider.
“Shortcuts” is the list of the locations in which to place a shortcut to start the Entry Point (such as the user’s Desktop and Programs).

So far so good, but what about the Sendto?

As we’ve learned in the previous section, the functionality to enable Sendto context menu simply doesn’t exist in thinreg - but hope is not lost! We can still manually (or via script) configure the host’s “Send to mail recipient” short cut so that instead of trying to locate a physical installation of a mail client - it will immediately launch our ThinApped Outlook instead.

First, we will need to locate and delete the existing Sendto link (aptly named “mail recipient.MAPIMail”), located under %userprofile%\sendto and create a new shortcut to the path shortcut invoking the following command:

Outlook 2007:

“C:\Path to ThinApp\Outlook.exe” /c ipm.note /a

Outlook 2003:

“C:\Path to ThinApp\Outlook.exe” /c ipm.note

Enough talking - just hand over the answer!

For the sake of practicality, below is a VBScript which will replace the original “mail recipient” with one invoking your ThinApped Outlook. Just copy the text and paste it into a .vbs file and execute the script in the user’s behalf via logon script.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

' First, we set the path for the ThinApped Outlook
OutlookPath = "C:\ThinApp\Outlook 2007.exe /c ipm.note /a"

' Don't forget to use these arguments for Outlook 2003
'set OutlookPath = "C:\ThinApp\Outlook 2003.exe /c ipm.note"

' Initialize the necessary objects
set WshShell = WScript.CreateObject("WScript.Shell")
Set objEnv = WshShell.Environment("Process")
SendTo = objEnv("userprofile") & "\sendto"

' Delete the original "mail recipient" as well as any previous "mail recipient" created by a previous run of this script
Set filesys = CreateObject("Scripting.FileSystemObject")
If filesys.FileExists(SendTo & "\Mail Recipient.MAPIMail") Then
 filesys.DeleteFile SendTo & "\Mail Recipient.MAPIMail"
End If 

If filesys.FileExists(SendTo & "\Mail Recipient.lnk") Then <br>
 filesys.DeleteFile SendTo & "\Mail Recipient.lnk" <br>
End If 

set oShortCutLink = WshShell.CreateShortcut(SendTo & "\Mail Recipient.lnk")
oShortCutLink.TargetPath = OutlookPath
oShortCutLink.WindowStyle = 1
oShortCutLink.Hotkey = "CTRL+SHIFT+N"
oShortCutLink.Description = "Send mail via ThinApped Outlook"
oShortCutLink.Save